pip-tools: Second level dependencies missing on for local file packages on >= 6.3.1

Hi, thank you for the great tool!

There seems to be a regression with 6.3.1 (and 6.4.0). Dependencies of dependencies don’t make it to the final result when using local packages.

Below is script to reproduce, problem seems to be in pip-tools as any recent tested versions of pip (21.3 and 21.2.4) produce them same problem.

Note : Tested with absolute files to remove the problematic relative files handling issues.

Environment Versions

  1. OS Type: Reproduced in OSX and a python:3.8-buster docker image
  2. Python version: Python 3.8.6
  3. pip version: pip 21.3 from /private/tmp/pip-tools/venv/lib/python3.8/site-packages/pip (python 3.8)
  4. pip-tools version: pip-compile, version 6.4.0 && pip-compile, version 6.3.1

Steps to replicate

#!/usr/bin/env bash -x

mkdir /tmp/pip-tools && cd /tmp/pip-tools

mkdir -p project-a
cat > project-a/setup.py <<EOF
#!/usr/bin/env python
from setuptools import setup
setup(
    name="project-a",
    version="0.1",
    install_requires=[
      "pip-tools",
    ]
)
EOF

mkdir -p project-b
cat > project-b/setup.py <<EOF
#!/usr/bin/env python
from setuptools import setup
setup(
    name="project-b",
    version="0.1",
    install_requires=[
      "project-a",
    ]
)
EOF

cat > requirements.in <<EOF
file:///tmp/pip-tools/project-a#egg=project-a
file:///tmp/pip-tools/project-b#egg=project-b
EOF

virtualenv venv
venv/bin/pip install -U "pip==21.3"

venv/bin/pip install -U "pip-tools==6.3.0"
venv/bin/pip-compile -v requirements.in  # Has all reqs

venv/bin/pip install -U "pip-tools==6.3.1"
venv/bin/pip-compile -v requirements.in  # Has no sub reqs

venv/bin/pip install -U "pip-tools==6.4.0"
venv/bin/pip-compile -v requirements.in  # Has no sub reqs

Expected result

# This file is autogenerated by pip-compile with python 3.8
# To update, run:
#
#    pip-compile requirements.in
#
click==8.0.3
    # via pip-tools
pep517==0.11.0
    # via pip-tools
pip-tools==6.4.0
    # via project-a
project-a @ file:///tmp/pip-tools/project-a
    # via
    #   -r requirements.in
    #   project-b
project-b @ file:///tmp/pip-tools/project-b
    # via -r requirements.in
tomli==1.2.1
    # via pep517
wheel==0.37.0
    # via pip-tools

# The following packages are considered to be unsafe in a requirements file:
# pip
# setuptools

When it works, verbose log shows round 2 as

New dependencies found in this round:
  adding ('click', '>=7', [])
  adding ('pep517', '', [])
  adding ('pip', '>=21.2', [])
  adding ('setuptools', '', [])
  adding ('wheel', '', [])
Removed dependencies in this round:
------------------------------------------------------------
Result of round 2: not stable

Actual result

# This file is autogenerated by pip-compile with python 3.8
# To update, run:
#
#    pip-compile requirements.in
#
project-a @ file:///tmp/pip-tools/project-a
    # via
    #   -r requirements.in
    #   project-b
project-b @ file:///tmp/pip-tools/project-b
    # via -r requirements.in

When it doesn’t work, verbose log shows round 2 as

New dependencies found in this round:
  adding ('click', '>=7', [])
  adding ('pep517', '', [])
  adding ('pip', '>=21.2', [])
  adding ('setuptools', '', [])
  adding ('wheel', '', [])
Removed dependencies in this round:
  removing ('pip-tools', '', [])
------------------------------------------------------------
Result of round 2: not stable

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 6
  • Comments: 20 (10 by maintainers)

Commits related to this issue

Most upvoted comments

The fix is released as part of pip-tools-6.7.0.

I have the same issue with 2nd level dependencies when using git+https github dependencies instead of local ones: works with pip-tools version 6.3.0 but not with 6.3.1 or 6.4.0.

I can also confirm that #1507 fixes the problem.

What needs to happen to get some movement on this? #1519 has had a fix for this for quite some time now and it’s a clear regression in pip-tools behavior between <=6.3.0 and 6.3.1+. We’re currently just using 6.3.0 and having to manually comment out the stream assertion error in pypi.py (lol). Our structure is a constraints file some ordered .in files:

### base.txt
sqlalchemy < 2.0

### src.in
-c base.txt
-e file:src/our-core-lib#egg=our-core-lib
-e file:src/our-web-app#egg=our-web-app

Here is our src.txt in 6.3.0:

### src.txt IN 6.3.0
-e file:src/our-core-lib#egg=our-core-lib
  # via
  #    -r src.in
  #    our-web-app
-e file:src/our-web-app#egg=our-web-app
  # via -r src.in
alembic==1.7.6
  # via our-core-lib
sqlalchemy==1.4.32
  # via
  #    alembic
  #    our-core-lib
  #    our-web-app
tabulate==0.8.9
  # via our-core-lib

And here is how it changes in 6.3.1+:

### src.txt IN 6.3.1 (and 6.6.0)
-e file:src/our-core-lib#egg=our-core-lib
  # via
  #    -r src.in
  #    our-web-app
-e file:src/our-web-app#egg=our-web-app
  # via -r src.in

Almost all actual dependencies are missing from the rendered src.txt defeating the entire purpose of pip-tools.