Bug 533290
Summary: | RFC: Emit python3 subpackage as part of the python-lxml build | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dave Malcolm <dmalcolm> | ||||||
Component: | python-lxml | Assignee: | Jeffrey C. Ollie <jeff> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | rawhide | CC: | amcnabb, jeff | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2009-11-06 02:08:28 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | 531895 | ||||||||
Bug Blocks: | 530636 | ||||||||
Attachments: |
|
Description
Dave Malcolm
2009-11-05 21:50:45 UTC
Created attachment 367737 [details]
Patch to devel/python-lxml.spec that adds a python3- subpackage
Notes:
- no %changelog entry yet
- execfile() was a builtin function in python 2 but doesn't exist in python 3 AFAIK, so I've reworked the copy&pasted scriptlet fragments to avoid using it
This is really cool. I didn't expect this to be quite so easy. Just a couple of quick questions: 1) Does %{py3dir} need to be manually deleted? 2) Does the code for lxml work unchanged for both Python 2 and Python 3, or is there anything magical happening to make changes for Python 3? Keep up the good work. (In reply to comment #2) > This is really cool. I didn't expect this to be quite so easy. Just a couple > of quick questions: > > 1) Does %{py3dir} need to be manually deleted? Possibly in the %clean section, yes. > 2) Does the code for lxml work unchanged for both Python 2 and Python 3, or is > there anything magical happening to make changes for Python 3? The magic is provided by "Cython", which autogenerates the c extension code from a .pyx file. As I understand it, Cython handles the nasty details of 2 vs 3 differences to the extension API (and is thus a big win over its predecessor, Pyrex). (Looks like the python-lxml specfile is using the .c files embedded in the upstream tarball, as there isn't a BuildRequires on cython) > Keep up the good work. Thanks! Can this even be built in devel yet? As fas as I can see python3 hasn't made it into CVS or the F-13 buildroots. Anyway I've added a modified version of the patch to CVS that defaults to not building the Python 3 subpackage. Once Python 3 makes it to the buildroots we'll need to flip the flag and rebuild. Created attachment 367772 [details]
Final patch
> Can this even be built in devel yet? As fas as I can see python3 hasn't made > it into CVS or the F-13 buildroots. Anyway I've added a modified version of the Correct, the "python3" package hasn't made it through review yet (bug 526126), likewise for python3-setuptools (bug 531648 or bug 531895, depending on which approach we follow). I'm still experimenting with approaches to packaging modules for python 3, and lxml is an interesting case, as 2 and 3 seem to work cleanly from a single upstream tarball. So I'm afraid I'm using lxml as an experimental subject to some extent. Sorry about this, and thanks for bearing with me. I've written some notes on python 3 packaging here: https://fedoraproject.org/wiki/PackagingDrafts/Python3 (this is very much a work-in-progress). > patch to CVS that defaults to not building the Python 3 subpackage. Once > Python 3 makes it to the buildroots we'll need to flip the flag and rebuild. Thanks - a good plan. BTW, I noticed that the version you committed to CVS had a definition of python3_sitearch. In python3-3.1.1-9 onwards I'm dropping a "macros.python3" file into /etc/rpm which should make this unnecessary (see https://bugzilla.redhat.com/show_bug.cgi?id=526126#c43 ), and perhaps we'll write it out of the packaging guidelines when we write them for python 3. Though it doesn't hurt to have it, especially given that there isn't an "official" version in the buildroots yet. (In reply to comment #6) > > BTW, I noticed that the version you committed to CVS had a definition of > python3_sitearch. In python3-3.1.1-9 onwards I'm dropping a "macros.python3" > file into /etc/rpm which should make this unnecessary (see > https://bugzilla.redhat.com/show_bug.cgi?id=526126#c43 ), and perhaps we'll > write it out of the packaging guidelines when we write them for python 3. > Though it doesn't hurt to have it, especially given that there isn't an > "official" version in the buildroots yet. I didn't see that until after I had made the changes to CVS, but in the specfile it's a conditional definition, if python3_sitearch is already defined it should take precedence. |