Upstream, this software supports Python 3. Please provide a Python 3 package for Fedora. According to the Python packaging guidelines [0], software must be packaged for Python 3 if upstream supports it. The guidelines give detailed information on how to do this, and even provide an example spec file [1]. The current best practice is to provide subpackages for the two Python versions (called "Common SRPM" in the guidelines). Alternatively, if nothing depends on your Python2 package, you can just switch to Python 3 entirely. It's fine to do this in Rawhide only. If anything is unclear, or if you need any kind of assistance with the porting, you can ask on IRC (#fedora-python on Freenode), or reply here. We'll be happy to help! [0] https://fedoraproject.org/wiki/Packaging:Python [1] https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
As per the recent porting initiative, I will submit a patch for this.
Created attachment 1181298 [details] patch for RPM spec file Here's my patch. I have only tested this on Fedora 24 (not RHEL or CentOS).
Thanks Alan! I took you patch but had to adjust it a bit. Here it is, applied and built in rawhide: http://pkgs.fedoraproject.org/cgit/rpms/python-zope-proxy.git/commit/?id=6d4041d9273a8f708026196e0f4117f46e6285dc Note that the with_python2 macro, while not forbidden, is unusual. I've only ever seen a with_python3 macro. Is there some new documentation out there indicating that we should use a with_python2 macro in our specfiles? Thanks again!
(In reply to Ralph Bean from comment #4) > Thanks Alan! > > I took you patch but had to adjust it a bit. > > Here it is, applied and built in rawhide: > > http://pkgs.fedoraproject.org/cgit/rpms/python-zope-proxy.git/commit/ > ?id=6d4041d9273a8f708026196e0f4117f46e6285dc > > Note that the with_python2 macro, while not forbidden, is unusual. I've > only ever seen a with_python3 macro. > > Is there some new documentation out there indicating that we should use a > with_python2 macro in our specfiles? > > Thanks again! Ralph, None that I'm aware of (this is my first contrib). It just seemed like a useful conditional to have if one wanted to build with Python 3 by default.
(In reply to Alan Liddell from comment #5) > (In reply to Ralph Bean from comment #4) > > Thanks Alan! > > > > I took you patch but had to adjust it a bit. > > > > Here it is, applied and built in rawhide: > > > > http://pkgs.fedoraproject.org/cgit/rpms/python-zope-proxy.git/commit/ > > ?id=6d4041d9273a8f708026196e0f4117f46e6285dc > > > > Note that the with_python2 macro, while not forbidden, is unusual. I've > > only ever seen a with_python3 macro. > > > > Is there some new documentation out there indicating that we should use a > > with_python2 macro in our specfiles? > > > > Thanks again! > > Ralph, > > None that I'm aware of (this is my first contrib). It just seemed like a > useful conditional to have if one wanted to build with Python 3 by default. Mind pointing me toward best practice?
You know.. I couldn't find any docs on it. I found this: https://communityblog.fedoraproject.org/port-python-package/ which led me to this: http://fedora.portingdb.xyz/howto/ which led me to this: http://python-rpm-porting.readthedocs.io/en/latest/ which led me to this: http://python-rpm-porting.readthedocs.io/en/latest/modules.html and that last page is very useful, but it doesn't mention anything about with_python3 or with_python2 macros. There's a certain value in the with_python3 macro for packages that are both in Fedora (which is python3 by default, and so the conditional will always be true) and also in EPEL (which is python2 only (kinda) and so the conditional is usually false there). Many of the packages I help maintain are in both Fedora and EPEL, and so by habit I use that with_python3 macro, but perhaps it is not as standard as I thought. (note that, this package in particular is not in EPEL)