ModuleNotFoundError: No module named 'pip.download'

[Dmitri-Sintsov]

• Pip version: 10.0.0
• Python version: 3.6.4
• Operating system: Ubuntu 14.04

Description:

pip fails to install the package from git repository specified by the following requirements.txt line:

git+https://github.com/Dmitri-Sintsov/django-jinja-knockout.git

Circle CI test, which used to work in a long time suddenly is broken. Why pip.download module is not available anymore and how can I fix that in my test script?

Please see the log here:
https://circleci.com/gh/Dmitri-Sintsov/django-jinja-knockout/353

What I've run:

         # Install pyenv to use exact version of Python.
          git clone https://github.com/pyenv/pyenv.git ~/.pyenv
          export PYENV_ROOT="$HOME/.pyenv"
          export PATH="$PYENV_ROOT/bin:$PATH"
          pyenv init -
          pyenv install 3.6.4
          # Version of Python installed in the python:latest-browsers image.
          python3 --version
          # Version of Python used to run the tests.
          $(pyenv root)/versions/3.6.4/bin/python --version
          # https://stackoverflow.com/questions/27849412/permissionerror-with-pip3
          $(pyenv root)/versions/3.6.4/bin/python -m pip install -U pip wheel tox tox-pyenv setuptools --user
          $(pyenv root)/versions/3.6.4/bin/python -m tox -r -e py36-django-20

[pradyunsg]

Hey @Dmitri-Sintsov!

You are trying to use an internal, implementation detail of pip which is not a supported way of using pip. pip 10 made this explicit by moving almost all of it into pip._internal namespace.

You can find more details on this in the User Guide.

As an aside, setup.py and requirements.txt are for serving different purposes -- https://caremad.io/posts/2013/07/setup-vs-requirement/.

I don't see anything actionable here from pip. @Dmitri-Sintsov if that addresses your concerns, feel free to close this issue.

[pfmoore]

Importing pip's internal code in your own application is not supported. See the docs for details.

https://github.com/Dmitri-Sintsov/django-jinja-knockout/blob/master/setup.py#L11 and the following line are unsupported usage, and you'll need to replace them. The packaging project may have a function to parse requirements in a supported manner.

[wimglenn]

Making everything private seems a bit heavy-handed. There's literally nothing in pip/__init__.py now except for the __version__(!) The part of the docs linked earlier is sad, saying to use subprocess is a poor substitute for providing some library functionality/api. Even if it's only a small but useful 'safe' subset. Using packaging, setuptools, pkg_info etc is good but in some cases you want to make sure you use the same stuff which pip vendors, even if there are different versions installed in site-packages.

[pfmoore]

@wimglenn You're missing the point here - everything was already private. We'd made that statement repeatedly, in issues, and we'd never documented any of pip's internal APIs - that wasn't an accidental omission, it was deliberate (although it's hard to get people to understand that "if we don't document it, it's not supported" :-().

No-one expects to use internal APIs from apt or yum. The situation with pip is the same - what makes people think it's not?

[wimglenn]

Of course people won't understand that, if you're violating the usual conventions in Python that name is public and _name is not. Many devs just RTFS, it's not practical to double check every name used is a documented feature.

Anyway, I found that as long as you enter/exit a PipSession context properly then using the library code actually worked pretty well! Sure, it was a bit annoying to have to monkeypatch to disable progress bars and redirect logger configuration and stuff, but there was some very good and useful stuff in there that is not really usable from the CLI. Anyone who expected thread-safety here is expecting way too much.

I honestly don't think it would be too hard to move some useful bits into public APIs and make the logging config / output stream handling a bit saner, and am happy to contribute some time to the project if there's any interest in moving things in that direction.