Closed mrclary closed 11 months ago
@jaimergp, perhaps this is a bug in constructor
? Maybe it's not supplying _mode='system'
to menuinst.api.install
?
Hey! Thanks for the report. Technically, menuinst
should "detect" whether the installation is for a single-user or not via the presence of .nonadmin
file in the conda installation root (see this block).
This used to be Windows-specific and I don't think I have added this logic in constructor
, so the bug is indeed in constructor
😬 We need figure out a way to detect whether the installation is single-user or all users and add the .nonadmin
file accordingly.
I'll mention the issue in the relevant PR there, thanks!
@mrclary - this commit should be enough to create the .nonadmin
files: https://github.com/conda/constructor/pull/474/commits/3f0b97bfc5b43441f2271b4c67df3c952d078e16.
However, thinking about it, they were not being created before, which means that something is also off in menuinst
(which should have understood that the installations were admin-like).
I found this only in the legacy code for Windows. Nothing like this in platforms/base.py:Menu
or the platform modules. I have not tested admin install on Linux, and I don't recall checking the shortcut location for the admin install for Windows. So it is possible that shortcut locations for all platforms are created in a user-specific location...
It's here, in the elevate_as_needed
decorator (which I want to rewrite anyway):
Aahh, then perhaps this preceding clause is the problem? https://github.com/conda/menuinst/blob/237e259a752e49d38bb256135ade6ce9ada36e01/menuinst/utils.py#L315-L316
Spot on! 🎯
Checklist
What happened?
@jaimergp, when selecting "Install on a specific disk..." from a package installer created by
constructor
(to install for all users) on macOS, the environments are created in the correct place but the application bundle is created in~/Applications
instead of/Applications
.Conda Info
No response
Conda Config
No response
Conda list
No response
Additional Context
No response