Using a relative path in `tool.uv.sources` add the absolute path in `pixi.lock`

[gabrieldemarmiesse]

Checks

• [x] I have checked that this issue has not already been reported.

• [x] I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

I made a minimal repro in a repo: https://github.com/gabrieldemarmiesse/pixi-bug-repro

git clone https://github.com/gabrieldemarmiesse/pixi-bug-repro.git
cd pixi-bug-repro
pixi run echo hello
cat pixi.lock | grep "my-subdir @"

The pixi.lock ended up with absolute path in it. Unlike the uv.lock. It makes it impossible to track it with git.

Issue description

pixi.lock should never have absolute path in it because it makes it impossible to share with other devs. In my project this happened by using

[tool.uv.sources]
my-subdir = { path = "my_subdir" }

I created a dummy repository to reproduce the bug, hopefully it will help.

Note that uv doesn't have this behavior, so it's fine to reference python packages present in subdirectories with uv.

Expected behavior

Like uv, when referencing a relative path in the pyproject.toml, an absolute path should never go in the pixi.lock, otherwise it's impossible to re-use it on another computer.

Related to

• https://github.com/prefix-dev/pixi/issues/1295

[tdejager]

Yes I've actually seen this in another issue as well: https://github.com/prefix-dev/pixi/issues/4573

[tdejager]

Sounds like something we should fix.

[tdejager]

Okay, so I checked how uv does it. If you use tool.uv.sources. In this example I had a package called 'a', that I overrode with a local click version, then you get something like:

[[package]]
name = "click"
version = "8.3.dev0"
source = { directory = "click" }
dependencies = [
    { name = "colorama", marker = "sys_platform == 'win32'" },
]

[package.metadata]
requires-dist = [{ name = "colorama", marker = "sys_platform == 'win32'" }]

[package.metadata.requires-dev]
dev = [
    { name = "ruff" },
    { name = "tox" },
    { name = "tox-uv" },
]
docs = [
    { name = "myst-parser" },
    { name = "pallets-sphinx-themes" },
    { name = "sphinx" },
    { name = "sphinx-tabs" },
    { name = "sphinxcontrib-log-cabinet" },
]
docs-auto = [{ name = "sphinx-autobuild" }]
gha-update = [{ name = "gha-update", marker = "python_full_version >= '3.12'" }]
pre-commit = [
    { name = "pre-commit" },
    { name = "pre-commit-uv" },
]
tests = [{ name = "pytest" }]
typing = [
    { name = "mypy" },
    { name = "pyright" },
    { name = "pytest" },
]

[[package]]
name = "package-a"
version = "0.1.0"
source = { editable = "package-a" }
dependencies = [
    { name = "click" },
]

[package.metadata]
requires-dist = [{ name = "click", directory = "click" }]

So no absolute paths :)

The main problem is that rattler_lock uses pep508_rs requirements directly in the PyPI requires_dist section, this by default does not allow relative paths. My assumption is that this causes us to default to absolute paths. Because in the uv -> open-souce conversion code, these will probably be converted. There are specific extensions though that do allow this with the open-source crates.

So my goal here is minimal lock-file changes, keep that in mind. So for @baszalmstra I propose we:

1. Try to enable these extensions for pixi and rattler_lock. (uv has them on by default).
2. Refactor code in rattler_lock to allow for this, should not be much, some tests would be nice.
3. Refactor code in pixi to allow for this as well, this is going to be a lot more code that will be touched.
4. If this does not yield the results that we want (there is a reason why uv did not go for this probably). We need to change the required_dists types.