Expand the ability to specify parameters by is_base or not

[hmaarrfk]

In my workflow, I change a bit more than just the name depending on the environment being base or not.
This expands the functionality of #180
xref: #207

This provides those switches.

It also provides a way to "not run inside a bash shell"

Let me know if you are interested in this, I need to go through the checklist.

Checklist - did you ...

• Add a file to the news directory (using the template) for the next release's release notes?
• Add / update necessary tests?
• Add / update outdated documentation?

[jaimergp]

Hm, I'm not sure about this. The is_base bits were implemented to maintain feature parity with menuinst 1.x, but I was never a fan. Assuming you control the installer generation via constructor, if you need different commands per environment, can that be achieved with two different packages: shortcut-for-app and shortcut-for-app-in-base?

[hmaarrfk]

Your suggestion would work, and it isn’t a bad one. I might just do it.

The problem is that any application will have duplicate their menuinst packages. That’s fine for me. But will generate future annoyance for users.

I’ll try and see how it looks.

Thanks again for the reviews!

[jaimergp]

In the future, base is going to be a protected environment and apps will be recommended to ship a "default" env with their software, leaving conda in base (and nothing else), as drafted in conda-forge/miniforge#740. I anticipate those keys to be increasingly infrequent 🤞

[hmaarrfk]

But in my use case, my main app is « my application » and not conda. I want my base to be protected too ;)

this is less for miniforge, more for customized use cases.

[jaimergp]

Fair enough. Also, I think you could accomplish the same with a single package, but two build variants, with some sed replacement similar to what we do in the napari shortcut.

[hmaarrfk]

I've held off on commenting, but 1 year later i find this inconsistency to still be thorn in our setup process.

but two build variants, with some sed replacement

is pretty complicated. variants and keeping them in sync is a chore.

Would you reconsider these additions?

[marcoesters]

The dict structure has a very big drawback that I hadn't considered back then: conda-standalone comes with frozen menuinst versions, so new shortcuts that rely on an updated menuinst will fail to uninstall in the end. So, if you update menuinst in the base environment and install shortcuts with the new dictionary structure in the schema, uninstalling with the uninstaller will fail.

#477 may provide a way out though: I made a suggestion to enable the menuinst CLI to dynamically set variables at install time that will be respected by both the installation and uninstallation. This could be expanded to arbitrary placeholders, now that I think about it. Would that potentially be an alternative and more robust solution for you?

I would also move the bash details into a separate PR because it's a separate concern.

[hmaarrfk]

#477 may provide a way out though: I made a suggestion to enable the menuinst CLI to dynamically set variables at install time that will be respected by both the installation and uninstallation. This could be expanded to arbitrary placeholders, now that I think about it. Would that potentially be an alternative and more robust solution for you?

can i circle back to this after #477 is merged? it seems like a lot of changes, so i'm hopeful I'll be able to use it.