New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for plugins that provide a new subcommand #2600
Conversation
(cc @edolstra) |
Looks good to me, could you resolve the merge conflict? BTW we could also get rid of libmain (i.e. merge it into src/nix) since it's not really useful anymore now that we have a single binary. |
Do we already truly have a single binary? Isn't |
@7c6f434c Yep, all those are symlinks to |
In order to make it actually possible to implement plugins that define custom subcommands, `RegisterCommand`, `Command`, and derived classes should be in a library, not in the `nix` executable. Specifically, with this change: * It is now possible to `#include <command.hh>` from a plugin. * Executables, other than `nix` itself`, will no longer crash if a plugin that uses `ReigsterCommand` is loaded. Fixes NixOS#2597
This way plugins can be initialised and subcommands added to the list even after an instance of `MultiCommand` is created.
Before this change plugins were initialised only after resolving the subcommand, so providing a subcommand from a plugin was not possible.
bca5e5f
to
3b265b4
Compare
Rebased. |
@edolstra ping! |
👋 |
:( |
Could this be done without moving BTW the flakes branch introduces a couple of nested subcommands ( |
I think, it can be done, but why though? Many plugins will want to parse commands and, in particular, work with installables, so it makes sense to have this code in the library. |
|
I marked this as stale due to inactivity. → More info |
I closed this issue due to inactivity. → More info |
This feature has been documented for quite some time but never really worked. Now it does.
The only visible change is that previously plugins were loaded after all of the command line was parsed (so, obviously, subcommands provided by plugins were ignored), now they are loaded after the subcommand name has been parsed and right before the subcommand is resolved. Therefore, the
plugin-files
option has no effect if it comes after the subcommand name. Ideally, a warning should be issues in this case, but I have no idea how to do this.See also #2597.