the new issue template should ask how pip was installed

[benoit-pierre]

A number of issues are caused by the use of distribution packaged version of pip:

• de-vendoring pip can cause subtle and hard to reproduce issues (e.g. Listing outdated packages fails #5757)
• some of the patches by package maintainers also break pip (e.g. pip install --user ignores system-installed dependencies, installs older versions #4222 (comment))

Maybe add a new How is pip installed? field. Alternatively, maybe the user should be asked to paste to exact output of pip --version (and said output should be amended to at least mention if pip is de-vendored).

[pfmoore]

That sounds like a good idea to me.

Maybe also "can you reproduce this using the standard version of pip?" although that could make things worse, by causing people to try to install "the official version of pip" in away that clashes with the distro installation, or some such :-(

[benoit-pierre]

Yeah, it would be great if there was a version of get-pip.py that is not limited to the install command.

[benoit-pierre]

It's too bad zipimport does not support files with a comment or this would work:

> wget https://github.com/pypa/pip/archive/master.zip
> PYTHONPATH=master.zip/pip-master/src python -m pip --version

;(

[pfmoore]

>py pip-18.0-py2.py3-none-any.whl/pip --version
pip 18.0 from E:\Work\Scratch\pip-18.0-py2.py3-none-any.whl\pip (python 3.7)

There's probably some corner cases where it doesn't work 100% correctly (I think that there are places that need to reference the cert store from certifi from an actual file, not from a zipfile) but it mostly works.

Totally unsupported for any real uses, of course :-)

[pradyunsg]

Alternatively, maybe the user should be asked to paste to exact output of pip --version (and said output should be amended to at least mention if pip is de-vendored).

👍

I was wondering if there is merit in pushing this even further and ask the user to add post something along the lines of what pipenv does with pipenv --support to the issue.

---

As an aside, I think we can definitely improve the language in the issue template, to get better issue filings.

[dstufft]

One idea might be a pip debug or something so as not to overload --version, that can print a bunch of relevant debug information.

[pfmoore]

One problem, we get a lot of cases where people are running one version of pip when they think they are running another. It'll be awfully easy to get people even more confused because pip debug doesn't work...

But that minor point aside, I like the idea of a pip debug. Going back to the original question, it could report the file locations where it finds our (supposedly) vendored dependencies, as well as maybe any option overrides in pip.ini, and things like that. I'm not sure how we deal with distro patches - maybe introspect the code for "known patches" and report something like "Debian patches detected"...?

[dstufft]

Could do something funky like generate a hash of our installation directory and report that. It won't tell us what has changed, but if someone's hash is wrong, that suggests something changed. Whether that something is relevant or not is another question.

[pradyunsg]

I too like the pip debug command too.

[benoit-pierre]

I think it would be better to stick with pip --version, maybe add more info when called with --verbose? This way you don't have a set of instructions that does not apply to old versions.

[pfmoore]

One other thing that would be useful in a pip debug type of command would be the output of pip._internal.pep425tags.get_supported(), to help people diagnose issues where they are getting "No distributions found for this requirement" errors.

Overall, I think that if we added a pip debug command, it wouldn't provide much information that isn't available elsewhere at the moment, so at first glance it doesn't seem particularly worthwhile - but what it would do is provide an obvious place to add further debug information when the need is identified.

[pradyunsg]

what it would do is provide an obvious place to add further debug information when the need is identified.

Yep! FWIW, if do go the pip debug, we should also note somewhere that pip debug's output is meant to be human readable and not for parsing/automated consumption. If someone wants that information to be exposed, we likely should have some packaging tooling that provides it to them.

[pradyunsg]

FTR - we have a pip debug command in pip > 19.2 now.