Suggestions for improvements on Windows from mboeck-altair

[hmaarrfk]

Hi everyone,

I want to thank you for your hard work around Miniforge, I really appreciate that! I wanted to share my feedback regarding the Windows experience with Miniforge, working on a Windows machine myself and having spend now a couple weeks around automated Miniforge installations and programmatic usage of it on all main OSes.

For context: We have implemented for our desktop applications an automated env management via Miniforge on all our supported platforms: Windows 10+, macOS 10.13+, modern Linux distributions (e.g. Ubuntu 22). 3rd party extensions for our platform can require any environment, and we will automatically install and use it to execute that particular code. To do this, we automatically do a headless installation of Miniforge. So I have now some experience with silent installs on all the above different systems. For macOS and Unix, this works nicely (with the sidenote caveat). But for Windows, this has been a long struggle to get it to work.

Sidenote: We do not want to interfere with a potentially existing conda installation on client machines! But this is a bit tricky because the general expectation of conda always seems to be that it is a singleton instance on a machine as it behaves as such by writing into the registry and files like .bashrc when calling conda init, forcing us to roll back those changes to avoid our own Miniforge installation becoming the system default. Not ideal, but we can revert what conda init does outside of the Miniforge installation directory. Would be nice if that was not needed at some point in the future.

Back to the topic at hand, the Windows installer: The windows installer is not robust at all. It can return simply 1 in case of errors, without logging anything. That's not nice and makes figuring out what is wrong a pain. It would be great if it can get some logging at least via flag so it prints what's wrong. But even worse: It can fail and still return 0, doing no installation at all - forcing us to manually check afterwards if it actually installed anything. One of the cases where this behavior is triggered is when the installation target path is too long (and by long I really don't mean very long at all, our QA department verified it fails exactly when the Windows username length changes from 13 to 14).

We run it with this command: cmd.exe /C start /wait "" "C:/path/to/installer" /S /InstallationType=JustMe /RegisterPython=0 /D=%LOCALAPPDATA%/Altair/MF All good when username is 13 chars or less - fails with exit code 0 if username is 14 chars or more (Windows username length limit is 20). This is probably the biggest problem in regards to the Windows installer right now, that it cannot even install on many systems if the username is not short enough.

I have one final, related question: Is there a particular reason why we cannot also have simple archive-based release artifacts in addition to the installers? I don't need the shell modifications, and as far as I saw, that's basically all the installers do?. An archive I could just extract somewhere, and then run conda init within that folder myself.

Originally posted by @mboeck-altair in #599

[hmaarrfk]

Not sure if it is an offtopic, but did you consider using micromamba (https://mamba.readthedocs.io/en/latest/installation/micromamba-installation.html) for your use case? micromamba is a self-contained .exe, so using it you should avoid any problem in installing miniforge or similar conda installers.

Originally posted by @traversaro in #599

[hmaarrfk]

Thanks for taking the time to submit this feedback!

I am not involved with the Miniforge project (I work on Miniconda), but I can help with some of these questions. The answer mostly boils down to that we need to move away from NSIS, but currently do not have enough people to completely rewrite the backend.

We do not want to interfere with a potentially existing conda installation on client machines! We run it with this command: cmd.exe /C start /wait "" "C:/path/to/installer" /S /InstallationType=JustMe /RegisterPython=0 /D=%LOCALAPPDATA%/Altair/MF

You can add /NoRegistry=1 to avoid writing into the registry. You can also add /NoShortcuts=1 to the command to not overwrite shortcuts. You can see the full list of options when you run Miniforge.exe /? or /Miniforge.exe /S /?

The windows installer is not robust at all. It can return simply 1 in case of errors, without logging anything.

Logging into a file is a problem with NSIS because of a few edge cases. Recently, constructor had a PR (https://github.com/conda/constructor/pull/847) that at least outputs to console (not stdout). That should be available with a new installer. Again, moving away from NSIS is the ultimate goal here.

This is probably the biggest problem in regards to the Windows installer right now, that it cannot even install on many systems if the username is not short enough.

This can be solved on the Miniforge end @hmaarrfk - you just need to set check_path_length to false in the construct.yaml file. I don't know if there was a reason to restrict the path length though.

Is there a particular reason why we cannot also have simple archive-based release artifacts in addition to the installers?

You might be looking for something like conda-standalone or micromamba. You can create a base environment via

conda.exe create -p %LOCALAPPDATA%\Altair\MF conda -c conda-forge

Then activate the environment in cmd.exe:

%LOCALAPPDATA%\Altair\MF\condabin\activate.bat

You can then run conda init in that environment.

Originally posted by @marcoesters in #599