Install (if possible) distribution packages to satisfy requirements

What’s the problem this feature will solve? For many users it would be preferable to install packages from maintained distribution, rather than Python packages from PyPI.

Describe the solution you’d like Would it be possible for pip to gain an option to prefer system packages to the PyPI ones, by running first the system install (e.g., zypper, dnf, or apt-get) with the list of desired system packages and only then installing remaining packages from PyPI.

I am willing to do the work, but I would need a lot of help and advice where to hook this option to and what special functionality would be useful to other distributions (if they are interested in this option).

User runs (even a normal user) runs

$ pip install foo --user --install-distro-pkgs

pip while collecting necessary requirements finds out that it needs LXML. Instead of downloading and building binary from PyPI, it also discovers that the distribution provides package python-lxml, which satisfies the requirement. Because it is run as a normal user it runs the system packager via sudo to install this packages and then continue with installing remaining packages all the way up to foo.

CC: @warsaw, @hroncok

[pfmoore]

OK, well we’ve long been promoting the advice that you should never run pip as root, so I’d say no. If you’re working as root, you should use the distro package management tools. If the distro hasn’t packaged something you need, then you should get it from PyPI using pip and install it as a normal user for your own use. Mixing the two usages is bad, IMO. Yes, it is probably useful for the user to have one tool that “does what you mean” rather than making you check what’s available and choose a different tool, but that sort of “intelligent guesswork” is way higher risk than I’d want to include in pip - especially if it’s something we’d advocate running as root.

[chrahunt]

I am against implementing this in pip this for the following reasons:

1. The use case proposed, to avoid building native dependencies, already has a working solution: distributing pre-built binary wheels
2. Supporting users is hard enough when we have to consider incidental interactions with system-provided packages, this would make those interactions much more likely.
3. This does not take into account #988 and I think it would make it much harder. And that issue has a lot of preexisting support and ongoing effort dedicated to it.
4. System Python packages and Python packages on PyPI live in completely different namespaces and there’s not a 1:1 mapping between them.
5. Anyone who cares about reproducibility in a dev or execution environment would end up specifying everything explicitly (install this from the system package manager, install this from PyPI) and at that point they might as well just do that with the individual tools.