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.

[hmaarrfk]

one year later, i just feel like this is a reasonable request.

you may disagree, but please take this as empowering a user of yours to avoid making a fork for something that the original creators of Anaconda/conda felt was a gap too:

For the "base environment" there is something special to consider.

Feel free to close this at this point, but I think this is a minor expansion of the scope, that has the capabilities to really help maintain one of your users.

[hmaarrfk]

and i'll put conda-forge/menuinst-feedstock#67 up as a token of me being a good "steward" of open source.

[jaimergp]

This one feels like it belongs in a different PR.

[jaimergp]

What is the criteria for adding the base-or-not dict to some fields but not others, simple necessity as of now? What's the update story for the inevitable moment when someone wants to add them to more places? Will we have more variables in this hardcoded conditional at some point?

If we accept to do this, I see ourselves going into the direction of generalised recipe.yaml-style if: / then: dictionaries, with some predefined runtime variables, and then accept those anywhere not just in a perhaps-arbitrary fashion.

That aside, we'll need to:

• Add tests and examples
• Update documentation
• Add news

[hmaarrfk]

What is the criteria for adding the base-or-not dict to some fields

necessity is pretty close to my decision making process.

Do note that this whole "I install things in my own conda environment inside a whole operating system) is somewhat new.

These things also end up being somewhat "public" at the interface between different subsystems that try to help with identification (by humans or other code)

• name: I want to be able to toggle more information for developers than for non-developers (who would install in base)
• command: depending on how WMClass gets set, it may be necessary to change this based on the same criteria (perhaps you add a flag like --wmclass).
• StartupWMClass: I really want to be able to set one of my environments as the "default" and so differentiating between the windwos of the different environments is critical, and this is thus needed.
• TryExec: as command

So if something doesn't end in (env_name), likewise it would make sense if the Exec and other thigns didn't have -base at the end of them. For symmetry

If we accept to do this, I see ourselves going into the direction of generalised recipe.yaml-style if: / then: dictionaries, with some predefined runtime variables, and then accept those anywhere not just in a perhaps-arbitrary fashion.

Understood. I don't see this as a problem. We have all been working toward better system integration. I see the present solution as a step in enabling that.

That aside, we'll need to:

Add tests and examples
Update documentation
Add news

I will ping again when this is ready.

[jaimergp]

Understood. I don't see this as a problem. We have all been working toward better system integration. I see the present solution as a step in enabling that.

Agreed, but I'd like to avoid the intermediate steps so we don't have to support too many different schemas, although this particular one may not be a big burden.