[issue20053] venv and ensurepip are affected by default pip config file

Nick Coghlan added the comment: pip 1.5.3 has been bundled and cherry picked to the release clone. -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker _

[issue20053] venv and ensurepip are affected by default pip config file

Donald Stufft added the comment: pip 1.5.3 is released and I've requested larry cherry-pick it into 3.4.0 with issue20713 -- ___ Python tracker ___ _

[issue20053] venv and ensurepip are affected by default pip config file

Nick Coghlan added the comment: I created issue 20570 to propose updating to pip 1.5.3 for 3.4rc2. That would include the pip side workaround for this issue, also allowing this issue to be closed. -- dependencies: +Bundle pip 0.15.3 in Python 3.4rc2 nosy: +larry priority: normal -> def

[issue20053] venv and ensurepip are affected by default pip config file

Paul Moore added the comment: Fix now merged into pip 1.5.X branch -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue20053] venv and ensurepip are affected by default pip config file

Paul Moore added the comment: https://github.com/pypa/pip/pull/1543 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue20053] venv and ensurepip are affected by default pip config file

Paul Moore added the comment: Sounds reasonable. Having thought about it a bit more, I don't think it's a big deal. I'll put a PR together for special-casing devnull. -- ___ Python tracker

[issue20053] venv and ensurepip are affected by default pip config file

Donald Stufft added the comment: I'd remove it in 1.6 with a proper isolated mode. I'm purely thinking of minimal changes to make it easier to to get it into 3.4. -- ___ Python tracker

[issue20053] venv and ensurepip are affected by default pip config file

Paul Moore added the comment: Maybe. I don't know what *else* might fail because devnull is special. The filename gets passed straight to configparser, for a start. But if you want to do that I'm OK with that - I just won't make that change myself. Would the special-casing be permanent or woul

[issue20053] venv and ensurepip are affected by default pip config file

Donald Stufft added the comment: The proper fix is an isolated mode, but we could special case devnull in pip for 1.5.3 and make a proper isolated solution in 1.6. -- ___ Python tracker ___

[issue20053] venv and ensurepip are affected by default pip config file

Paul Moore added the comment: In ensurepip, _disable_pip_configuration_settings has the line: os.environ['PIP_CONFIG_FILE'] = os.devnull On Windows, os.devnull does not behave like a real file in that os.path.exists(os.devnull) is False even though opening it works fine. So that line of c

[issue20053] venv and ensurepip are affected by default pip config file

Donald Stufft added the comment: I'm not sure I grasp what the problem is -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue20053] venv and ensurepip are affected by default pip config file

Nick Coghlan added the comment: (Note that the fix on the pip side may be something more direct like just ignoring all config files and environment variables when ENSUREPIP_OPTIONS is set, rather than changing the way it reads the config files) -- _

[issue20053] venv and ensurepip are affected by default pip config file

Paul Moore added the comment: As noted in http://bugs.python.org/issue1311 (referenced from http://bugs.python.org/issue20541) it's not actually correct to assume that os.path.exists(os.devnull) returns true, as on Windows the "null device" is not a proper filesystem object. So I'd suggest th

[issue20053] venv and ensurepip are affected by default pip config file

Nick Coghlan added the comment: The problem is that the assumption of assumption of an exists <-> open equivalence is in pip's configuration file loading rather than in ensurepip or venv - the idea was to pass in an existing but empty file to avoid needing a change in pip to fix this. However

[issue20053] venv and ensurepip are affected by default pip config file

Roundup Robot added the comment: New changeset f3f92d55f942 by Nick Coghlan in branch 'default': Issue #20053: Mark as an expected failure for 3.4 http://hg.python.org/cpython/rev/f3f92d55f942 -- ___ Python tracker

[issue20053] venv and ensurepip are affected by default pip config file

Nick Coghlan added the comment: As Paul noted, I discovered there was a bug in my assumption testing test - when I tried it directly on Windows, I discovered the culprit here is issue 20541. So adding that as a dependency, and I'll disable that part of the test on Windows (and mark the assump

[issue20053] venv and ensurepip are affected by default pip config file

Paul Moore added the comment: Sigh. Yes, I looked at that and wondered if os.devnul would show as existing, but I similarly misread the test and assumed it was testing what it was meant to test :-( os.path.exists(os.devnull) is false on Windows (just checked) so this assumption *is* what's fa

[issue20053] venv and ensurepip are affected by default pip config file

Roundup Robot added the comment: New changeset 17bea44a9fa7 by Nick Coghlan in branch 'default': Issue #20053: Actually test relevant assumption http://hg.python.org/cpython/rev/17bea44a9fa7 -- ___ Python tracker _

[issue20053] venv and ensurepip are affected by default pip config file

Nick Coghlan added the comment: EnvironmentVarGuard doesn't work through monkeypatching - you make your changes *through* the guard, and it undoes them in __exit__, as well as restoring the original binding (in case *other* code monkeypatched it). This allows it to still be used when testing c

[issue20053] venv and ensurepip are affected by default pip config file

Paul Moore added the comment: Nothing obvious or Windows-specific from what I can see. It does seem to me that EnvironmentVarGuard doesn't monkeypatch os.environ even though it looks like it intends to (__exit__ sets it back, but __enter__ doesn't monkeypatch it). So maybe that's doing somethi

[issue20053] venv and ensurepip are affected by default pip config file

Nick Coghlan added the comment: D'oh, still failing even though that new assumption check passes on Windows: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/4002/steps/test/logs/stdio Paul, any ideas? -- ___ Python tracke

[issue20053] venv and ensurepip are affected by default pip config file

Roundup Robot added the comment: New changeset ddc82c4d1a44 by Nick Coghlan in branch 'default': Issue #20053: new test to check an assumption http://hg.python.org/cpython/rev/ddc82c4d1a44 -- ___ Python tracker ___

[issue20053] venv and ensurepip are affected by default pip config file

Nick Coghlan added the comment: *sigh*, Windows is not cooperating, suggesting it is still reading the default config file: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/4000/steps/test/logs/stdio ===

[issue20053] venv and ensurepip are affected by default pip config file

Roundup Robot added the comment: New changeset 1b8ba1346e67 by Nick Coghlan in branch 'default': Close #20053: ignore default pip config settings http://hg.python.org/cpython/rev/1b8ba1346e67 -- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed

[issue20053] venv and ensurepip are affected by default pip config file

Nick Coghlan added the comment: Oh, I forgot about os.devnull. ensurepip.bootstrap mutates the environment of the current process (hence the recommendation to use the CLI instead), so yes, doing "os.environ['PIP_CONFIG_FILE'] = os.devnull" before importing pip should do the trick. And then g

[issue20053] venv and ensurepip are affected by default pip config file

R. David Murray added the comment: I don't know anything about pip configuration or the tests, but perhaps you want to use something like: 'PIP_CONFIG_FILE={}'.format(os.devnull) -- nosy: +r.david.murray ___ Python tracker

[issue20053] venv and ensurepip are affected by default pip config file

Nick Coghlan added the comment: pip side counterpart, suggesting an explicit "isolated mode" option: https://github.com/pypa/pip/issues/1397 -- ___ Python tracker ___ __

[issue20053] venv and ensurepip are affected by default pip config file

New submission from Nick Coghlan: In resolving issue 19734, I realised venv and ensurepip are actually in a similar situation with respect to the default pip configuration file as they were with respect to environment variables: those settings are unlikely to be appropriate for ensurepip, but