Miniconda installer cannot install Start Menu items on windows

[mcg1969]

First posted as https://github.com/conda/conda/issues/782; thank you to @asmeurer for directing me here instead.

Miniconda does not install menuinst; and as a result, it does not install Start Menu items even though it says it will. And because of the known filelock issue, menuinst cannot be installed after the fact.

Therefore, it seems that one of two things should happen (my vote is for the first):

• menuinst should be one of the packages included with miniconda.
• The installer text that claims that a Start Menu item will be created should be removed.

[asmeurer]

Miniconda is supposed to be just conda and its dependencies, the bare minimum that you need to get going with conda.

Also, I don't think menuinst makes much sense without the packages that are going to be installed, like ipython notebook, which aren't included in miniconda.

[mcg1969]

Well yes, but I would argue that menuinst is part of the bare minimum that you need to get going with conda. The installer uses menuinst to create a Start Menu item with the proper paths set so that you can properly use conda.

[mcg1969]

Obviously, you don't see this if you allow Miniconda to modify your global path. But if you don't want to do that---and I think there are good reasons why not, which is why the installer rightly gives you the choice---then you need some other way to fire up a solid conda environment for further installations and environment creation.

[ilanschnell]

menuinst is a small package, I wouldn't mind if it was part of Miniconda.

[asmeurer]

Does it makes sense, though? What exactly does it do?

[ilanschnell]

It installs the menu items and desktop shortcuts (on Windows only for now). So it would only be included in the Miniconda on Windows.

[mcg1969]

What about dependencies? If menuinst in turn depends on too many other modules I could understand a reluctance to include it. But the installer is attempting to use it! (How about this: could Miniconda designate some modules as helpers for the installer only, that are deleted once the installer is complete?)

[asmeurer]

But the shortcuts to what? I thought the menu shortcuts were only for things that Miniconda doesn't come with (like ipython).

[asmeurer]

My preferred solution would be to:

• Fix the confusing text in the installer
• Make it so that conda install menuinst works and does the right thing.

I'm not clear why the second thing cannot work. The file lock only pertains to removing or updating packages.

This is somewhat similar to https://github.com/conda/conda/issues/107 for letting the modification of the registry happen independently of the installer.

[mcg1969]

The shortcut I am asking the installer to build is the one it says it will build: a link to a command shell with the proper paths and/or environment variables set, so that I can type commands like "conda install etc" and begin building a full environment.

Here's an exercise: install Miniconda on a machine that does not yet have it. Make sure to uncheck the box specifying that Python should be added to your global path. Now open a command shell and try to use conda.

This is very similar to shortcuts created, for instance, when installing the Microsoft Visual Studio SDK. You don't necessary want the environment variables and paths set always, just when you want to actively use it. So the SDK creates a shortcut to a shell with those variables set.

It is not enough to simply fix conda install menuinst, because it doesn't help to install it after the fact.

[mcg1969]

But the shortcuts to what? I thought the menu shortcuts were only for things that Miniconda doesn't come with (like python).

Yes, this is the source of your confusion. Anaconda does create shortcuts to some of the programs it installs, but it also creates a shortcut that fires up a command shell with the paths set. That is the shortcut that Miniconda should be enabled to install as well.

[asmeurer]

Oh ok.

[mcg1969]

Also: I'm not sure why conda install menuinst is ignore/skipped. What I'm reading is that it has something to do with the Windows 'filelock' issue, but I don't see what that affects its installation (and if it does, why it doesn't affect it when creating a new environment). But if it cannot be installed after the fact, that's all the more reason to include it in the installer, so that you can create those menu shortcuts for ipython, etc. when installing these packages manually.

[asmeurer]

I also don't understand why the filelock would prevent it from being installed. I thought it only pertained to updating or removing packages.

[ilanschnell]

The filelock wouldn't prevent it from being installed, but when we first added the menuinst dependency to conda, Miniconda did not exist yet, and it was easiest to ignore (installing/removing/updating) menuinst entirely. We chould maybe allow installing menuinst.

[mcg1969]

I don't understand it either. Again, if you are going to enable the creation of the start menu item to open a conda-friendly shell, then menuinst must be included. I really would like to have had that menu item so that's my preference!

If you want to do a bit more work---and who doesn't? :-)--- then you include label menuinst but then remove it once installation is complete. That's something that could potentially benefit the full Anaconda installer too, with any other package that is downloaded primarily to support the installer.

[H0R5E]

This issue also reveals some ambiguity in the way that conda build works. Contiuum allows the installation of graphical packages that set up windows shortcuts through conda install. For instance, within the recipe for spyder is a file called menu-windows.json which I believe uses menuinst to add windows menu shortcuts.

Yet there is no mention of menuist within the conda build documentation so, for my binstar pacakges, I have to write some obscure vba to get the same outcome. Then, if I did start using menuinst I would have to tell all potential users to avoid miniconda as it could not be used to install the distributed package.

So, in conclusion, if miniconda does not contain menuinst then it probably shouldn't contain conda. Or conda should not be allowed to install GUI packages.

And please document menuinst + conda build some more, pretty please. Muchas muchas gracias. :)

[ddale]

I would also like to request that menuinst be part of the core set of packages installed by anaminiconda, and that http://conda.pydata.org/docs/build.html should document how to use it. (I've tried using the approach seen in the ipython and spyder recipes at conda/conda-recipes, but have not been successful.)

