Skip to content

fix: honor workspace [cache.*] overrides for conda-pypi mapping cache#6284

Open
baszalmstra wants to merge 3 commits into
prefix-dev:mainfrom
baszalmstra:claude/adoring-babbage-8hfxM
Open

fix: honor workspace [cache.*] overrides for conda-pypi mapping cache#6284
baszalmstra wants to merge 3 commits into
prefix-dev:mainfrom
baszalmstra:claude/adoring-babbage-8hfxM

Conversation

@baszalmstra
Copy link
Copy Markdown
Contributor

Description

A [cache.pypi-mapping] path set in a workspace .pixi/config.toml was being ignored. The conda-pypi mapping cache always resolved through a global-only path, so the workspace setting had no effect; the cache kept landing on the network filesystem, and the "cache for PypiMapping is on a network/parallel filesystem" warning kept firing. The only workaround was setting PIXI_CACHE_DIR.

This makes the mapping cache respect the workspace configuration like the other caches do. As part of this, the global-only cache path is removed so all per-kind cache directories now honor workspace-level [cache.*] overrides, including for pixi clean cache.

Partly fixes #6281

How Has This Been Tested?

Added a regression test confirming a workspace-level [cache.pypi-mapping] override is honored even when the network-filesystem redirect is forced. Also verified the full test suite and build 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: 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.

claude added 2 commits June 4, 2026 13:44
…ache path

Workspace-level `[cache.*]` overrides were ignored for the conda-pypi
mapping cache because the mapping client resolved its path through a
global-only code path (the free `cache_dir_for`, reading only system +
user config). A `[cache.pypi-mapping]` set in a workspace
`.pixi/config.toml` was silently dropped, so the netfs redirect kept
firing and the "cache for PypiMapping ... is on a network filesystem"
warning persisted (issue prefix-dev#6281).

Make `MappingClient::builder` take the resolved cache path as a
parameter and resolve it through the workspace-merged config at the call
site (`project.config().cache_dir_for(PypiMapping)`), keeping the
`pypi_mapping` crate agnostic about which config layer wins.

Also remove the global-only free `cache_dir_for(kind)` entirely so per-kind
cache paths always flow through `Config::cache_dir_for`:
- `pixi clean cache` now resolves the cache config from the workspace when
  available, falling back to the global config outside a workspace.
- `DetachedEnvironments::path` takes the cache config to consult.

`GLOBAL_CACHE_CONFIG` is kept only for `get_cache_dir` (cache root).

Add a regression test that a workspace-merged `[cache.pypi-mapping]`
override wins over a forced netfs redirect.
Resolving the detached-environments directory previously required handing
the config its own cache config:

    workspace.config().detached_environments().path(&workspace.config().cache)

Add `Config::detached_environments_dir()` that resolves the path against
its own `[cache]` settings, and route all callers through it. The
lower-level `DetachedEnvironments::path` is now a private helper.
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.

cache.pypi-mapping in config.toml is ignored, only PIXI_CACHE_DIR is recognized

2 participants