Skip to content
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

Allow plugins to modify existing commands #87

Open
fpliger opened this issue May 22, 2023 · 8 comments
Open

Allow plugins to modify existing commands #87

fpliger opened this issue May 22, 2023 · 8 comments

Comments

@fpliger
Copy link
Contributor

fpliger commented May 22, 2023

As a plugin author
I'd like to be able to modify an existing command in order to add command options, amend the description, and actually change the command using specific hooks in the command pipeline
so that I can "easily" modify the behaviour a command.

As an example:

I'd like to create a plugin that changes the create command so that it can have an additional option --from-file so that it can basically do exactly what the wrap command does today.

@fpliger
Copy link
Contributor Author

fpliger commented May 22, 2023

@mchilvers I have an almost working version for this but it's ugly... mostly because of the race condition between the Plugin manager loading the commands and the loading additional options for these very same commands.

Basically, if commands are defined at the global scope of the module we import them from like it is right now, the commands are already defined when it comes time to load the new options. The quick ugly fix is to define the commands themselves inside the pyscript_subcommand hook.

I'll keep you posted

@mchilvers
Copy link
Collaborator

Ok, so basically the plugins need to register "factories" that create the commands? Could another option might be to make commands callable instances? They could have attributes for arguments/options etc that could be extended by plugins.

@fpliger
Copy link
Contributor Author

fpliger commented May 23, 2023

Yes. I think it'd work with command factories... but I want to try to see if we can make it a bit more straightforward.

Could another option might be to make commands callable instances?

How different than the current decorated callable do you mean?

They could have attributes for arguments/options etc that could be extended by plugins.

Yes. That's kind of the idea (I think :) )

@mchilvers
Copy link
Collaborator

When I say "factory" I mean it in the general sense.... i.e. something that when called produces something... not implying classes etc.

In out case plugins need to be able to contribute arguments/options to command factories. The factories then produce the commands on-demand for the CLI.

@fpliger
Copy link
Contributor Author

fpliger commented May 23, 2023

Ok... spoke too soon. Even if I can pass arguments around, I can't think of any possible way to make a command factory work without doing some pretty horrible 🤮 things to make it work. Even if we make it work, it'd also require adding new commands with a really ugly API.

Also, note that I couldn't find anything on the Typer side to support this type of feature.

I'll let it sit for the day and get back to it with fresh eyes tomorrow

@mchilvers
Copy link
Collaborator

G'day! Yes - I've been looking at Typer this morning... not sure it will be easy for plugins to contribute arguments etc. This is one of the problems with decorator based APIs... :(

@mchilvers
Copy link
Collaborator

Makes me wonder if we:

a) try to work how to build a truly extensible-CLI with Typer
b) just use explicit import guards to add psdc functionality :)

@fpliger
Copy link
Contributor Author

fpliger commented May 24, 2023

Yeah. Here's where my thoughts are heading. We hold this specific [very] nice feature and focus on adding features that are really must haves for the upcoming release. In the meantime, we start a discussion with the Typer folks to explore ways we can do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants