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).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx/message/JA2GU7GILK4FYS5CAMOTPRCNJCAFDNRQ/
