Re: Python 3.4, ensurepip and wheels
- Original Message - On 12/12/2013 01:18 AM, Bohuslav Kabrda wrote: Well yeah, my point is that there is no upstream-acceptable way other than checking the file hashes by ensurepip, is there? If I wouldn't want to check file hashes, I'd have to query RPM for release - or is there some other way you're thinking of? I think doing it initially as a downstream only change where you query RPM will work for now (perhaps by patching the way pip handles the case where ENSUREPIP_OPTIONS is set?). By the time this approach is posted upstream, then PEP 426/440 will hopefully by Final and we can just use the metadata version field directly rather than needing to grab the release increment from the RPM repo. (I think this situation provides a good practical use case for why it's important to standardise this feature upstream, too). So, getting back to Toshio's concern about sysadmins who just update'n'upload files, the workflow for them would be update files, bump build tag and then upload, right? What I mean is, this still has two solutions: - checking the build tag (seems to be very simple to do) - check the file hashes Both solutions are IMO acceptable upstream (when we can actually do build tags), but my question is: Which one is more likely to be accepted? I'm for checking the build tag, even if it means the extra step for sysadmins who will need to bump the build tag when doing changes. (We may need to tell them to not bump the build tag major number, but add something to it like 1 = 1.1, since we want distro package with 2 win over sysadmin's change.) Does that make sense? What I'd love to hear is which of the two approaches is more likely to get accepted upstream, so that I can concentrate on that one approach. Thanks, Slavek. Cheers, Nick. -- Nick Coghlan Red Hat Hosted Shared Services Software Engineering Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/) -- Regards, Bohuslav Slavek Kabrda. ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Python 3.4, ensurepip and wheels
On 12/12/2013 01:18 AM, Bohuslav Kabrda wrote: Well yeah, my point is that there is no upstream-acceptable way other than checking the file hashes by ensurepip, is there? If I wouldn't want to check file hashes, I'd have to query RPM for release - or is there some other way you're thinking of? I think doing it initially as a downstream only change where you query RPM will work for now (perhaps by patching the way pip handles the case where ENSUREPIP_OPTIONS is set?). By the time this approach is posted upstream, then PEP 426/440 will hopefully by Final and we can just use the metadata version field directly rather than needing to grab the release increment from the RPM repo. (I think this situation provides a good practical use case for why it's important to standardise this feature upstream, too). Cheers, Nick. -- Nick Coghlan Red Hat Hosted Shared Services Software Engineering Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/) ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Python 3.4, ensurepip and wheels
- Original Message - On 11/28/2013 12:42 AM, Bohuslav Kabrda wrote: I hope I covered all the important points. Basically, we can make this work in a way acceptable for upstream, if we package setupttols and pip as wheels. It'll require some extra effort, but I think it's worth it. Thoughts? Anyone has better/simpler ideas? From an upstream point of view, so long as test.test_ensurepip and test.test_venv still work, things should generally be OK. I quite like the idea of checking for the consistency of the RECORD files between the system pip and the one in the virtualenv (as well as using RECORD as a guide to what to copy into a fresh venv). If you get that working, I'd be interested in a Python 3.5 venv and/or ensurepip patch to do that by default, and only bootstrap from the embedded wheel if there was no system pip available. Cheers, Nick. Actually, there seems to be a much simpler way of doing this in Fedora (and any distro more generally): - setuptools and pip RPMs will carry the wheel inside them and drop it into ensurepip/_bundled - the wheels will be rebuilt during every RPM build everytime *after patching*, so they will carry security patches etc. - we will use the RPM release as the build tag mentioned in PEP 427 [1], so that when we e.g. fix a security bug but don't bump the version, ensurepip --upgrade will still see that the wheel has to be reinstalled (otherwise it'd say think the version is already there and wouldn't reinstall) So the only thing we will need to implement will be autodiscovery of the wheels, since they will change names independently on python3 package, but I think we can do that :) From upstream point of view this shouldn't break anything, but it'd also probably not have any benefit. Would you still accept such patch? Regards, Slavek. [1] http://www.python.org/dev/peps/pep-0427/#id11 ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Python 3.4, ensurepip and wheels
On 11/28/2013 12:42 AM, Bohuslav Kabrda wrote: I hope I covered all the important points. Basically, we can make this work in a way acceptable for upstream, if we package setupttols and pip as wheels. It'll require some extra effort, but I think it's worth it. Thoughts? Anyone has better/simpler ideas? From an upstream point of view, so long as test.test_ensurepip and test.test_venv still work, things should generally be OK. I quite like the idea of checking for the consistency of the RECORD files between the system pip and the one in the virtualenv (as well as using RECORD as a guide to what to copy into a fresh venv). If you get that working, I'd be interested in a Python 3.5 venv and/or ensurepip patch to do that by default, and only bootstrap from the embedded wheel if there was no system pip available. Cheers, Nick. -- Nick Coghlan Red Hat Hosted Shared Services Software Engineering Development, Brisbane Testing Solutions Team Lead Beaker Development Lead (http://beaker-project.org/) ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
