Make pip freeze respect the command that was used to install a local editable package

[csimmons0]

Environment

• pip version: 19.0
• Python version: 3.6
• OS: macOS 10.13.6

Description
Pip freeze does not respect the way that a local editable package was installed. I thought that 19.0 was supposed to fix this issue, but it doesn't.

Expected behavior
After I run "pip install -e ./generated/sisu_backend/", I expect the output of "pip freeze" to include the line "-e ./generated/sisu_backend/". Instead, the output of pip freeze varies depending on where I am when I run the commands.

If I am outside of any repository:

# Editable install with no version control (sisu-backend==1.0.0)
-e /Users/csimmons/notarepo/generated/sisu_backend

If I am inside a repository that does not have a remote set:

# Editable Git install with no remote (sisu-backend==1.0.0)
-e /Users/csimmons/arepo/generated/sisu_backend

If I am inside my local copy of the sisudata/core repository:

-e git+git@github.com:sisudata/core.git@df51b0d8f0a8176ad081fe95b8d3b96b59ce60c0#egg=sisu_backend&subdirectory=webapp/generated/sisu_backend

What I want is just the following:

-e ./generated/sisu_backend

For some context, my company has a Flask app in this sisudata/core repo, and that Flask app has this sisu_backend package, which is generated using openapi-generator, as one of its dependencies. This generated code is checked into the repo.

How to Reproduce
Do the following outside of any VCS, inside a git repo with no remote set, and inside a git repo with a remote set:

1. Install a local project as editable in the manner pictured in the documentation: https://pip.pypa.io/en/stable/reference/pip_install/#editable-installs
2. Run pip freeze.

Output
Attached are the results of the command below run in each of the three contexts outlined above:

{ pip --version && pip freeze && pip install -e ./generated/sisu_backend/ && pip freeze; } &> piptrace_in_a_repo.txt

piptrace_not_in_a_repo.txt
piptrace_in_a_repo_no_remote.txt
piptrace_in_a_repo.txt

[cjerdonek]

What I want is just the following:
-e ./generated/sisu_backend

Relative paths in requirements files are problematic because then the file would only be valid when pip is run from a particular directory. For example, see #6112 ("Requirements file which contains -e with a relative local path, is only installable from a specific directory") and #3772 ("Pip should interpret relative paths in requirements.txt relative to requirements.txt") for related discussion, as well as #4300 ("-e install uses remote Git repo instead of local files").

Instead, the output of pip freeze varies depending on where I am when I run the commands.

It seems like what you're suggesting would cause the output to vary because the path to the project would depend on what directory you run pip freeze from. With an absolute path, the output of pip freeze will be the same no matter which directory you run it from.

Also, whether a path or URL is outputted shouldn't depend on where you run the command from. That's a function of whether the project is under version control, and whether the repo has a remote URL or not.

[cjerdonek]

A couple other comments now that I understand better what you're suggesting (at first I thought you just wanted the requirements paths to be relative):

First, an editable install doesn't currently record anywhere how it was installed, so pip wouldn't have access to the path ./generated/sisu_backend/. See for example this comment by @dstufft on issue #4300 making a similar request that he closed:

a git checkout that was pip installed as a path is indistinguishable from a git checkout that was pip installed as a git clone

Second, if pip did what you suggested, it seems like this could easily result in requirements files that don't work from any directory. For example, if you were in a directory foo containing two projects package1 and package2, and then you did this.

1. pip install -e ./package1
2. cd ..
3. pip install -e ./foo/package2

Then the requirements file would look like--

-e ./package1
-e ./foo/package2

But this wouldn't work from any directory because the two relative paths would be relative to different directories.

[csimmons0]

@cjerdonek Thanks for the response. I think you've already considered the issue I'm facing in your discussion of #4300; feel free to close this.

[cjerdonek]

@csimmons0 Okay, thanks for your suggestion and for your understanding. FWIW, I agree with you that absolute paths aren't the best for certain scenarios (e.g. checking in to source control for sharing with others). Perhaps for your use case you can have a post-processing step where you replace the absolute paths with relative paths as desired.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.