picocli VS cli-guidelines

Picocli allows using a compiler annotation processor to generate classes at compile time instead [0].

[0]: https://github.com/remkop/picocli/blob/main/picocli-codegen/...

Picocli is a pretty good one for writing CLI apps

"and there are simply no good command line input parsing libraries for Java."

Looks like author missed the most obvious and popular OSS one: https://picocli.info/

The command line example gave me the "ick". It is usually preferrable to parse the command line arguments into one instance of a custom "command class", rather than into a list of things. Like jcommander, picocli or jbock do.

Complex argument parsing needs to be auto-generated by libraries like picocli. Even if you need something custom, it'd be quicker to write an Annotation processor from scratch than editing that file.

https://github.com/remkop/picocli

"Picocli-based applications can be ahead-of-time compiled to a GraalVM native image, with extremely fast startup time and lower memory requirements, which can be distributed as a single executable file."

https://picocli.info/quick-guide.html

Using picocli to handle your command line options gives you the best chance to automatically generate an ArgumentCompleter script in the future, but won't help you today (other than possibly making your command line handling more standardized & easier).

Picocli

Then we released a JBang! and picocli based cli that would be, on any OS running a jvm runtime :

picocli : "a mighty tiny command line interface"

The Command Line Interface Guidelines [1] says:

> Do not read secrets from environment variables

> Secrets should only be accepted via credential files, pipes, `AF_UNIX` sockets, secret management services, or another IPC mechanism

Which one of these do you use? On github it seems common for projects to use environment variables for secrets.

[1] https://clig.dev/#environment-variables

Seems they took a small step back from their previous "don't bother with man pages" stance. Now it's "Consider providing man pages."

I still find it a rather shocking order of priority, honestly.

https://clig.dev/#documentation

- E. `blah project foo --edit`

Wondering if there was any guidance on this from the UNIX people. Perhaps scoping should be done using the file system. `cd path/to/project && blah edit`. Like git does with `git --cwd=path/to/project`. Maybe a virtual FS could even be used. Then you wouldn't have to continuously type in the scope with each command. Interesting thinking about how to maintain state in the terminal...thinking about how Python's virtual env bin/activate modifies the shell.

Found an interesting guide here: https://clig.dev/

Capturing these guidelines is one of the primary reasons that https://clig.dev/ exists.

You may want to take a look at various existing CLIs to get inspiration on how they operate, the user feedback loop and the ergonomics on using them. Here is a great website on some CLI structing guidance https://clig.dev/