Skip to content

fix(global): do not re-expose executables that already have a custom exposed name - #7104

Open
GhostMinerPlus wants to merge 6 commits into
prefix-dev:mainfrom
GhostMinerPlus:fix/global-update-custom-exposed-name
Open

GhostMinerPlus wants to merge 6 commits into
prefix-dev:mainfrom
GhostMinerPlus:fix/global-update-custom-exposed-name

Conversation

@GhostMinerPlus

Copy link
Copy Markdown

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:

Error:   × couldn't update 1 environment

  ╠─▶ Exposed name jupyter already exists

Project::sync_exposed_names with ExposedType::All (which is also used for Ignore) 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, because Manifest::add_exposed_mapping only 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 All branch 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_1 fixture:

pytest tests/integration_python/pixi_global/test_global.py -k custom_exposed_name
# this branch: 1 passed
# pixi 0.81.0: 1 failed - "Exposed name jupyter already exists"

Manual reproduction: install jupyter into two global environments (pixi global install --channel <non_self_expose_channel_1> jupyter and pixi global install ... --environment custom --expose jupyter-custom=jupyter jupyter), then run pixi global update custom.

Also verified locally: cargo build --release -p pixi (Windows, MSVC) and ruff format/ruff check pass.

AI Disclosure

  • This PR contains AI-generated content.
    • I have tested any AI-generated content in my PR.
    • I take responsibility for any AI-generated content in my PR.

Tools: Other

Fix "pixi global update" failing with "Exposed name ... already exists" when two global environments expose the same executable (one of them under a custom exposed name); add a regression test.

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added sufficient tests to cover my changes.

…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".
@lucascolley lucascolley added bug Something isn't working area:global labels Oct 1, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:global bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug(global): Exposed name already exists when using a custom exposed name

2 participants