Right... forgot pip's issue with self-updating on Windows. Amended to use python -I -m pip.

And python -I is not supported by older Python versions... sigh

OK, so now the issue is the un-vendored tox envs...

The un-vendored tests are a lie!

Because:

• tox --notest is called, creating the environment
• then we un-vendor pip (except the wheels just added to pip/_vendor are deleted too, so it would never have worked anyway)
• and then tox is run again to run the tests, but the first thing tox does is install the code to be tested (pip) from sdist, so we're back to a regular vendored pip...

So I've reworked how un-vendored jobs are handled: tox now supports 2 dedicated environments (py27-novendor and py36-novendor). making it easier to use locally for testing. Un-vendoring is done by using a custom install_command that automatically un-vendors pip each time it's installed.

But there's still an issue stemming from the fact that a subsequent tox run will use the code we tested during the preceding run when re-installing pip's current code from sdist. So we're back to the problem this PR was trying to address... This was the reason the second tox run (for the integration tests) was failing on Travis: some entries were apparently missing for proper un-vendored support (see last commit).

Anyway, I see 2 ways to make sure that the installation is always done with a stable version of pip:

• set recreate=True in tox.ini so the environment is re-created every time tox is run
• instead of using pip/python -m pip, use a copy of get-pip.py

instead of using pip/python -m pip, use a copy of get-pip.py

I would oppose such a change - it would make it difficult to run the tests without network, something I've had to do quite a few times.

The un-vendored tests are a lie!

Oh wow. This is actually a valid issue and something that needs to be fixed. I didn't check this PR yet but I did verify that indeed the tests (in master) are running on a version of pip that bundles the vendored files.

instead of using pip/python -m pip, use a copy of get-pip.py

I would oppose such a change - it would make it difficult to run the tests without network, something I've had to do quite a few times.

Don't some of the tests need network access too? If using get-pip.py, you would only need access for setting up the tox environment, and the get-pip.py script could also be cached.

What about option 1, use recreate=True, instead? (Just to be clear, that's 2 different ways to solve the issue, both are not needed to solve it)

If using get-pip.py, you would only need access for setting up the tox environment, and the get-pip.py script could also be cached.

Yeah - I thought about this but it just doesn't feel right.

Don't some of the tests need network access too?

They're all marked with the network and I just deselect them.

What about option 1, use recreate=True, instead?

Regenerating the tox venv when running the py**-unvendor tests sounds fine to me - not for the normal py** tests though. :)

What about option 1, use recreate=True, instead?

Regenerating the tox venv when running the py**-unvendor tests sounds fine to me - not for the normal py** tests though. :)

Why? This is about solving the original issue this PR was supposed to address. Re-creating the tox venv is not going to fix the problem with un-vendored jobs running a vendored version of pip

The only relation between the 2 issues is that if tox env's pip had been used, the fact that the short-lived un-vendored version was not working (because of the deleted wheels) would have been immediately detected. That's another good reason for making sure the tox env version is always used.

Just to be clear, this is what's happening for an un-vendored job on master:

1. tox --notest is run: pip (source dir) is used to install the tox env deps
2. tox's pip is incorrectly un-vendored: wheels are generated, copied to pip/_vendor, but deleted as part of removing the sources in pip/_vendor
3. tox is run again: again pip (source dir) is used to install the code being tested from sdist

The failure in 2. to properly un-vendor is not detected when running pip for 3. because the source dir version is used...

Anyway, I'll try to think of some way to fix the original issue without hitting the network.

In the mean time, how should I PR the un-vendoring problem? Do you want separate PR for 922f9a3 and 66d16ad? Only the later needs a news entry, I think. Do changes that are not user visible need a news entry?

This is about solving the original issue this PR was supposed to address.

Oh, my bad. X|

Thanks for patiently explaining this stuff to me. :)

I'll come back to this PR a little later today...

Anyway, I'll try to think of some way to fix the original issue without hitting the network.

Thank you!

