The current CLI in Cachi2 was largely a consequence of how things were done in the original Cachito web API. With more package managers being added, its limitations are starting to show. We should take some time to revisit the CLI design, change what is not working currently and make it more future-proof before we release Cachi2's first stable version.
Some topics that could be improved are:
JSON provides a terrible UX if the user is actually typing the commands in the terminal. We can provide a better input method for such cases, and we could keep JSON for more complex/automated scenarios.
Some gomod flags are currently global to the fetch-deps command, but should instead be handled at package-level.
The inject-deps command could benefit from allowing additional options. For example, in #522, the generated .repo files can be expanded with additional options, and this could be done in the inject-deps command instead of fetch-deps.
The package managers could have options that affect all of its input packages, insead of only one of them. For example, in #522, the options.dnf.repoid option affects the repofile for that specific repoid, and for this reason, is not bound to an specific input package.
The log output of the commands can be enhanced to be more easily readable by folks using Cachi2 in a local enviroment. We could have a very high level output showing only the overall workflow for each package manager being executed in a request, and only show actual detailed logs if a flag was turned on (which should be on by default in Konflux).
These are just some ideas from the top of my head, feel free to add more to this issue.
The current CLI in Cachi2 was largely a consequence of how things were done in the original Cachito web API. With more package managers being added, its limitations are starting to show. We should take some time to revisit the CLI design, change what is not working currently and make it more future-proof before we release Cachi2's first stable version.
Some topics that could be improved are:
fetch-depscommand, but should instead be handled at package-level.inject-depscommand could benefit from allowing additional options. For example, in #522, the generated .repo files can be expanded with additional options, and this could be done in theinject-depscommand instead offetch-deps.options.dnf.repoidoption affects the repofile for that specific repoid, and for this reason, is not bound to an specific input package.These are just some ideas from the top of my head, feel free to add more to this issue.