feat: add pixi extensions command

[pavelzw]

closes #3958

[Hofer-Julian]

Let's make sure that we add docs and tests before we merge it

[ruben-arts]

To be honest, I don't see the huge benefit of adding this to the CLI. pixi search "pixi-*" will give you a similar list.

The hard-coded ness of this makes it even less feature rich, as I also see this as something companies will do for their own private tooling.

[Hofer-Julian]

To be honest, I don't see the huge benefit of adding this to the CLI. pixi search "pixi-*" will give you a similar list.

You might misunderstand what this CLI does 🙂
It shows you all pixi extensions on your system, not the ones available from a conda channel.

The hard-coded ness of this makes it even less feature rich, as I also see this as something companies will do for their own private tooling.

We were pondering alternative ideas to have nice descriptions. Considering there are only a limited number of pixi extensions, we felt it was fine to hardcode descriptions in the Pixi code. pixi extensions would still work for other extensions, it would just not show a description.

I'd be happy to hear ideas how this could be made more flexible without adding a lot of complexity.

[ruben-arts]

Ah, I did indeed misunderstand.

It seems like there is not really a standard for this logic yet.

Seeing that git gh cargo helm docker kubectl all have a different approach.

If we go for extention(s) I would at least like to think about the sub commands we would be planning. If the answer were "None", I'm not convinced it make sense to make it a sub command.

[pavelzw]

our preferred solution would have been adding this to pixi --help. but injecting arbitrary code into there that is only executed when actually running --help is apparently not trivial and would require rewriting the --help command :/

[ruben-arts]

Yeah that's correct, clap-rs/clap#3166 this issue still has me on the edge of my seat. As that would enable so much more.

But If there's ever the idea of adding the pixi ext command, I would want to avoid this PR to be merged in favor of that.

Would value @nichmor and @mrswastik-robot's input for this, as they are working on the full implementation.

[nichmor]

tbh, I'm against hardcoding any known extensions' description in pixi itself and would rely on just discovering them from the path.

It would then raise the discrepancy questions of - why extension a has a description while b doesn't, how one becomes a well-known extension, and when we stop adding them

Regarding the extensions subcommand, I don't have anything planned for other subcommands, and I do think that we can just show them in pixi --list ( in the end as a separate subtable ). It would then keep all available actions of Pixi ( and its extensions ) in one place rather than split across multiple commands

[Hofer-Julian]

It would then raise the discrepancy questions of - why extension a has a description while b` doesn't, how one becomes a well-known extension, and when we stop adding them

Do you think we'd need to gate keep this? I would have just accepted every single submission.

I don't have anything planned for other subcommands, and I do think that we can just show them in pixi --list ( in the end as a separate subtable )

I still think that a subcommand makes more sense than a flag like cargo --list.
It doesn't change the behavior of an existing command, but it's, well, its own command.

[Hofer-Julian]

But If there's ever the idea of adding the pixi ext command, I would want to avoid this PR to be merged in favor of that.

What would this command do @ruben-arts?

[nichmor]

I still think that a subcommand makes more sense than a flag like cargo --list.
It doesn't change the behavior of an existing command, but it's, well, its own command

I feel that it is too much to introduce a new subcommand just for listing...

[nichmor]

Do you think we'd need to gate-keep this? I would have just accepted every single submission.

I don't think we need to gate-keep this, but I think it would still go through a review. And if the extension is not-good ( based on some criteria ), it would not be added in Pixi.
I believe docs are a better place to explain the extensions. I think it is just not scale - imagine having 30-40 extensions hardcoded there

[Hofer-Julian]

I believe docs are a better place to explain the extensions. I think it is just not scale - imagine having 30-40 extensions hardcoded there

Honestly, would be fine by me.

But I am not at all fixated on hard-coding anything.

What I would like though is that we have some CLI, which gives descriptions for extensions. Where Pixi gets them isn't all too important too me as long as it's not too much work for us or the extension developers.

Side-note: cargo hardcodes descriptions too. They seem to limit it to certain extensions, though. cargo clippy has a description, cargo insta does not.

[ruben-arts]

What would this command do @ruben-arts?

Stole that from gh, I just want to push it in the discussion to make sure there are no ideas for it yet. I don't think the gh ext makes sense for pixi as it's already a package manager.

[Hofer-Julian]

I don't think the gh ext makes sense for pixi as it's already a package manager.

Yeah, agreed :)

[ruben-arts]

What about augmenting the pixi call to print both help and include a section with the extensions.

[Hofer-Julian]

What about augmenting the pixi call to print both help and include a section with the extensions.

Sounds good to me!