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 !

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?

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

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

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.

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.

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...

@cas--

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.

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

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.

Related: #1274

This related PR has been merged #5011 and it at least gets rid of the always changing sha256 hash in the lockfile.

This related PR has been merged #5011 and it at least gets rid of the always changing sha256 hash in the lockfile.

Unfortunately, not yet! That was related to conda packages. But we are working on removing input hash from pypi too: #5174

Could this be considered solved by #5607 ?

I think so yes! Feel free to reopen if thats not the case.

Navigation Menu

Repository navigation

Leave out development package out of lock file #2512

Problem description

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Leave out development package out of lock file #2512

Description

Problem description

Activity

ruben-arts commented on Nov 19, 2024

olivier-lacroix commented on Nov 19, 2024

ruben-arts commented on Nov 20, 2024

ruben-arts commented on Nov 22, 2024

matrss commented on Mar 13, 2025

cas-- commented on Apr 4, 2025

uwu-420 commented on Apr 24, 2025

tdejager commented on Apr 24, 2025

dhirschfeld commented on Apr 24, 2025

tdejager commented on Jun 2, 2025

uwu-420 commented on Dec 16, 2025

nichtmacho commented on Jan 2, 2026

uwu-420 commented on May 13, 2026

baszalmstra commented on May 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions