Leave out development package out of lock file

Problem description

I'm using pixi as primary package manager for development of Python packages. It's nice to get an editable installation out of the box, once the environment is set up, thus I add this in a pyproject.toml:

[tool.pixi.pypi-dependencies]
awesome_pkg = { path = ".", editable = true }

One thing that's annoying about this, that lock file gets updated with every single commit (at least in my versioning setup, where each commit is marked with post: w.y.z.postx). Would be nice to have an option to leave this package out of lock file, so pixi.lock doesn't have to be committed to a repo every single commit. Something along the lines:

[tool.pixi.pypi-dependencies]
awesome_pkg = { path = ".", editable = true, lock = false }

Or there is another way to achieve this ?

Thanks !

[ruben-arts]

Hey @ernimd,

There currently is no way to skip a package from being included in the lock-file.

To understand the issue better, you change the version in the pyproject.toml on every commit?

No, it's automatic versioning system with hatch. So whenever I build a package and activate a shell, or recreate an environment with pixi it creates this two line diff on a package that I am actively developing. See the screenshot below.

The patch version and post commit versions are changing frequently. Would like to leave out development package out of the lock file completely, it's not a dependency, but rather the project itself.

Ofc I could just do pip install -e . instead of having it in pyproject.toml but it's a nice feature to set up a development environment with a single pixi command.

[olivier-lacroix]

Maybe keeping it in the lockfile, but without version or sha256 info would be better?

[ruben-arts]

We currently add this to run avoid running a rebuild. We could maybe only rebuild on pixi install if not already existing?

Not sure if got fully what you're saying. Even on pixi install I would rather not have the version change be recorded on the development package.

[ruben-arts]

I'm sorry, let me elaborate. To get rid of the versions we would need to change the environment validation logic. Because we currently use these on every pixi command to validate the proper existence of the lock-file and environment. When we don't have these versions we would need to reinstall on every command if we can't figure the version information out from the lock-file. So to avoid that we would need to do something like, only revalidate the environment on pixi install and not on pixi run or pixi shell to avoid reinstallations.

[matrss]

We are running into this issue with https://github.com/open-MSS/MSS as well: generally, changes to the project do not cause a change in the lock file, but changes to setup.py require a lock file change. This means that PRs touching e.g. setup.py cause CI to fail with a "lock-file not up-to-date with the workspace" error.

IMO editable installations should not include version information or a hash, rather they should mean "always use the current (development) version at that path". The hash and version are misleading anyway: with MSS changes to files other than setup.cfg, setup.py, or pyproject.toml do not necessitate a lock file update, even if that change is to mslib/version.py, meaning the version information in the lock file is no longer correct.

[cas--]

This is quite frustrating that simply any change to pyproject.toml results in a new sha256 hash. As matrss mentions this doesn't apply to any other source files.

I think a partial workaround for me is to separate out the pixi config to pixi.toml to reduce the scope of changes that might generate a new hash in pyproject.toml.

It seems straightforward that the sha256 should be dropped from pixi lock file for editable packages. This is how uv lock files work:

[[package]]
name = "testpkg"
version = "0.1.0"
source = { editable = "." }

The version on the other hand is a different issue...

[uwu-420]

I'd also argue for leaving out the sha256 hash for editable dependencies. The uv example shown by @cas-- above shows that nicely.

About versions, uv had to face a similar issue here astral-sh/uv#7533 which might be a starting point.

[tdejager]

To be more specific, when investigating that thread, this seemed to be the PR that changed things for dynamic versions: astral-sh/uv#10622

[dhirschfeld]

I'm running into this also as I have dynamic versioning with hatch.

Not storing the hash, or using a magic, static, made-up hash for editable installs sounds like a good option.

I'm seeing this behavior in a pixi install -e <env> where it's redundant work which actually makes it slower than a simple pip install, so it would be great if the editable installed packages could just be ignored.