`pip` tracebacks when not upgraded in build process and `python-pip-whl` package is not installed

[OddBloke]

When building in an Ubuntu schroot (via sbuild), I believe the virtualenv creation process copies the pip from the build system into the virtualenv. This pip is debundled: pip upstream vendor their dependencies in pip/_vendor/..., but Debian/Ubuntu remove those and provide them instead as wheels in /usr/share/python-wheels, via the python3-pip-whl package.

However, the built package does not have a dependency on python3-pip-whl, so when you try to use pip within the virtualenv, you hit an ImportError: it doesn't have its vendored dependencies in _vendor, and they aren't installed in /usr/share either.

There are two easy workarounds: add python3-pip-whl to Depends yourself, or upgrade pip within the virtualenv (which pulls down an upstream pip which does have the vendored dependencies in _vendor).

If I didn't already have a bunch of experience debugging virtualenvs, figuring this out would have been pretty painful (and I think I may have landed on a more obvious but worse solution: explicitly installing pip's missing dependencies via my requirements.txt file).

Should dh-virtualenv do something in this case to avoid users having to figure this all out?

[nailor]

Hi,

thanks for taking the time reporting the issue and especially for digging through the virtualenv behaviours 😊

What comes to core dh-virtualenv it aims to provide repeatable builds, and in this context supporting modifying the virtualenv in place is not something we want to support via the project.

However as you note, adding the simple dependency enables this and still gives you the power to do local modifications if you want.

Closing the issue as it is not something we will support by default

[jhermann]

Well, it warrants a small docs PR -- if we have no traps & pitfalls chapter, it's time to create one.