Why do Lockfiles contain -e file:.?

[sykloid]

The requirements.lock files generated by rye are almost exactly what I need, but I always need to sed out the first package line, since the package I'm developing at the moment is never something I want to install when I'm thinking in terms of the dependencies of that same package.

This led me to ask this question -- under what circumstances is including the current directory in the lockfile correct, or useful?

[bluss]

-e is editable install and file:. is the current directory. If I understand correctly, the assumption is that the rye user is developing a python package, and thus it needs to be installed to be used.

Why is it that you don't need to install the package?

Issue #236 lists a wish for workspace-only projects where you don't have a python package in the project.

[sykloid]

As one example: #239 (comment)

Especially when setting up a CI environment in multiple stages, I frequently need to install only the dependencies of a project, without installing the project itself -- that task is done in a later phase.

At a higher level, I'm trying to understand what the semantics of the lockfile are supposed to be -- For a file whose intention is to pin specific versions of packages, having a blanket "also install the package in this directory" seems counterintuitive.

[bluss]

It looks like the lockfile is the install list for pip, so then it's dual purpose in that sense - both the install list that rye can feed to pip, and a lockfile for the project.

If you have a workspace, every participating project will be listed, so there will be more than one -e line in that case. I guess that makes the purpose more clear to us. It sounds to me like it would be sensible to separate the two lists. The whole backend that resolves deps and installs packages might also be switched from pip-tools to something else, if I read the issues right, and the lockfile construction would probably change at that point anyway.