-
-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace argparse CLI with typer. #606
Comments
What about There are many other alternatives, although I am quite fond of rich. One thing is that the current CLI is doing stuff depending on the order of flags, do they automatically do this? I'll think some more and come with some more comments. |
Typer is built on top of click and you can customize a typer CLI with click concepts. With "raw click" I find the syntax for defining arguments as verbose as I think the behavior of |
We could start with the Sorry to rush this but I have the basis optimization CLI ready to merge but for the moment it's in |
My idea is to create a from typing_extensions import Annotated
from somewhere_in_sisl import CLIargs
def my_sum(
first: Annotated[int, CLIargs("-f", metavar="Whatever")],
second: Annotated[int, CLIargs("-s", metavar="Another")]
):
"""Sums two numbers
Parameters
---------------
first:
First argument.
second:
Second argument.
"""
return first + second The CLI would be created from the functions' signature (including type hints and metadata) and the docstring. Then changing from one CLI framework to another would be just a matter of changing the function that creates the CLI. So I would be taking from |
Sounds like a plan. Here would be my proposal:
|
I would like to propose to rewrite sisl CLIs with typer instead of argparse.
Why?
Because:
rich
, which uses colors in the terminal 🎨Thanks to the first point, I envision we could implement commands like
sgeom
without all the boilerplate code that there is currently in theGeometry
class. In fact, we could automatically create a command for any class that we want in sisl which would include all its methods. E.g.:Then, all arguments would automatically work without needing to describe the interface separately, as it is done with
argparse
, which means that it will be much easier to maintain a complex CLI.What would be needed?
We would need to define a parser for any custom type that might appear in sisl's type hinting if we want to support it. Say for example, if we have a function that receives a geometry:
of course you can't pass a geometry through the CLI. You would then define a parser:
and pass it to
typer
whenever there is aGeometry
annotated function. Typer accepts this kind of parameter options as metadata ofAnnotated
:so we would need to define a wrapper that introduces this kind of information before passing it to the typer CLI. But it would work for ALL functions. Another thing that goes into the metadata is the help message of the parameter. It would be retrieved from the docstring. Since all docstrings in sisl follow the same standard, it is quite easy.
I have already implemented the proof of concept wrapper and it works nicely.
I think this would standarize sisl CLIs, making them more familiar to the users, and can facilitate creating new CLIs in the future (e.g. for plotting 😄). If you agree, I could give it a try to reproduce the existing CLIs and create a PR 👍
The text was updated successfully, but these errors were encountered: