On 1.8.2018 15:34, Miro Hrončok wrote:

On 1.8.2018 15:11, Petr Viktorin wrote:

...

On 07/22/18 11:49, Miro Hrončok wrote:

...

Hi Pythonistas and Fedora packagers.

Recently I've realized we bundle too much wheels with our pythons + virtualenv package. That is unfortunate:

* we don't build those. stricly seeking, it's just a zip with python files in it, yet this is not permitted in Fedora   * we only sometimes list it as Provides: bundled(...) and when we do, it is tedious   * we never list bundled deps in those bundled wheels (pip bundles a lot)   * we never adapt the license tag to include license of bundled wheels (and bundled deps in those) - it would be even more tedious, as pip License tag can be very complicated   * we duplicate those across packages

I went ahead and prepared a concept in: https://bugzilla.redhat.com/show_bug.cgi?id=1605156

This is one package that builds all the required wheels. It might be a bit weird that it's only one package, but I think it can lower the maintenance burden. Also, we won't update any wheel package, we only add or remove them, so there is no "life cycle". Later we can decide that there are simply too many thing sin one package and split it).

This package makes sure the license tag is right and all the virtual bundled provides are in place.

Even as one package, I think it's a big improvement comparing to current state of things.

Could you please review the decisions made in the spec? Namely:

* naming (main package, subpackages)   * virtual provides   * that the spec is generated by a script and how that script works   * the method of usage described in the package review request

I've also decided not to run tests, as for them to mean something, we would need to run them against all relevant Python versions. Also, it would complicate the package a lot.

The package is approved thanks to Robert-André Mauchin, yet I won't request the repo until it's settled that we want this.

Also, once we start using this, maybe we can stop doing rewheel and just use wheels from here in the python3 package as well?

Let me ask: do we actually need all those different versions of wheels? After all, the first thing I do after creating a venv is usually `pip install -U pip`.

The answer is in the middle. No, it doesn't need to be the hardcoded one. But for some Python version,s it needs to be relatively old one.

For example virtuelenv now bundles:

argparse = 1.4.0 pip = 9.0.3 pip = 10.0.1 setuptools = 36.8.0 setuptools = 39.1.0 wheel = 0.29.0 wheel = 0.31.1

Just to support Python 2.6, 3.4-3.7.

We may be able to reduce the number of versions. E.g. I don't really think we need both 9.0.1 and 9.0.3. Or I don't understand why pypy3 ships both pip 8.1.2 & 9.0.1; setuptools 21.2.1 & 28.8.0.

We could probably reduce this to:

setuptools   36.8.0 for virtualenv (py26)   39.1.0 (or newer) for everything else

pip   9.0.3 fior virtualenv (py26)   10.x or 18.x for everything else

wheel   0.29.0 for virtualenv (py26)   0.31.1 (or newer) for everything else

argparse-1.4.0 for virtualenv (py26)

We've talked with Petr in person at Flock. Here's a summary:

We'll build wheels packages with our recent pip and setuptools from python-pip and python-setuptools SRPMs.

We make sure python 2.7 to 3.7 uses them instead of the bundled ones. That should be fairly easy.

We try to do the same with pypys and Jython (and hope it works).

We'll deal with the Python 2.6 virtuelenv wheels later (probbaly have a dedicated SRPM for them).