Worth stating -- I'm by no means a strong -1 toward needing to hit the network for running tests (it's more of a -0.5). It's just that the network I use is slightly unreliable in nature (and it's not under my control) so I try to not get red colour on my terminal because of it. :P

Do you want separate PR for 922f9a3 and 66d16ad?

That would be nice. :)

Do changes that are not user visible need a news entry?

I think anything that makes a major change in the development workflow or is a user facing change warrants a news file. So, these would probably not need a news entry.

OK, so I've created #4661 for adding the required missing entries to pip._vendor (still part of this PR to see if the un-vendored tests pass).

And I have reworked how travis/tox's environment is setup and how un-vendored jobs are supported:

• Use the virtualenv's pip for installing dependencies, not code that is about to be tested.

• Add 2 dedicated un-vendored environments (py27-novendor and py36-novendor), making it easier to use locally for testing.

• Un-vendoring is done by using a custom install_command that automatically un-vendors pip each time it's installed.

Hello!

I am an automated bot and I have noticed that this pull request is not currently able to be merged. If you are able to either merge the master branch into this pull request or rebase this pull request against master then it will eligible for code review and hopefully merging!

Rebased to avoid conflicts + tweaked comments in tox.ini.

Probably we should just get rid of the unvendoring tests. Nobody can get an unvendored pip without patching pip, so presumably they can also run the tests after having patched it to see if something broke.

@dstufft I think this PR is still relevant. Could you take a look at it?

Rebased.

Not necessary anymore now that pip's source code does not live in the current directory.

Ah, nice!

Uhm... This is still an issue...

I'm still seeing that tox uses the development pip when installing stuff - which is what this PR is supposed to fix.

Yep, on the second run, for installing pip's code itself...

diff --git i/src/pip/__main__.py w/src/pip/__main__.py
index 4609582c..861ceee9 100644
--- i/src/pip/__main__.py
+++ w/src/pip/__main__.py
@@ -3,6 +3,8 @@ from __future__ import absolute_import
 import os
 import sys
 
+assert False
+
 # If we are running from a wheel, add the wheel to sys.path
 # This allows the usage python pip-*.whl/pip install pip-*.whl
 if __package__ == '':

> tox -e py36 --recreate --notest
GLOB sdist-make: setup.py
py36 create: .tox/py36
py36 installdeps: -rdev-requirements.txt
py36 inst: dist/pip-10.0.0.dev0.zip
py36 installed: apipkg==1.4,execnet==1.4.1,freezegun==0.3.9,mock==1.0.1,pretend==1.0.8,py==1.4.34,pytest==3.2.1,pytest-catchlog==1.2.2,pytest-forked==0.2,pytest-rerunfailures==3.1,pytest-timeout==1.2.0,pytest-xdist==1.20.0,python-dateutil==2.6.1,PyYAML==3.12,scripttest==1.3,six==1.10.0,virtualenv==15.2.0.dev0
_____________________________________________________________________________________________________ summary ______________________________________________________________________________________________________
  py36: skipped tests
  congratulations :)
> tox -e py36 --notest
GLOB sdist-make: setup.py
py36 inst-nodeps: pip-10.0.0.dev0.zip
ERROR: invocation failed (exit code 1), logfile: .tox/py36/log/py36-4.log
...

Tweaked pip launcher script.

Appveyor doesn't seem very happy; any idea what happened there?

I don't know, for some reason somewhere in the bowels of pip, in pip.pip_vendor.distlib.resources, a check for os.path.exists(r'.tox\py\pip.tmp\pip\_vendor\distlib\t32.exe') fails, although the file does exist...

This should have re-triggered the builds. If they still fail, it's something that'll need to be looked into.

There's no need to re-trigger the build. I can reproduce the issue on my Windows 10 VM. I don't know how to fix it, and I've already spent enough time on this, so I'm going to close this PR. Someone else will have to find a way to fix the initial issue (or just use recreate = True in tox.ini).

Cool! Thanks a lot for looking into this @benoit-pierre! ^.^

This approach breaks the build-isolation code. :/

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.