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.