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)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
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/python-devel@lists.fedoraproject.org/message/CRBKMUC5ND4AHEF5F6XNNEHHXANQDK2I/