[cmaes]

I ran into this issue as well. I installed Miniconda and was surprised to see it did not install a shortcut to a shell in the Start menu (even though the installer said it would). I'd like to request that the confusing text in the installer be removed, or menuinst be included so Miniconda could add something to the Start Menu.

[msarahan]

Pending fix:

conda/conda#1699 ContinuumIO/menuinst#4 conda/conda-recipes#439 https://github.com/conda/conda-env/pull/178

[H0R5E]

d:\Usuarios\108630>conda info
Current conda install:

             platform : win-64
        conda version : 3.19.1
  conda-build version : 1.19.0
       python version : 2.7.11.final.0
     requests version : 2.9.1
     root environment : C:\Anaconda  (writable)
  default environment : C:\Anaconda
     envs directories : C:\Anaconda\envs
        package cache : C:\Anaconda\pkgs
         channel URLs : https://conda.binstar.org/t/<TOKEN>/topper/win-64/
                        https://conda.binstar.org/t/<TOKEN>/topper/noarch/
                        https://repo.continuum.io/pkgs/free/win-64/
                        https://repo.continuum.io/pkgs/free/noarch/
                        https://repo.continuum.io/pkgs/pro/win-64/
                        https://repo.continuum.io/pkgs/pro/noarch/
          config file : d:\Usuarios\108630\.condarc
    is foreign system : False

So, the situation is now that when upgrading packages that need permissions to install (update?) windows menus it will request an increase in permissions with a dialogue box. That's good. Unfortunately, there are some bad things too.

Mainly, I don't want these packages to try to install menu shortcuts outside of the root environment. Maybe some people want that, but I use so many environments that it would be nice to turn off that behaviour. I am also worried that its not clear which environment the menu shortcuts are associated to, if you have the same package in more than one (I guess the last to be installed, and that if you uninstall, the links to the other environment will not be rebuilt).

[msarahan]

Agreed, with lots of environments it kind of breaks down. I think the next iteration of this is to create a folder for each environment's shortcuts inside the anaconda folder.

Shortcuts should have the environment name appended to the end of the shortcut name. If the string is too long and Windows cuts it off, then we need a different way (probably the folder solution)

If you name your environments starting with an underscore ( _env_name ) then shortcuts will not get installed. A more explicit flag would be better. I'll add an issue for that. https://github.com/conda/conda/issues/2089

[gansanay]

Hi,

This so-called feature is exactly what I would like to avoid. My builds and tests are distributed to gitlab-runner instances on windows hosts, and not only it messes with their Start Menus, which is unwanted, but it also fails:

INFO menuinst_win32:__init__(182): Menu: name: 'Anaconda${PY_VER} ${PLATFORM}', prefix: 'D:\Multi-Runner\builds\XXX', env_name: 'XXX', mode: 'None', used_mode: 'user'
INFO menuinst_win32:folder_path(73): WARNING: menuinst key: 'start'
                 path: 'C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\Windows\Start Menu\Programs'
     .. excepted with: 'PathNotVerifiableException' in knownfolders.py, implementing workarounds ..
INFO menuinst_win32:folder_path(98):      .. due to lack of 'check_other_mode' not picking
        non-excepting path of 'C:\ProgramData\Microsoft\Windows\Start Menu\Programs'
 in knownfolders.py
INFO menuinst_win32:folder_path(73): WARNING: menuinst key: 'quicklaunch'
                 path: 'C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch'
     .. excepted with: 'PathNotVerifiableException' in knownfolders.py, implementing workarounds ..
menuinst ExceptionINFO menuinst_win32:__init__(182): Menu: name: 'Anaconda${PY_VER} ${PLATFORM}', prefix: 'D:\Multi-Runner\builds\XXX', env_name: 'XXX', mode: 'None', used_mode: 'user'
INFO menuinst_win32:folder_path(73): WARNING: menuinst key: 'start'
                 path: 'C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\Windows\Start Menu\Programs'
     .. excepted with: 'PathNotVerifiableException' in knownfolders.py, implementing workarounds ..
INFO menuinst_win32:folder_path(98):      .. due to lack of 'check_other_mode' not picking
        non-excepting path of 'C:\ProgramData\Microsoft\Windows\Start Menu\Programs'
 in knownfolders.py
INFO menuinst_win32:folder_path(73): WARNING: menuinst key: 'quicklaunch'
                 path: 'C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch'
     .. excepted with: 'PathNotVerifiableException' in knownfolders.py, implementing workarounds ..

My main concern is at the moment: how do I disable it?

[stevengj]

This is also a problem for us in Julia, where we use miniconda to install an "internal" miniconda distro in order to supply dependencies, and our internal miniconda installation should not be user visible in the Start menu: https://github.com/JuliaPy/Conda.jl/issues/147

Has anyone figured out a way to prevent the miniconda installer from touching the Start menu?

[msarahan]

If your environment name starts with an underscore, no shortcuts are installed. There's also a flag for conda, but that doesn't help with miniconda. On my phone, so I can't look it up easily, but look through the output of

Conda install -h

And

Conda create -h

If you need a flag for the installer itself, please consider submitting a PR to GitHub.com/conda/constructor

[stevengj]

Beginning an environment name with an underscore doesn't seem applicable to installing the root environment?

A flag for the installer itself would be ideal. Unfortunately, I'm not a Windows user myself, so hacking and testing the NSIS files are a bit difficult for me.