Allow alias commands of Plugins to be available in Parent Repo

[aronggile]

It would be nice if alias commands defined in a plugin repo could be made available in client repos either automatically or with minimal configuration. This would make it easier to build and share tools that simplify interaction with plugins.

For example, I am currently working on please plugin that provides a Terraform module, which can be used to spin up a local QEMU/KVM test environment. I would like to just import this plugin into an external project I am working on, say a Go service, and execute aliases it provides directly.

Something like,

• plz infra-up to launch the infrastructure
• plz infra-down to shut it down

Where infra-up and infra-down are aliases defined in the Terraform plugin repo.

This is better than providing additions shell script or a make file for interacting with a project that already uses please. I also think for small team driven or solo projects, where devs are expected to ware multiple hats, such a feature may be useful.

That said, given Please is a do one thing and one thing only properly type of Linuxy project, this may be outside of the project's scope. It may also present security challenges as this seems like a gateway to plz install command. Those of you with more experience can look into it, but I thought it was worth sharing.

[peterebden]

I don't think this is a security issue - if you import a plugin you pretty implicitly trust that plugin (it's running a bunch of build actions on your behalf which may be sandboxed but we don't guarantee that's any kind of strong security boundary). I do think it is pretty useful - e.g. we've talked about a plz go-get and similar that plugins might define for you. There might be a question about whether you need to opt into these but I feel like plugins should just be cautious with them.

The bigger issue is probably: when someone types plz infra-up which isn't a legal command in the first instance, how do we know how to find a plugin to see if it defines it? We probably need to load them all - maybe the logic is basically "if it's not immediately defined, try loading all preloaded subincludes then see if it does work". That could be a bit slow when you just mistype plz biuld but it seems possible to cope with that.

An alternative to all the above could be that the top-level config file has a way of opting into aliases from plugins. That would resolve a bunch of concerns but it is more fiddling about (which shouldn't be underrated, ideally the UX for these things should be nice).

@Tatskaari this seems relevant to your interests, thoughts?

[Tatskaari]

Yeah, this is something I've been musing about. I similarly want to add sub-commands to go the go plugin to generate and format targets. Once we have v17 out the door and plugins rolled out, I'd like to come back to this.

I think I'd want to hook this into the plugin system, at the very least. We'd want to have the sub-commands be namespaced so that you can plz infra up where infra is a plugin that defines an alias:

In the host repo:

[Plugin "infra"]
Target = //plugins:infra

And then in the infra subrepo:

[PluginDefinition]
Name = infra

[Alias "up"]
Command = docker compose up

Then the user can run plz infra up.

This will require a departure from the current implementation though. Currently aliases can be handled immediately after loading the .plzconfig files. If we want to be able to load config from subrepos, we'd need to spin up the full build state, and build the subrepo target, in order to get at it's .plzconfig. This is possible, but something to keep in mind.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any recent activity in the past 90 days. It will be closed if no further activity occurs. If you require additional support, please reply to this message. Thank you for your contributions.