-
Notifications
You must be signed in to change notification settings - Fork 92
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
CLI refactor #2972
Comments
On point 8. A syntax to allow control of multiple suites is good, but I'm not sure I understand the proposed syntax. A simple (quoted) glob to replace the current SUITE positional argument is probably the least disruptive? The other points are good. It may be worth noting that argparse has an issue with mixing options and positional arguments ordering until Python 3.7. |
Yes, it would be great to have this done. Some of this we've wanted for ages, but there are also some good new ideas that I hadn't thought of. My only concern is how long this might distract from the core cylc-8 implementation tasks (since a CLI refactor is more highly desirable than critical). I suppose some parts of your proposal could be done later, however, ... such as better use of colour. However, if its easy enough and quick enough, let's do it! |
I think this will have a positive impact on the code base, and will definitely help for packaging and also for testing. +1 and thanks for starting the task! |
I think with the exception of 7 this should all be pretty quick to implement.
I'm guessing you mean something like this? $ # usage: cylc show REG TASKID
$ cylc show 'foo bar baz/*' pub.1 That's a pretty simple way to do it. My logic was:
This: $ cylc -r foo bar show baz.1 --format=json Would run this: $ cylc show foo baz.1 --format=json
$ cylc show bar baz.1 --format=json Or
$ cylc -r foo -r bar show baz.1 --format=json Or
etc |
Matt just mentioned a good use case worth recording here:
|
Some other main usages for multi-suite controls:
|
From these use cases Cylc would need the ability to select suites by:
|
I think this is an important point. Do we anticipate the CLI will need adjustments during Cylc 8 to fit with the new architecture &/or new control potential & mechanisms from the Web UI? If so, is it not premature to do a CLI revamp at this stage? (I'm just throwing some questions out there, as I am not yet sure where I sit on this from lack of background; I am also wary of complicating our already extensive roadmap.) Otherwise, some CLI ideas I have that have not yet been covered, which are definitely for later rather than sooner, i.e. for post Cylc 8:
|
Some time ago I created #2802 thinking in the Web UI. And I think this comment in this issue might fix that
Right now we have a prototype UI server in https://github.com/cylc/cylc-jupyterhub, which is able to talk to the JupyterHub and also to REST or GraphQL endpoints. And I am in the progress of trying @dwsutherland 's GraphQL branch. The GraphQL branch won't have a GraphQL endpoint until I run For now I will run in another terminal The issue is that we will have to have that ugly code to Which is doable, but I would prefer to be able to just
Great question. We could skip it and implement everything calling the commands from command line. But changing this later, would mean to update For a change like this, we could go with a minor release like 8.1 if we consider for a user of cli commands there was no change, but if we consider the other developers relying in Cylc public API, this would have to be a major release like 9.0 - as we could break their code by moving the logic from commands to other places. So I'm +1 for including this in Cylc 8 😁
I like this idea too! I always run Maybe we could copy
+1!
Sounds interesting too! I think I liked all your suggestions! Except for easter egg, which I am not sure we would be able to properly test 😁 (I'm an old man, no sense of humour, that's fine). If others agree too, I think this issue could proceed, and your suggestions would become issues blocked by this one :) |
On On verbosity, Rose's interface is still my favourite. Starting with |
I think that argparse, despite being the 3rd CLIs attempt in the standard library, is definitely not the charm. Over-complicated and lots of boiler plate required for anything more substantial. There is a lot of alternatives out there if you're willing to look outside of the standard library. Personally, I quite like the idea of auto-generating CLIs from function signatures like clize or plac - all you do is write regular Python functions (possibly with some argument annotations) and you can run them as CLIs with no extra work. The latest release of clize adds support for Sphinx doc strings, while with plac it's easy to add interpreter mode for interactive use suggested by @sadielbartholomew. |
I've seen a few projects with click too. Looks simpler, but will be happy to just have moved from |
Cool libraries. Let's pick one to use. |
@kinow I noticed your star on python-fire some time ago as well. Looks very good and backed by the big guy. (All these remind me of Perl 6, which comes with this sort of magic as part of the language. And the good old days when I wrote a CLI parser from scratch to support GNU-style CLI (i.e. long/short options, positional arguments mixed with options, etc) for a Java utility, all configured via dependency injection with a horrible XML file, etc.) |
Yup, python-fire is another good one. I had a look at the code and commented in an issue. They fixed that issue quite quickly later, which indicates the project is still maintained (google must be using that for their Python libraries). I also thought that AWS could have something, then just checked their Python aws CLI (which is great, and used in so many places). Looks like they are using argparse too (https://github.com/aws/aws-cli/blob/develop/awscli/argparser.py). As well as colorama, a new dependency introduced in the Python3 pull request that I still want to learn about 🤓 |
@sadielbartholomew and @kinow - I'm not so keen on this idea, sorry! Given this is the shell CLI, users can do this sort of thing themselves with bash aliases and shell variables defined in their login scripts, right? Plus, I have seen users who alias standard commands to their own "language" to such an extent that they end up unable to work in a standard environment, or to communicate with others who do. Built-in support for command aliasing and option grouping etc. might just encourage this sort of thing! I think storing command history is also best left to the shell. Bash and fish, for instance, allow you to view and re-run previous commands very easily. |
Sounds like a good argument to me, especially given there's a workaround. Will update my aliases list to include a cylc=cylc --no-detach --debug... 🎉 |
When we have "cylc as a module" we can just use the interactive Python interpreter. Or Jupyter Notebook. |
Agreed (with a few exceptions noted above). Do others agree with @TomekTrzeciak that stdlib argparse is not the best route for CLI? I don't mind new 3rd party dependencies if the benefit is clear (that's much easier with proper packaging at least) but we have to be a bit careful to not to end up relying on some dead-end project if we diverge from the standard library. |
Agreed that we should choose a 3rd party solution, carefully. (@wxtim has shown me yet another problem with argparse earlier, so I am now fully convinced that it is NOT the way forward. Really, how hard can it be to write a good CLI parsing framework?) |
I see this a lot too. Over customisation is the root of a large number of user issues. Keep it simple, keep it vanilla. |
Fair enough @hjoliver, I follow your reasoning & though I think it can be done in a more pared-down way than I hastily wrote up as an example, to avoid those issues, it doesn't seem like the best use of time and effort in terms of new features and functionality etc.
Yes, I strongly agree. We shouldn't stick with |
A point in favour of argparse: Sphinx integration #3037 (comment) |
This is mostly done now, punting the remaining parts to other issues in the relevant repositories. Quick summary of the 10 points above:
|
With Cylc8 and the upgrade to Python3 (which brings with it
argparse
) we have the opportunity (read excuse) to make some meaningful changes to the CLI.This issue is for collating (and hashing out the details of) changes to make.
My suggestions:
argparseClickargparse?argparseClick for them all.cylc.cli
or something of that ilk.argparseClick to implement cylc subcommands as proper subcommands.pytest
is a good example.--format=json
,--terse
and--color=never
.--bold
,--no-bold
,--color
,--no-color
--color=WHEN
.cylc scan
on my Python3 branch.--raw
,--plain
,--json
,--terse
--format=FMT, -t FMT
.cylc scan
on my Python3 branch.Consider moving some options onto thecylc
command itself rather than the subcommands.remrun
functionality now removed, no longer a concern.--host
might be a good candidate i.e.cylc --host=myhost subcommand --subcmdoption
.Implement a simple batch mode on thecylc
commandSuperseded by global universal identifier #3931
--debug
and--verbose
: - cli: verbosity #4214-v
/-q
logging
levels for this, i.e.cylc -v
would get youlogging.DEBUG
,cylc -q
would get youlogging.WARNING
.--debug
shorthand for--verbosity=DEBUG
.We should probably do this along with #1249 & #2928
Thoughts? Suggestions?
The text was updated successfully, but these errors were encountered: