Skip to content

fix: don't uninstall PyPI files that a conda package now owns - #6920

Draft
baszalmstra wants to merge 1 commit into
prefix-dev:mainfrom
baszalmstra:fix/6902-conda-owned-pypi-files
Draft

fix: don't uninstall PyPI files that a conda package now owns#6920
baszalmstra wants to merge 1 commit into
prefix-dev:mainfrom
baszalmstra:fix/6902-conda-owned-pypi-files

Conversation

@baszalmstra

@baszalmstra baszalmstra commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Description

Moving a PyPI dependency to the conda side leaves the package half-deleted: the .py files are gone but some data files survive.

When that was the last PyPI dependency of the environment, on_python_interpreter_change sees an empty set of PyPI records and cleans out site-packages. The old PyPI .dist-info is still sitting there, and its RECORD lists exactly the paths the conda package just wrote, so we uninstall the freshly installed conda files. Only the files that differ between the two versions survive, which matches the symptoms in the issue.

Before uninstalling a distribution we now look up its RECORD entries in the conda paths registry we already build for the clobber warnings. If a conda package owns any of them, only the stale .dist-info is removed and the files are left alone. The registry is built after we know there is something to uninstall, so the common "environment has no PyPI dependencies" path does not pay for it on every run (~15 ms on a 109-package env).

Entries of an installed distribution need slightly different handling than a wheel RECORD: they are relative to the directory holding the .dist-info and the PEP 427 .data/<scheme>/... entries have already been spread out by the installer. Hence from_installed_record next to from_wheel_record.

Fixes #6902

How Has This Been Tested?

cargo test -p pixi_install_pypi, with three new unit tests for mapping installed-RECORD entries onto conda's prefix-relative form: a plain entry, a ../../../bin/<script> console script that escapes site-packages but stays inside the prefix, and entries that escape the prefix or are absolute.

I did not manage to build an integration test for the full move-to-conda flow, so that path is reasoned about rather than verified. Please check it closely.

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: Claude

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.

@baszalmstra
baszalmstra force-pushed the fix/6902-conda-owned-pypi-files branch from 5b6753e to fe42e45 Compare August 28, 2026 10:25
When the last PyPI dependency of an environment moves to the conda side,
the PyPI updater sees an empty set of records and cleans out
site-packages. The leftover `.dist-info` of the old PyPI package is still
there, and its RECORD lists exactly the paths the new conda package just
wrote, so uninstalling by that stale RECORD deletes the freshly installed
conda files and leaves a half-empty package behind.

Before removing an installed distribution we now look up its RECORD
entries in the conda paths registry. If a conda package owns any of them,
only the stale `.dist-info` directory is removed and the files are left
alone.

Fixes prefix-dev#6902
@baszalmstra
baszalmstra force-pushed the fix/6902-conda-owned-pypi-files branch from fe42e45 to e9893c4 Compare August 28, 2026 10:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Updating pypi-dependency to a conda one results in broken python package in env

1 participant