Unexplainable ContextualVersionConflict

[1313e]

Not sure how I am going to describe this, as I cannot find any way to reproduce this on my own machine, but for some reason, on Travis CI for Python 2.7.15, pip fails to uninstall the already present numpy v1.16.0 and install the requested numpy<1.16.0,>=1.12.0.
The build job can be viewed here: https://travis-ci.com/1313e/PRISM/jobs/178432270

I know that when running on Travis CI on Linux, it automatically comes with NumPy 1.16.0, which is incompatible with what I want to test for Python 2.7.
Therefore, when installing all requirements, it should uninstall that version and install a version that satisfies the condition (which is v1.15.4).
Until today, it did this perfectly fine and it still does on my machine(s).
However, for some odd reason, it does not do that anymore and simply throws an ContextualVersionConflict.

The only thing I changed today is that I combined two requirements files into a single one.
One has a package requirement that simply requires NumPy (emcee), while the other has the version restrictions.
This does work perfectly fine on my machine(s), even in fresh environments, so I am a bit confused why this pops up all of a sudden.

I know this may seem a bit of a weird issue, as I cannot give any way or method to reproduce the error, but I hope somebody knows what the problem is here.

Edit: It seems that this problem affects both pip v18.1 and v19.0.2.

[pradyunsg]

Does this also occur with pip 19.0.2 and updated setuptools / wheel?

[1313e]

@pradyunsg Yup, it occurs with that as well: https://travis-ci.com/1313e/PRISM/jobs/178462602

[cjerdonek]

Never mind, I see from the Travis CI that this occurred with pip 18.1

[1313e]

@cjerdonek What do you mean?
In the second job output I showed, the same error was produced while using pip v19.0.2.

[cjerdonek]

What happened is that I couldn't tell from your original report without digging into the Travis CI details whether your issue was limited to pip 19.0 and up. But digging in I saw the first report was about 18.1. (It's always a good idea to include the affected pip versions in the issue report text itself.)

[1313e]

Alright, yeah, forgot about that.
It happens for both v18.1 and v19.0.2.

[uranusjr]

I did some digging, and this seems to happen only when you

• Use Travis’s default environment
• Have an existing installation of package X
• Perform an editable install of package Y requiring an incompatible X

This is the minimal reproducible case I came up with:

# setup.py
from setuptools import setup

setup(
    name='pip-conflict-travis',
    install_requires=['six>=1.0.0,<1.11.0'],
)

# Failing .travis.yml
language: python
python: '2.7'

install:
  - python -m pip install six==1.11.0
  - python -m pip install -e .

script:
  -

As mentioned previously, this is only reproducible on Travis. The problem also does not exist if you create your own virtual environment; the following works:

# Working .travis.yml
language: python
python: '2.7'

install:
  - virtualenv --python=$(which python2.7) venv
  - ./venv/bin/pip install six==1.11.0
  - ./venv/bin/pip install -e .

script:
  -

So I am inclined to think this is a configuration on Travis’s part, and there’s not much pip can do at the moment.

[uranusjr]

Forgot to mention—The same failure can be observed on Travis with Ubuntu Trusty and pip 9.0.1 (the default runtime), so it is highly unlikely to be related to any recent packaging changes.

[1313e]

@uranusjr Interesting.
I already had the feeling it was Travis that was causing this problem, but nevertheless, it still feels to me like pip has something to do with it as well.
After all, why would it fail to parse in the requirement properly?

Also, before, I did not have this problem.
The only difference is that now pip will check for both requirements at the same time, while before they were done separately (two pip install -r requirements.txt calls instead of one containing the other).

Forgot to mention—The same failure can be observed on Travis with Ubuntu Trusty and pip 9.0.1 (the default runtime), so it is highly unlikely to be related to any recent packaging changes.

I agree, but it might be an indication that there is a long-living problem somewhere.

[cjerdonek]

Some suggestions:

• What happens if you run pip freeze in the Travis environment both before and after the pip install six==1.11.0 line?
• What do you see when you enable more verbose logging?
• What directory is Travis installing packages into?
• Does this also affect 3.x versions on Travis?