Re: Python Bundled Wheels package

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)