Pip upgrades dependency installed as `flit install --symlink` editable install.

pip version

20.3.1

Python version

3.9.1

OS

Arch Linux

Additional information

No response

Description

Installing a project B that depends on a project A will modify A’s installation without need.

This is specifically problematic when A is installed in editable/develop mode using flit install --symlink.

I assume pip treats editable installs in a magic special way, but doesn’t identify symlinked installs as editable.

Expected behavior

Pip should not downgrade dependencies, especially not development dependencies

How to Reproduce

$ conda create -yn flit-deps python=3.8 flit
$ conda activate flit-deps
$ git clone https://github.com/theislab/scanpy.git && cd scanpy
$ git switch flit || true  # go to the flit branch if it hasn’t been merged int master yet
$ flit install -s --dep=develop  # Make development install of scanpy
$ pip install scvelo  # Install project that depends on scanpy

Output

...
  Attempting uninstall: scanpy
    Found existing installation: scanpy 1.8.0.dev49-ge715cd98
    Uninstalling scanpy-1.8.0.dev49-ge715cd98:
      Successfully uninstalled scanpy-1.8.0.dev49-ge715cd98
...
Successfully installed loompy-3.0.6 numpy-groupies-0.9.13 scanpy-1.7.0 ...
...
# Development version of scanpy has now been uninstalled in favor of an older stable version

Code of Conduct

• I agree to follow the PSF Code of Conduct

[uranusjr]

Sounds like we have figured out the problem here and the fix to it. Thanks for everyone involved here! I’ll close this and continue the work at Flit’s side. Feel free to open further issues if more is needed from the pip side to make this work.

[sbidoul]

Actually flit install with --symlink and --pth generate proper dist-info metadata (and a direct_url.json like this {"url": "file:///tmp/foobar", "dir_info": {"editable": true}}, /tmp/foobar being the project location).

I’ve not tried this example, but with a sample flit project, both pip freeze and pip list generate something meaningful in such a situation.

So at first sight I’d think all the necessary standard-based information is present for pip to work properly.

I’m not too sure what’s happening here. It looks like pip is downgrading scanpy ?