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.

[lrandersson]

Hi @hmaarrfk could you provide more with more context to your use-cases?

[hmaarrfk]

Hi @hmaarrfk could you provide more with more context to your use-cases?

Lets consider installing Spyder. And I know that Spyder can be installed in one environment, then USE the python of an other, but I've never found that to be hyper reliable.

There is one usecase where you want to install spyder in 2 environments that are NOT base:

• Spyder in environment dev1
• Spyder in environment dev2

In this case, you want Spyder to show up on linux as Spyder (dev1) and Spyder (dev2) since you are a developer and understand the difference between environments.

In the case that you now wnat to ship Spyder, as a standalone application

• Spyder will be created in constructor in the "base" environment.

You don't want Spyder (base) to appear, That doesn't make much sense to the end users. You want just Spyder.

That is the main usecase and the logic I want.

I want to design different names for my application when it is installed in base (it can assume it is a standalone application), and when it is in an environment (where the (env_name) should appear to help distinguish it).

There are many "customizations" accross most of the options in menuinst that need to happen.

I would prefer to not have 2 packages to install.

[hmaarrfk]

Thanks for working to learn more about my usecase!

[lrandersson]

Hi @hmaarrfk thanks for sharing this. If the primary use case is just the name (Spyder vs Spyder (env)) I'd say that adding built-in placeholders would be the easiest. I.e.:

• Add ENV_NAME_IF_NOT_BASE placeholder that resolves to (env_name) or an empty string.
• Package authors write: "name": "Spyder{{ ENV_NAME_IF_NOT_BASE }}".
• Advantage of this is: No schema change, backward compatible, solves the common use case you have mentioned.
• Downside with this approach is that it is limited to specific patterns, can't cover all use cases in this PR (different commands, etc.)

Other ways forward could be:

1. Add IS_BASE as a built-in placeholder, but I think it would be clunky and you'd need two placeholders like IS_BASE_SUFFIX that resolve differently
2. Support this PRs dict structure BUT store the resolved value in menuinst.toml
   • At install time, menuinst resolves the dict and stores the chosen value in menuinst.toml
   • At uninstall time, menuinst reads from menuinst.toml (even if frozen menuinst can't parse the original JSON)
   • I think this would give the most flexibility for package authors, and solves the conda-standalone problem
   • It's a more complex implementation.

[hmaarrfk]

Unfortunately for me. A partial solution just isn’t enough.

I might take Jaime’s suggestion and just deal with two helper package names. This is really not ideal since I feel like what I’m asking for is a natural extension of the schema that is already here.