search

alire-project / alire

Command-line tool from the Alire project and supporting library
GNU General Public License v3.0
288 stars 49 forks source link

Feature request: custom commands (extending Alire) #1352

Open mgrojo opened 1 year ago

mgrojo commented 1 year ago

I was looking at whether it was possible to make a helper tool to build AppImages from crates. There is a similar tool for cargo, which might work as inspiration: https://github.com/StratusFearMe21/cargo-appimage

This tool is a cargo custom command. These are simply programs called cargo-something, which, when put on the PATH, are invoked by cargo something. I haven't found much information about this Cargo feature, but I suppose in Alire could be implemented as an automatic alias to alr exec -P -- alr-something, when alr something is invoked and:

Some custom commands could simply use the inherited environment set by alr exec to make their job. More complex tools could depend on the Alire library to read the alire.toml file or for whatever they could need. cargo-appimage seems to depend on the crates cargo-metadata and cargo-toml for that. Extension of the TOML file to include custom metadata could be needed as well (e.g. an icon is needed to make an AppImage). I don't know if this is already possible with alire.toml.

This feature would allow extending the capabilities of Alire without requiring integration with the Alire project itself, providing easy extension of the Alire ecosystem for particular needs and experimentation.

Examples of Cargo custom commands: https://crates.io/keywords/cargo-subcommand

Related issue: #1151

mgrojo commented 1 year ago

The Alire library is not in the Alire index. There isn't even a separate crate for it in the repository. Is there a plan to publish it, or do you regard it as private to the Alire project?

Without the library, the only available solution is parsing the alire.toml file or the output of alr show (which would need to wait to #1151 to get some of the metadata).

mosteo commented 1 year ago

Yes, I intend for the library part of Alire to be published at some point; it's just no need had arisen yet.

There are also plans to have something akin to cargo metadata, or getting more easily parsable info from alr, at some not too distant point I hope.

On the topic of alr-whatever extensions I'm somewhat ambivalent, as we wouldn't have any control over the quality of such extensions. I would be more confortable with something like alr ext <whatever> as the entry point. That also prevents conflicts if we later want some subcommand that is used by a popular extension.

The alire.toml currently is strict about unknown entries, but that would be easily solved by likewise having some [extensions] entry which were completely ignored by us.

So, to summarize:

mgrojo commented 1 year ago

It makes sense to invoke the extensions with a specific subcommand and not pollute your subcommand name-space. In fact, I like it better in that way, I only feel a bit unconvinced about alr ext, it feels too much similar to exec and, as an abbreviation, too diffuse in meaning. Other possibilities could be alr plugin or alr custom; or even alr extension, since the user could abbreviate it as an actual alias if wanted.

Regarding arguments, I suppose the best option is just to forward the remaining arguments to the extension.

Regarding metadata, I wonder if providing them to the standard input of the program would be a good idea. For example, protoc plugins receive the information in standard input. The drawback would be that plugins wouldn't be able to use standard input for interactivity, which might be too limiting. Another options could be to receive it in the environment. Are long multi-line values portable in the environment? Or even each metadata field could be exported as individual variables (they should use a common prefix like ALR_META_). That would facilitate simple extensions implemented in script languages without any use of complex parsing or API usage.