Repository navigation
fix(global): do not re-expose executables that already have a custom exposed name - #7104
Open
GhostMinerPlus wants to merge 6 commits into
Open
GhostMinerPlus wants to merge 6 commits into
GhostMinerPlus wants to merge 6 commits into
Conversation
…custom exposed name The scenario: two global environments depend on the same package, one exposes the shared binary under its own name and the other under a custom exposed name. Updating used to fail with "Exposed name <binary> already exists".
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
pixi global update <env>fails when two global environments depend on the same package and one of them exposes the shared executable under a custom exposed name:Project::sync_exposed_nameswithExposedType::All(which is also used forIgnore) adds an exposed mapping for every executable of the environment's direct dependencies, using the executable name as the exposed name, and does not skip executables that the environment already exposes - possibly under a custom exposed name. The extra mapping then collides with the identically named expose of the other environment, becauseManifest::add_exposed_mappingonly ignores the environment the mapping is added to.This PR filters out executables that are already exposed in the environment before adding new mappings, so the
Allbranch only adds "new binaries that are not yet exposed", as its comment already promised.Fixes #7101
How Has This Been Tested?
Added a regression test reusing the existing
non_self_expose_channel_1fixture:Manual reproduction: install
jupyterinto two global environments (pixi global install --channel <non_self_expose_channel_1> jupyterandpixi global install ... --environment custom --expose jupyter-custom=jupyter jupyter), then runpixi global update custom.Also verified locally:
cargo build --release -p pixi(Windows, MSVC) andruff format/ruff checkpass.AI Disclosure
Tools: Other
Checklist: