backstage
beps(cli): modularization
Hey, I just made a Pull Request!
👋 , one more BEP to add to my pile 😁 . Following up on conversation in #23818.
This BEP introduces a new initial design for CLI modularization based off of my work in #24488 which proved that some level of reuse of the backend abstractions is viable for a CLI. I also added the idea of profiles to allow for more purpose driven workflows, where a user may not want to install every plugin to their CLI and they instead just want to choose a few plugins for a certain task. That may lead itself to personalization, ie having a development CLI with build, test, start, and another CLI with api [endpoint] [ref], catalog search, pagerduty page [oncall], etc.
I also wanted to design with personalization in mind, once we have a modular CLI, users may want to start using this CLI outside of their Backstage repos. That isn't solved here, but I also think it's important to provide some foundation for that work to build off of when we get there.
cc: @drodil @Rugvip
:heavy_check_mark: Checklist
- [ ] A changeset describing the change and affected packages. (more info)
- [ ] Added or updated documentation
- [ ] Tests for new functionality and regression tests for bug fixes
- [ ] Screenshots attached (for UI changes)
- [x] All your commits have a
Signed-off-byline in the message. (more info)
I like this, reminds me a lot of how golang cli's are setup and extended. I am however, gonna pass this review over to @Rugvip for some eyes too :eyes: :pray:
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
@Rugvip I had a similar thought around migration that that might fit into, removed it in the most recent draft but I agree it would be a good place to start. How should I proceed here? Do we want to merge this BEP and start working to understand what modularizing the existing CLI looks like, reduce the scope of this BEP to just modularizing the existing CLI, or start a PRFC/RFC instead?
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
I haven't had a chance to update this since we chatted about this last. A sparse tree approach seems best here, not leveraging the existing new backend infra and instead creating some custom set up instead.
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
@Rugvip Do we want to close this until cycles emerge? I can pick up some work to start modularizing the existing CLI
@aramissennyeydd to be honest I've been doing some experimentation on my side the last few weeks as I'm finding this to be more and more of a high priority for the framework. I think I'm at a point where I have a good enough idea of the kind of communication patterns that we need that I can help drive this forward fairly efficiently. I do think we want to continue with experimentation such as #27213 as the way to move this forward for the time being though.
In fact I wouldn't mind experimenting a bit with the BEP process in the meantime as well as I don't find the provisional -> implementable move to work that well right now. What do you think about keeping this BEP open with comments and changes here while we iterate and tweak the design, and eventually merge it straight into the implementable state?
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
Are we ready to start maybe adding a new module to the CLI yet? Either with clipanion or something else?
Thinking about the future of #26952 once that's ready, don't want to ship something as @backstage/scaffolder-cli for it to be instantly deprecated the next release if we're close :pray:
@Rugvip Thoughts on ^? I think we could do it as a "module" (in the same package and not yet separated out) for the @backstage/cli - we still need to figure out the installation pattern for plug + playable modules. If we did that as a "module", we'd need to have support for the old commander-based system as well.
@aramissennyeydd @benjdlambert hmm, I'm thinking we could easily ship it as a module just for the alpha CLI? That way people could access it via backstage-cli-alpha ... but that will obviously go away in the future.
I'd say the main thing to figure out regarding modularization from the PoV of a module is what and how we provide things to use. Will we for example bring in the backend service system or not?
Yeah, we could do that - probably worth chatting through what a cutover of backstage-cli-alpha to backstage-cli looks like, but it shouldn't affect the scaffolder work.
I signed up for next week's Framework SIG to chat about the missing pieces :)
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!