docopt.rs
typer
docopt.rs | typer | |
---|---|---|
4 | 87 | |
752 | 14,398 | |
- | - | |
0.0 | 8.7 | |
about 3 years ago | 3 days ago | |
Rust | Python | |
The Unlicense | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
docopt.rs
-
Docopt.sh – Command-Line Argument Parser for Bash 3.2, 4, and 5
Consider using clap or possibly structopt instead.
It's a lovely way to internalize the CLI argument cultural norms, decrease confusing and verbose argument parsing, make argument parsing work-free for the developer, and make argument parsing a copy-paste across languages. There's no greater pleasure than iteratively adding options to your program by just adding a line of text
-n, --new-option Do something new
I honestly think making a docopt parser is just very hard, which may limit its future prospects.
[the docopt rust repo.]: https://github.com/docopt/docopt.rs
-
Fedora to disallow CC0-licensed code
Ditto, I guess? :P (But obviously with the position on the Unlicense flipped.)
To address your indictment head-on: you suggesting the 0BSD as a better alternative is really missing my point. The 0BSD is not an alternative for my use case. The Unlicense is one of the very few overt "political" acts that I inject into the software I produce. Its purpose is to make a statement. The 0BSD doesn't do that IMO, so it's not actually an alternative that meets my advocacy goal.
You and Rick Moen seem to have the same apparent blind spot for this. See my conversation with him that started here (which might also clarify some aspects of my own position): https://github.com/docopt/docopt.rs/issues/1#issuecomment-42...
And finally, note that my dual licensing scheme is exactly a response to the "problems pointed out by quite a few people": https://github.com/BurntSushi/byteorder/issues/26
-
Docopt
I like Docopt for quick scripts, used it both in Python and Rust projects. It is quite unflexible though.
The Rust Docopt implementation¹ was deprecated this year, which is probably good because clap v3 (https://github.com/clap-rs/clap) is so awesome. In a project of mine (tealdeer), I noticed that docopt.rs was responsible for the huge majority of CPU instructions when running the binary: https://github.com/dbrgn/tealdeer/issues/106#issuecomment-59... I then switched² to clap and shaved off almost a megabyte from the release binary³. Performance improved as well, time required for rendering a tldr page went down from ~15.9 ms to ~12.4 ms⁴. With the migration, we also managed to reduce a lot of custom validation logic and move this logic into the derive macro attributes.
¹ https://github.com/docopt/docopt.rs
- clap 3.0.0-rc.7
typer
- Typer: Python library for building CLI applications
- Copilot for your GitHub stars
-
Things I've learned about building CLI tools in Python
I have been using Typer on every one of my CLI projects which uses Click under the hood. The documentation is fantastic, the CLI app it produces looks great and lets you create things quickly. I high recommend it.
https://typer.tiangolo.com/
-
Things to do with standalone script
Adding CLI capabilities. My preferred library here is typer.
-
Where to start for managing a Python code base for public distribution
I just heard about this but it seems to be pretty much the type of thing you want and want fast.
-
Help on Docstrings
Docstrings are for documenting how a function/ class/ method/ module works. Often you don't need to add a docstring to your main function because no one will be importing it to use elsewhere. And if you want it to run as a CLI, then there are better ways to document the available options. For example, typer does most of it for you, or in click you add the help text to the decorator.
-
Which best practices do you follow to build robust & extensible ETL jobs?
Most computing tasks in airflow DAGs are KubernetesPodOperator containing a CLI (Python Typer). It allows us to pass arguments easily to run DAG manually if needed (the new UI to pass arguments to DAG in airflow 2.6 is really nice). Arguments allow us to replay DAG easily (change start / end dates for instance).
-
Devs on teams that deploy anytime you want, what does your SDLC workflow look like?
So it's basically the main .gitlab-ci.yml file plus a separate Python CI app using Typer for the AWS instrumentation.
-
The different uses of Python type hints
Similarly for Typer, which is literally "the FastAPI of CLIs"[1]. Handy to type your `main` parameters and have CLI argument parsing. For more complicated cases, it's a wrapper around Click.
[1] https://typer.tiangolo.com/
-
Command line parser library, which one do you like the most, regardless of language?
interesting that you hate python, but love Click. Did you try Typer which uses Click underneath?
What are some alternatives?
clap-rs - A full featured, fast Command Line Argument Parser for Rust
click - Python composable command line interface toolkit
structopt - Parse command line arguments by defining a struct.
Python Fire - Python Fire is a library for automatically generating command line interfaces (CLIs) from absolutely any Python object.
easy_flag - Simple command line flag parser for rust.
Gooey - Turn (almost) any Python command line program into a full GUI application with one line
byteorder - Rust library for reading/writing numbers in big-endian and little-endian.
rich - Rich is a Python library for rich text and beautiful formatting in the terminal.
docopt-ng - Humane command line arguments parser. Now with maintenance, typehints, and complete test coverage.
python-prompt-toolkit - Library for building powerful interactive command line applications in Python
argc - A Bash CLI framework, also a Bash-based command runner.
cement - Application Framework for Python