Comments (11)
I'll investigate if I can reasonably add rst support. RST would be a good, python-sane default. If I cannot, I agree that I think setting "markdown" as the default is reasonable.
from cyclopts.
Sounds like a solid plan! Looks like RST also won't mess with plaintext, so users who don't intend to use any special formatting shouldn't even notice that their help text is being rendered as RST. The aliases are also a good idea.
I'm more of a markdown guy myself, but I can take a look if any issues pop up with rich-rst
.
from cyclopts.
this is now in v2.2.0, thanks!
from cyclopts.
So I'm strongly considering adding some sort of formatting support for docstrings. Markdown would be one of those options, but RST is also a natural choice. Unfortunately, rich doesn't have native rst support. I think it would manifest itself in a way like:
app = App(docstring_format="markdown")
from cyclopts.
@Gracecr would you mind playing around with #85 and see what you think? Currently only "text" (default behavior) and "markdown" are implemented. We can add RST later if we figure out a maintainable solution.
from cyclopts.
Markdown looks gorgeous! Seems like most everything is working in the VSCode integrated terminal. Even code blocks with syntax highlighting and tables are working!
I'm not seeing any new bugs introduced with this PR.
from cyclopts.
do you think the API is fine? i.e. the field name being help_format
, the two valid explicit options being "text"
and "markdown"
, and it's documentation being:
The markup language of docstring function descriptions.
If ``None``, fallback to parenting :attr:`~.App.help_format`.
If no :attr:`~.App.help_format` is defined, falls back to ``"text"``.
from cyclopts.
Seems like a reasonable API to me. I would try to make it prominent in the docs. It's too nice of a feature for users to not know about it!
from cyclopts.
follow up question: do we think "markdown" or "text" is a more reasonable default? The markdown looks much nicer.
from cyclopts.
follow up question: do we think "markdown" or "text" is a more reasonable default? The markdown looks much nicer.
Good question. I agree that it likely improves the look of the average user's output. On the other hand, it is non-standard in the python world.
I think markdown default still gets my vote. If a user doesn't intend to use it, it probably won't change their output. If it does, it probably looks better. On the off chance it messes up their formatting, they can always switch to "text".
from cyclopts.
Alright so, here's my thought process:
-
rich-rst
appears to be what we want, but it only has 9 stars on github. -
rich-rst
stems from this discussion in the rich repo. -
rich-rst
itself doesn't have any subdependencies, which is good. The module itself is only like 700 lines of code in an__init__.py
. -
willmcgugan, creator of rich, uses
rich-rst
as a dependency inrich-cli
, which has nearly 3k stars at the time of this writing.. That said, he hasn't really touched that project in 2 years.
So, I think I'll do the following:
- Add
rich-rst
as a dependency. - Add the following
help_format
:"restructuredtext"
,"rst"
(alias for restructuredtext) and"md"
(alias for markdown). - Rename "text" option to "plaintext" for additional explicitness.
- Make the default
help_format
option be "rst". - Update documentation, maybe make a whole page for this.
@Gracecr what do you think of this plan?
from cyclopts.
Related Issues (20)
- [BUG]: bad error report because of assetion error when there is UnusedCliTokensError HOT 2
- [BUG] Weird behavior of list of tuples HOT 7
- [BUG] list of tuple of single item is parsed but take only the first character of each token get parsed HOT 2
- Misleading error message when flag name has an underscore HOT 2
- the help format parsing is not consistent HOT 2
- Misc likely (rare) typing bugs HOT 1
- Use of the meta application results in a double help display HOT 5
- Automatic conversion from underscore to hyphen HOT 3
- Prompt for missing required parameters HOT 6
- Newlines should not be present in descriptions that span multiple lines HOT 5
- [Feature Request] Add auto_env_var_prefix HOT 19
- Importing cyclopts fails if there is a file called "tokenize.py" in the project which imports cyclopts HOT 1
- [feature request]: automatic markdown documentation generation HOT 2
- App() name parameter type hint adjustment HOT 2
- [Feature request]: Nested pydantic validation HOT 14
- [Discussion] First-class config overrides via pyproject.toml? HOT 2
- [Feature Request] Completion? HOT 6
- App() console parameter HOT 2
- integration with https://pypi.org/project/typed-settings/ HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cyclopts.