Remove `editable` from the lock-file

[baszalmstra]

Problem description

Currently, the lock-file stores whether a Pypi package should be installed as editable or not. However, this has some downsides:

• If you change a package from editable to non-editable or vice-versa, the lock file has to be regenerated.
• Whether a package is editable or not is not defined in the name but it is currently stored in the package data part of the lock file. E.g.

  - kind: pypi
    name: foo
    version: 0.1.0
    path: foo
    sha256: 5eb7d27a464b108fef2bb090ef1d2f62a2750e7bd625c70d2b00ef3f19a2edf7
    editable: true

  This means that for every environment the package is now editable.

I see two solutions:

1. Add editable to a per environment section (similar to extras) and remove it from the package data. This still requires the lock file to be regenerated if the editableness of a package changes.
2. Remove it from the lock-file all together. This means we have to check at installation time if the package needs to be "re-installed".

I think I'm in favor of option 2 but I'm curious about other people's opinions.

[tdejager]

Also @pavelzw this would fix the some of the issues you were facing as well. Where you include them into the same solve group.

[baszalmstra]

It does slightly break one of the goals of the lock-file:

//! * To be complete. The lock-file should contain all the information needed to recreate
//!   environments even years after it was created. As long as the package data persists that a
//!   lock-file refers to, it should be possible to recreate the environment.

But I think its fine because the environment is still valid, just not perse editable.

[glemaitre]

I'm facing this issue. I don't know if an opt-in/out option to track the SHA of the editable package would make sense.

I can see use-case that you want to track the exact package installed through the SHA or sometimes, you are in a dev setting where the editable is your current project in development where you don't want to bother with this info.

[noamgot]

@baszalmstra Any news on this one?
I just encountered this problem where the sha256 of my (editable) package is the only change in my pixi.lock file....

[cas--]

There is a related/duplicate issue; #2512

As I commented there, the sha256 should be dropped since should not be required and creates lockfile churn.

[pmeier]

We recently switched our dev envs to pixi and are using setuptools-scm. This means whenever you run pixi without the --frozen argument on a feature branch, the pixi.lock file changes. Meaning, unless people know about this and explicitly revert the change, we are seeing a diff on every single PR, e.g. here.

I'm very much in favor of removing editable packages from the lock file. Note that uv recently did the same for basically the same reason. See astral-sh/uv#7533 and astral-sh/uv#10622.

[tdejager]

Yeah this makes a lot of sense to me. So I think we should take the version into account when resolving but leave it out of the lock. I think only in the case of a dynamic version, I'm guessing that's what uv is doing when reading the PR description.

Then we should maybe also emit both the editable Boolean and the sha in case of an editable. But check the state of things on install.

That would give us:

1. No lock file changes when switching between editable and non-editable.
2. No resolve when changing something other than the version in the metadata. But perhaps a reinstallation.
3. When using a dynamic version, even changing the version should not trigger a re-solve. I'm not sure what would happen when this version would suddenly start conflicting with a dependency though. We might need to look closer to how uv is handling this.

As an aside:
We need to make this change so that old lock files with this info keep working.

wdyt @baszalmstra @ruben-arts?

[ruben-arts]

All for this improvement!

I'm only worried about the requirement for a resolve/installation. When do we now call for a resolve? Should pixi install or at least pixi lock still see it as not satisfied and try a resolve? My gut says yes. But we then have different behavior from pixi run and pixi shell.

[tdejager]

Sorry could you maybe re-phrase. I don't see why it should function differently for the different subcommands :)

[dhirschfeld]

I have two issues with the current behaviour:

1. In my CI when I install an env pixi is re-resolving solely because of the editable install which takes up a huge amount of time.
2. When I install an env the re-resolve updates the hash in my (committed) pixi.lock file causing git describe to show as dirty.

I would like to be able to do a pixi install --locked -e <env> and have it Just Work when I have an editable install such that no time consuming and lock-file-changing re-resolve occurs.

[tdejager]

Hey Dave! So are you using something like a dynamic version ala hatch-vcs or something? Because currently it should only re-solve when the metadata of the editable changes. Otherwise it's another bug :)