Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MENU_ITEM_LOCATION is incorrect for all-user installation on macOS #137

Closed
2 tasks done
mrclary opened this issue Jun 21, 2023 · 7 comments
Closed
2 tasks done

MENU_ITEM_LOCATION is incorrect for all-user installation on macOS #137

mrclary opened this issue Jun 21, 2023 · 7 comments
Labels
locked [bot] locked due to inactivity type::bug describes erroneous operation, use severity::* to classify the type

Comments

@mrclary
Copy link

mrclary commented Jun 21, 2023

Checklist

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

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

@mrclary mrclary added the type::bug describes erroneous operation, use severity::* to classify the type label Jun 21, 2023
@mrclary
Copy link
Author

mrclary commented Jun 21, 2023

@jaimergp, perhaps this is a bug in constructor? Maybe it's not supplying _mode='system' to menuinst.api.install?

@jaimergp
Copy link
Contributor

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!

@jaimergp
Copy link
Contributor

@mrclary - this commit should be enough to create the .nonadmin files: conda/constructor@3f0b97b.

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).

@mrclary
Copy link
Author

mrclary commented Jun 29, 2023

used_mode = (
mode if mode else ('user' if exists(join(self.prefix, u'.nonadmin')) else 'system')
)

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...

@jaimergp
Copy link
Contributor

It's here, in the elevate_as_needed decorator (which I want to rewrite anyway):

if not (Path(base_prefix) / ".nonadmin").exists():

@mrclary
Copy link
Author

mrclary commented Jun 29, 2023

Aahh, then perhaps this preceding clause is the problem?

menuinst/menuinst/utils.py

Lines 315 to 316 in 237e259

if os.name != "nt":
return func

@jaimergp
Copy link
Contributor

Spot on! 🎯

@github-actions github-actions bot added the locked [bot] locked due to inactivity label Jul 24, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked [bot] locked due to inactivity type::bug describes erroneous operation, use severity::* to classify the type
Projects
Archived in project
Development

No branches or pull requests

2 participants