Support for seed packages having dependencies

[gaborbernat]

• bump setuptools/wheel
• no OS dependent dependencies allowed

[hroncok]

Fedora people here 😱 cc @frenzymadness

I'd be very very VERY happy if this didn't come trough and the problem would be solved differently (most likely by not having the dependency). I follow the discussion in pypa/wheel#346

One thing I wanted to ask for ages (and forgive me if it is answered in some FAQ): Why is wheel seeded into new virtual environments created by virtualenv when it is not seeded to those created by venv? Already discussed in the linked issue, sorry.

[gaborbernat]

I'd be very very VERY happy if this didn't come trough and the problem would be solved differently (most likely by not having the dependency). I follow the discussion in pypa/wheel#346

Your best chance is to raise the issue within wheel project and link it here 🤔 It's @agronholm you have to convince of this.

[agronholm]

@hroncok What exact issue would you have with wheel having dependencies?

[hroncok]

In Fedora, we don't ship the wheels bundled with virtualenv, but instead we build our own wheels of setuptools, pip and wheel. This means we apply our (also security) patches to them, we ensure how the wheels were built etc.

We don't have to do that, but we want to. For example, for some (very) old Python versions (currently 2.7 and 3.4), we stop trying na we ship the CPython upstream bundled wheels (shipped in ensurepip).

At this point, we only need to worry about compatibility problems of 3 projects: setuptools and pip for ensurepip and additionally also wheel for virtualenv. With this change we would not only need to also build wheels of packaging, pyparsing and six, but we would also need to worry about their cross-Python-version compatibility and the "current list of deps" changing over time.

Assuming the (recursive) list of deps won't grow over time, we could probably do it, but if this opens a door to even bigger depchain growth. At the end, we might end up shipping / building several small stacks of wheels. I am not saying it is not possible, but if we could avoid that situation, I would be much happier.

[agronholm]

The current plan is to separate the packaging.tags module from the packaging library and have wheel depend on that. I have no further plans to add dependencies to wheel, and that library would not have any dependencies of its own. Would you be okay with that?

[hroncok]

That would certainly make it possible, as long as the packaging.tags library supports at least the same Python versions as wheel.

[agronholm]

Wheel will drop support for Python < 3.5 in v1.0 but I don't know when that will come out. I could keep wheel dependency free at least until then, if that makes your life easier.

[hroncok]

Python < 3.5 is fine in Fedora, we needed to drop anything older anyway (we no longer have 3.4 in new Fedoras and 2.7 has bundled wheels -- we will need to bundle the wheel of wheel with virtualenv anyway). Keeping it dependency free until would be nice (thanks) but not critical.