Replies: 0 comments 4 replies
-
We clearly need to improve documentation for some of the commands (eg. sources which I somehow missed adding to the docs). But I don't think we can (or should) move it someplace else for RHEL8. Continue to improve what's needed in the rhel8-branch of lorax. In Fedora 34 lorax-composer has been dropped, but the composer-cli subpackage remains. We should move that to osbuild in Fedora 34, and add my new go version as a branch to that repo so it can be worked on in the same place as the existing code. ETA: Do we want to rename it? Now would be the best time, but I don't have any better suggestions. |
Beta Was this translation helpful? Give feedback.
-
I ended up moving it and rewriting it :) https://github.com/osbuild/weldr-client |
Beta Was this translation helpful? Give feedback.
-
Motivation:
The only CLI client for Weldr API is
composer-cli
from the lorax repository. Given that osbuild-composer became available in both the latest RHEL and the latest Fedora, it would make sense for the osbuild organization to take ownership of the command line client so that we can quickly respond to reported issues.These are examples from Red Hat Bugzilla and Github issues:
composer-cli
does not communicate with the user and if it does, it does not contain anything useful [1]:We should solve these problem as soon as possible because there is no alternative client (Cockpit does not have all the features composer-cli has).
[1] composer-cli poor error handling and messages: https://bugzilla.redhat.com/show_bug.cgi?id=1900659
[2] composer-cli needs to have some decent examples: https://bugzilla.redhat.com/show_bug.cgi?id=1915353
[3] composer-cli has a poor user experience: osbuild/osbuild-composer#1105
Approach
Create a new repository with
composer-cli
only. Make an RPM package out of it, for exampleosbuild-composer-cli
which would provide thecomposer-cli
binary and it would conflict withcomposer-cli
RPM package which is built as a subpackage oflorax
.Draft new user interface with helpful messages and implement it in the current code base. For example:
Keep the current output format when invoked with
--json
as that one works fine.Alternatives
Write a completely new client, for example https://github.com/bcl/weldr-client. If we started from scratch and took our time to do a proper research on available libraries, we could generate most of the code like parsing command line arguments (this is only partial in composer-cli), bash/zsh/fish completions, HTTP client code (if we wrote OpenAPI spec for Weldr API) and probably more. The clear downside of this approach is that we would for sure broke someone's workflow by changing some details in how composer-cli works. Nevertheless we can start by the approach described in the section above and continue with this alternative in the future.
Prototype
Ripping only
composer-cli
from thelorax
repository should be straight forward as the repo is well structured and the code for client and server part is separate. I tried it myself and I can execute composer-cli from thesrc
directory:https://github.com/msehnout/osbuild-composer-cli
Beta Was this translation helpful? Give feedback.
All reactions