Installing the napari bundle edits the ~/.conda/environments.txt list

[ctrueden]

After installing the napari bundle 0.4.18 on my Ubuntu Linux 23.04 system, I see two new nameless environments listed when I run conda env list:

/home/curtis/.local/napari-0.4.18
/home/curtis/.local/napari-0.4.18/envs/napari-0.4.18

I think the reason is because the ~/.conda/environments.txt gets edited to include these during the installation process. I tried deleting them again, and running the napari bundle, and it still works, because the command used under the hood is:

bash -c 'unset PYTHONHOME && unset PYTHONPATH && eval "$("/home/curtis/.local/napari-0.4.18/_conda.exe" shell.bash activate "/home/curtis/.local/napari-0.4.18/envs/napari-0.4.18")" && /home/curtis/.local/napari-0.4.18/envs/napari-0.4.18/bin/python -m napari'

which references the environment path directly. (And I guess it couldn't reference it by name anyway, since these two environments are apparently nameless.)

So, my question is: can we make the installer not hack the ~/.conda/environments.txt file?

This is certainly a very minor issue, but it seems unnecessary to modify the user state in a non-encapsulated way here.

[jaimergp]

It's not a hack, but part of conda's standard behaviour when creating new environments (which is done via constructor + conda-standalone when you run the installer).

It can be considered a "registration" step to add any conda environments into that very simple database.

[jni]

@jaimergp I think then @ctrueden's question can be rephrased as: can we avoid registering, or unregister the environment as a post-install step, without breaking anything? Or is this necessary for specific functionality? I can see how it would be confusing for users that installing an app would modify their conda env list.

At the same time, I can also see that this might be handy to help power users debug issues with the bundle.

I don't have a strong opinion here but I'd like to understand the trade offs and come up with a final decision about whether we'll leave this as-is or try to fix/mitigate in some way.

[jaimergp]

We can't add it as a general functionality in conda-standalone or constructor because proper conda installs (Miniconda, etc) do rely on that mechanism. However we can indeed add a post-install script to revert those modifications.

The actual bug is that I don't think those entries are deleted on uninstall right now, and that's something I am more inclined to fix first.

[jaimergp]

On second thought I think it's reasonable to consider a toggle in the constructor configuration. Started that work at conda/conda#12924, but it will take a few moving pieces for this to land. Namely:

• Add context option in conda: Add a config option for environment registration conda/conda#12924
• Wait for release or port PR above to conda-standalone
• Add configuration option in constructor - Add option for the new register_envs conda/constructor#716

[goanpeca]

Sounds like a great plan @jaimergp, thanks for looking into it 🚀

[jaimergp]

conda/conda#12924 was merged

[jaimergp]

Opened conda/constructor#716

[jaimergp]

This feature is now available in constructor 3.5.0 as per conda-forge/constructor-feedstock#72

We'll integrate it in the next batch of installers, so I'll leave this open til that happens.

[jni]

Amazing! 🤩