CMD shell activation changed in `conda 25.3.0`

[kenodegard]

Checklist

• [x] I added a descriptive title
• [x] I searched open reports and couldn't find a duplicate

What happened?

The CMD shell activation was modified in conda 25.3.0 to support users using Windows AppLocker with script restrictions enabled.

Xref https://github.com/conda/conda/issues/13610 Xref https://github.com/conda/conda/pull/14607

This change results in conda shell.cmd.exe activate * no longer producing a dynamic .bat script to be executed but rather produces an ini-style .env file to be consumed by the CONDA_ROOT\condabin\_conda_activate.bat.

To support conda 25.3.0+, menuinst's manual calls to conda shell.cmd.exe activate * need updating to properly handle activation, e.g.:

https://github.com/conda/menuinst/blob/7e1aa1fc445935d25f7d22cf808b68d41fa6956c/menuinst/platforms/win.py#L271-L283

This change is likely the cause of the recent failures:

• https://github.com/conda/menuinst/actions/runs/14110630226/job/39528799895?pr=319

Conda Info

Conda Config

Conda list

Additional Context

No response

[kenodegard]

To catch these issues earlier in the menuinst should include conda-canary in its test matrix and probably run the tests on some regular schedule

[marcoesters]

Agreed on the canaries. This is a breaking change for menuinst because old versions of conda do not use this kind of logic. So, we will have to implement a different activator depending on the conda version.

[marcoesters]

I think the only way we can fix this is by replicating the behavior of _conda_activate.bat because there is no guarantee that an activation file exists in the base prefix or the target prefix (for example when creating an environment with conda-standalone).

Based on the cross-referenced PRs, I do not see a way how the .env file can be consumed directly. We can parse the information in the .env file when the shortcut is installed. I'm not sure if there is a need for conda to be called directly whenever the shortcut is executed.

This is, of course, brittle. Changes to the parsing logic in conda must be ported to menuinst, but unless conda provides an interface to the new activation file format, I see no other option.

[kenodegard]

An alternative would be for us to revert the change in conda and to introduce a new activator for the new format (e.g., conda shell.env ...)

@jezdez thoughts?

[marcoesters]

This is how this would more or less look like as it stands: https://github.com/marcoesters/menuinst/blob/cea4bffc1221e4f52ed19c30c74e7ec820337781/menuinst/platforms/win.py#L271-L320

[jezdez]

That would be more compatible, and users wouldn't be impacted by it. I think I like that idea, @kenodegard

[marcoesters]

In that case, we would still need logic to differentiate between the old and new format inside menuinst.

Wouldn't using a .bat file activator with a random name just shift the AppLock problem from conda to menuinst if we kept with the old format (i.e., conda <shell> activate)? Maybe parsing that file is actually the more sustainable way to move forward.

[kenodegard]

yes that would shift the AppLocker problem from conda to menuinst

but that would alleviate the pressure of needing to solve the problem right now for the current miniconda release

[marcoesters]

If the AppLocker problem is shifted to menuinst, Miniconda would still not function though since the prompts are part of the installation. I think solving this problem here, too, is the best way forward.

[marcoesters]

Even though, I'm not sure if any of the shortcuts use the activate property, so we might be getting away with it.

[marcoesters]

I thought about this more and I think this needs some sort of way to create callable files from the conda activator or we have to duplicate the activation code in menuinst.

Parsing the .env file statically in menuinst is certainly possible since it's just a set of SET and CALL commands. But doing this in menuinst at install time like in my branch would freeze the activation behavior to the conda version at install time.

Right now, if a user updates conda in the base environment, the activation behavior of the shortcut would use the updated conda version. I think this is the behavior we want. So, the activator probably has to stay.

[marcoesters]

but that would alleviate the pressure of needing to solve the problem right now for the current miniconda release

I looked through the Anaconda feedstocks and none of the recipes there use the activate feature. So, this is not a release blocker.

However, I did find some conda-forge recipes that use it:

• https://github.com/conda-forge/mne-feedstock/blob/08355b8a5cd76fec2ae7d4e3d16245fdc754da5a/recipe/menu/menu.json
• https://github.com/conda-forge/mss-feedstock/blob/d6b3fe18b921814abc507856c7ca923cfe3cd98b/recipe/menu.json
• https://github.com/conda-forge/hyperspyui-feedstock/blob/cfa177e37c8ef86670a3dc7227eb5c6332eb47e0/recipe/menu.json
• https://github.com/conda-forge/helios-menuinst-feedstock/blob/8fef758f6d04c50d34d9e0140c6fe135cffdd718/recipe/src/menu.json

So, this should block a new release of conda-standalone since it ships a frozen menuinst version.