typespec VS cli-guidelines

It does not exist, but it will be worked on fairly soon. You can track progress on GitHub [1]. It will be as you suggest - a one time conversion, after which you can iterate. We have this workflow for inside Azure, but the converter is Azure-specific (e.g. converts to TypeSpec that uses our extensive Azure-specific component library). It will take a bit to generalize.

[1]: https://github.com/microsoft/typespec/issues/3038

Afaik there's nothing that's widely used and of which I'd say I prefer it. But I'm having hopes for https://github.com/microsoft/typespec (former cadl). The reason being that yaml/JSON specs get huge very quickly, OpenAPI has to fight with restrictions of yaml/JSON ($refs, splitting up into files, oneOf, etc.) and tooling is ok but not great.

You've touched on some use cases I've thought about and led me to ask the question.

I also recently saw Microsoft take a higher level approach with CADL/Typespec: https://microsoft.github.io/typespec/ which could be cool if it reaches wide adoption.

This one just crossed my feed today: Cadl, "... a language for describing cloud service APIs and generating other API description languages, client and service code, documentation, and other assets."

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/