-
-
Notifications
You must be signed in to change notification settings - Fork 610
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python 2 package is added to Python 3 dependency list using pip-compile #558
Comments
Can't reproduce this (Ubuntu 16.04, Python 3.5.2, pip-tools 1.9.0). Are you sure that you compiled the requirement file with Python 3? Try removing the txt file and running |
Also, try with the In would actually make sense, as @MHLut Please check with what @suutari-ai said, and then try clearing your cache, and tell us about the result. If you could save the verbose output of you different attempts (both failed and successful), that would be really helpful for us to pinpoint the exact cause for the future. It's the 3rd time in a short while we get reports of this. I'd really like to know the exact cause to do something about it. |
@suutari-ai The file was compiled in a Python 3 virtualenv on a machine that never even has contained an installation of Python 2. I have removed the @vphilippon I have run the command with a rebuild and verbose flag. The full results of my compilation can be read in the attached text file. Look at line 50 in the file to see the point where it's first (wrongly) asserted that there is a dependency on |
Can't reproduce either, using Python 3.6.2 in a Docker container. Could you try simply running |
@vphilippon Installation of this package goes well on my local venv (a new P3.6) and inside my Docker container (P3.4). $ pip install django-auth-ldap==1.2.10
Collecting django-auth-ldap==1.2.10
Using cached django_auth_ldap-1.2.10-py3-none-any.whl
Requirement already satisfied: pyldap in ~/.virtualenvs/python3/lib/python3.6/site-packages (from django-auth-ldap==1.2.10)
Collecting django (from django-auth-ldap==1.2.10)
Downloading Django-1.11.5-py2.py3-none-any.whl (6.9MB)
100% |████████████████████████████████| 7.0MB 198kB/s
Requirement already satisfied: setuptools in ~/.virtualenvs/python3/lib/python3.6/site-packages (from pyldap->django-auth-ldap==1.2.10)
Collecting pytz (from django->django-auth-ldap==1.2.10)
Using cached pytz-2017.2-py2.py3-none-any.whl
Installing collected packages: pytz, django, django-auth-ldap
Successfully installed django-1.11.5 django-auth-ldap-1.2.10 pytz-2017.2 You are correct that this is very much like #552. I did try the solution presented in that issue, but this did not solve the problem for me. For now I have manually removed the dependency line from the .txt file. Will test this setup on another workstation later, to see whether the issue occurs there as well. |
@MHLut I noticed your If |
@vphilippon Both on my local Python 3.6 environment and Python 3.4 Docker container I get the same result when running the installation instructions. As you can see below, the Py3 wheel is used: $ pip install django-auth-ldap==1.2.10 --no-cache --ignore-installed
Collecting django-auth-ldap==1.2.10
Downloading django_auth_ldap-1.2.10-py3-none-any.whl
Collecting pyldap (from django-auth-ldap==1.2.10)
Downloading pyldap-2.4.37.tar.gz (303kB)
100% |████████████████████████████████| 307kB 10.8MB/s
Collecting django (from django-auth-ldap==1.2.10)
Downloading Django-1.11.5-py2.py3-none-any.whl (6.9MB)
100% |████████████████████████████████| 7.0MB 21.8MB/s
Collecting setuptools (from pyldap->django-auth-ldap==1.2.10)
Downloading setuptools-36.4.0-py2.py3-none-any.whl (478kB)
100% |████████████████████████████████| 481kB 13.2MB/s
Collecting pytz (from django->django-auth-ldap==1.2.10)
Downloading pytz-2017.2-py2.py3-none-any.whl (484kB)
100% |████████████████████████████████| 491kB 18.3MB/s
Installing collected packages: setuptools, pyldap, pytz, django, django-auth-ldap
Running setup.py install for pyldap ... done However, the Note: I've just realised I neglected to mention that the dependency list also contains the Py3 package. So both packages mentioned in line Attached to this comment is the output of |
I used a Fedora 26 Docker image and updated to Python 3.6.2 to try and reproduce this, and I can't. I just realised that when using |
I'm also wondering if there could still be some part of Python 2 tool chain installed, e.g. pip or virtualenv. Another thing that could affect the results is if there is some environment variable affecting pip configuration or a pip configuration file present. Can you copy-paste the output of these commands for us? # activate the problematic virtualenv first
ls -l $VIRTUAL_ENV/bin
ls -l /usr/bin/{python,pip,virtualenv}*
head -n1 $VIRTUAL_ENV/bin/pip
head -n1 /usr/bin/pip
ls -l ~/.config/pip/
ls -l ~/.pip/
ls -l /etc/pip.conf
env | grep PIP_ Also it seems that if a new virtualenv is created with a |
I just fixed a very similar problem with Prequ. See Prequ PR #12. It was caused by commit 4900c7c, which isn't part of pip-tools 1.9.0 though. (First pip-tools version which has it is 1.10.0.rc1.) Are you sure you're using pip-tools 1.9.0? |
@suutari-ai I looked at the PR you linked and your analysis makes a lot of sense. But here's a thing: So, unless someone is pointing to Maybe the issue is with a something related to hashes or platforms, but included in |
OK. I don't really know anything in the 1.9.0 code base that would cause similar behaviour and that's why I was guessing that this could be a newer code. Or maybe the cache was built with newer code? (If a broken pip-tools is used to compile incorrect dependencies, they will be cached and won't be recalculated until the cache is purged.)
That's one of the reasons why I maintain my own fork of pip-tools, Prequ. (Another reason is that there's no new releases.) |
Funnily enough, I am facing opposite problem after upgrading to
For issue to be reproduced reliably I had to clear caches (via |
And I can reproduce too with python 2.7 on Windows. We need to check if the feature of generating hashes on all platform can be fixed an kept, or removed. @jdufresne maybe you can give some input here. |
I wonder if it would be possible to somehow fake what the platform is instead? Doing a quick search (did not actually go through script in detail), there's some script that does something similar. |
Can someone provide an easy to follow bash script to reproduce? Here is what I'm running, but it works fine. I'm first clearing all caches. The Here is my test script: #!/bin/bash
set -x
cat requirements.in
rm -rf ~/.cache/pip
rm -rf ~/.cache/pip-tools
rm -f requirements.txt
rm -rf venv
python3 -m venv venv
venv/bin/pip install --upgrade pip setuptools
venv/bin/pip install pip-tools
venv/bin/pip-compile -o requirements.txt requirements.in
rm -rf venv
python3 -m venv venv
venv/bin/pip install --upgrade pip setuptools
venv/bin/pip install -r requirements.txt Here is the output running this. Commands are prefixed with a "+":
|
@jdufresne I took you script and adjusted it for python2, and I reproduced (in a Docker container: python:2.7) : (Edit: First execution did not clear cache, fixed it)
Output
It's hard to make 100% reproducible case, as I'm not sure of the pattern used to select the wheel when multiple are detected as ok. |
I think the non-deterministic part of this is the following line in candidates_by_version = lookup_table(all_candidates, key=lambda c: c.version, unique=True) This builds a lookup table of the candidates by version. An unordered set of InstallationCandidate objects is assigned for each version. The py2 wheel, py3 wheel and tar.gz packages are in this set. The best candidate is then selected from this set using You can try to set environment variable |
@suutari-ai In my case, the But what you explained happens almost exactly in
I'll try and use a context manager to keep the monkeypatch of "Wheel" only in the context of |
Another resolution difference between With The issue should be reproducible with |
@azaghal Seems like the same issue yes, assuming you're on Linux. |
Yep, Gentoo 64-bit. |
I've got something working that fixes this while keeping the feature from #520. |
…endencies Respect platform's wheels for dependencies (Fixes #558)
First of all, thanks for looking into this and fixing it :) Now, what's the chance of getting a patch release out that includes this fix, since it does make it troublesome to use 1.10.x? |
@azaghal We're currently unable to make releases, as the PyPi upload has been deactivated for all project part of Jazzband at the moment (see #531 and jazzband/help#64). That's in the hands of the admin/roadies right now. As soon as we're able to make new releases, it will be my pleasure to make one (believe me, I'm waiting for it too). |
Ho-hum, that sounds even slightly scary. Thanks for letting me know what's up, much appreciated :) |
Issue occurs in conjunction with django-auth-ldap.
django-auth-ldap
requires different LDAP packages, depending on whether Python 2 or 3 is used. As defined insetup.py
:When using
pip-compile
to compile a list of dependencies on a Python 3 environment, the Python 2-compatible package (python-ldap
) is added to the list. This results in a broken application when all dependencies are installed throughpip
.Environment Versions
4.12.9-300.fc26.x86_64 GNU/Linux
)Steps to replicate
base.in
and add at least the following dependencies (non-related packages have been omitted):Note: The resulting file should now contain a line like
python-ldap==2.4.42 # via django-auth-ldap
.pip install -r /path/to/base.txt
.Expected result
I expect all packages to install without errors.
Actual result
The following error occurs:
Note here that my
base.txt
file is calleddependencies.txt
in the snippet above. This is because the file is renamed and used in a Docker environment.When I remove the line
python-ldap==2.4.42 # via django-auth-ldap
from by dependency file manually, all packages are installed without any error.The text was updated successfully, but these errors were encountered: