python-devel July 2015

python-devel@lists.fedoraproject.org

8 participants
4 discussions

Python guidelines cleanup
by Jason L Tibbitts III 03 Aug '15

03 Aug '15

As many of you may be aware, FPC has been fielding several tickets surrounding python packaging lately, and the last one was a sizable reorganization that unfortunately was based on an older version of the guidelines. While merging it all together I just said screw it and just cleaned up the page like I've always wanted to do. I suggest anyone who hasn't lost sanity due to this whole guidelines revision process pile onto: https://fedorahosted.org/fpc/ticket/552#comment:4 Here's the contents of that comment to save you a click. OK, this was a lot of stuff, and the more I worked on it, the more annoyed I became. Plus the wiki kept eating my edits and I kept getting lost in the overhuge page. So, I've probably gone too far in cleaning up but I'll present what I have and if people yell at me then I'll try something less ambitious. There are now three pages: https://fedoraproject.org/wiki/User:Tibbs/PythonCleanup2 https://fedoraproject.org/wiki/Packaging:Python_F21 https://fedoraproject.org/wiki/User:Tibbs/PythonAppendix The first page incorporates the following changes: * Notes that these guidelines apply only to F22+ and EPEL7. Points at the 2nd page for old guidelines. * Includes the information about not retiring python-version-specific subpackages in stable releases. * Makes BuildRequires: section much more succinct. * Makes sure python2-foo provide is versioned, mentions %python_provide macro. * Makes the macro table collapsible and collapsed by default. * Remove EL6-specific cruft (it's in the old guidelines page). * Move the parts of the byte compilation section that nobody ever uses off to the Appendix page. * Make the single-rpm single-dir case the default. Move the entire multiple-dir case to the appendix. * Completely remove %with_python3 from the example spec. We want people to build for python3. People just paste this in without knowing why they would ever need it. If you're using the new macros you can't just conditionalize for EL6 anyway. This really makes the spec look nice. Macro-izing the summary and description would make it look even nicer once the description gets longer than a line. * Uses a generic "example" module as an example. Two different approved proposals changed it to two different things; I just punted. * Puts the example spec all together without a bunch of text and admons and whatnot in the middle. * Moves the 2to3 section to the appendix. * Simply refers to the eggs section. That whole part at the bottom was quite awkward and I don't think most people even looked down that far. * Loads and loads of typo fixes, grammar fixes, and cleanups. The current main guideline page is now a bit over half the length it was and on the page it's less because of the collapsed macro table. I find it to be far more readable, and the sample spec no longer turns my stomach. The old guidelines page is just as it was before writing up the new macros, except that I added a short explanatory section at the top. The appendix page conveniently holds things which we probably should document but pretty much nobody would actually want to read without some specific reason. Functionally I do not believe I have gone beyond anything upon which we voted but I wanted to toss this out there and see if anyone yells before I copy it into place. Been trying to get this done for three days now and I think I'm finally there. - J<

5 11

python34 packages for EPEL
by Orion Poplawski 16 Jul '15

16 Jul '15

Sorry for the cross posting - let's follow up on the EPEL list We now have python34 in EPEL (yay - thanks Matej and others!). Starting to look at packaging some modules. We have https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 as a starting point which looks pretty good. One wrinkle though is that we have a bunch of python2 packages provided by RHEL that we'll want to provide python3X versions for in EPEL, but not ship python2 versions. So a question becomes, where do they get maintained? Either: - epel7 branch of the python-blah package in Fedora? - a new python3X-blah package? And if in an epel7 branch of an existing package, is it conceivable to maintain a common spec across EPEL and Fedora? I think this is somewhat representative of the changes needed in a more complicated package (setuptools) which isn't actually too terrrible: diff --git a/python-setuptools.spec b/python-setuptools.spec index 7f37e90..cb96b9f 100644 --- a/python-setuptools.spec +++ b/python-setuptools.spec @@ -1,9 +1,9 @@ -%if 0%{?fedora} +%if 0%{?fedora} || 0%{?rhel} >= 7 %global with_python3 1 # This controls whether setuptools is build as a wheel or not, # simplifying Python 3.4 bootstraping process -%global build_wheel 1 +%global build_wheel 0 %else %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print (get_python_lib())")} %endif @@ -44,10 +44,10 @@ BuildRequires: python-pip BuildRequires: python-wheel %endif %if 0%{?with_python3} -BuildRequires: python3-devel +BuildRequires: python%{python3_pkgversion}-devel %if 0%{?build_wheel} -BuildRequires: python3-pip -BuildRequires: python3-wheel +BuildRequires: python%{python3_pkgversion}-pip +BuildRequires: python%{python3_pkgversion}-wheel %endif %endif # if with_python3 # For unittests @@ -68,7 +68,7 @@ This package also contains the runtime components of setuptools, necessary to execute the software that requires pkg_resources.py. %if 0%{?with_python3} -%package -n python3-setuptools +%package -n python%{python3_pkgversion}-setuptools Summary: Easily build and distribute Python 3 packages Group: Applications/System @@ -76,7 +76,7 @@ Group: Applications/System # has been present since python3-3.2. We do not ship python3-3.0 or # python3-3.1 anywhere -%description -n python3-setuptools +%description -n python%{python3_pkgversion}-setuptools Setuptools is a collection of enhancements to the Python 3 distutils that allow you to more easily build and distribute Python 3 packages, especially ones that have dependencies on other packages. @@ -156,6 +156,9 @@ chmod +x %{buildroot}%{python3_sitelib}/setuptools/command/easy_install.py popd %endif # with_python3 +%if 0%{?epel} +rm %{buildroot}/%{_bindir}/easy_install +%else %if 0%{?build_wheel} pip2 install -I dist/%{python2_wheelname} --root %{buildroot} --strip-file-prefix %{buildroot} %else @@ -167,9 +170,11 @@ rm -rf %{buildroot}%{python_sitelib}/setuptools/tests sed -i '/^setuptools\/tests\//d' %{buildroot}%{python2_record} %endif -install -p -m 0644 %{SOURCE1} %{SOURCE2} . find %{buildroot}%{python_sitelib} -name '*.exe' | xargs rm -f chmod +x %{buildroot}%{python_sitelib}/setuptools/command/easy_install.py +%endif # 0%{?epel} + +install -p -m 0644 %{SOURCE1} %{SOURCE2} . %check %{__python} setup.py test @@ -184,15 +189,17 @@ popd rm -rf %{buildroot} +%if !0%{?epel} %files %defattr(-,root,root,-) %doc *.txt docs %{python_sitelib}/* %{_bindir}/easy_install %{_bindir}/easy_install-2.* +%endif %if 0%{?with_python3} -%files -n python3-setuptools +%files -n python%{python3_pkgversion}-setuptools %defattr(-,root,root,-) %doc psfl.txt zpl.txt docs %{python3_sitelib}/* One note - according to https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3#Specfiles.2C_Macr… %{python3_pkgversion} is supposed to be defined in Fedora, but I don't see it (at least not in F22). In the review (https://bugzilla.redhat.com/show_bug.cgi?id=1219411#c8) there seems to be some uncertainty as to where it will land? Comments? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

2 1

Compatibility shim for /usr/bin/python
by Nick Coghlan 15 Jul '15

15 Jul '15

One of the open questions with the Python 3 migration is the eventual fate of /usr/bin/python. In response to a question from Robert Kuska, Barry Warsaw recently pointed me towards Geoffrey Thomas's design proposal for Debian: https://ldpreload.com/blog/usr-bin-python-23 The gist of the idea is to make /usr/bin/python a custom launcher rather than a symlink to a specific Python interpreter, and then have a simple "magic comment" syntax to specify version compatibility. (These would only apply for a "python" shebang line - "python2" and "python3" would still be symlinks to a specific interpreter) Python 2 only (fail if Python 2 not installed): No comment # pyversion: 2.x+ Python 3 only (fail if Python 3 not installed): # pyversion: 3.x+ Python 2 & 3 compatible: # pyversion: 2.x+, 3.x+ In all cases, the ".x" would be a *specific* Python version. Thomas has a very simple proof of concept implementation at https://github.com/geofft/pythonmux/blob/master/pythonmux.c that just uses "/usr/bin/pythonX.Y" as its registration mechanism for making the launcher aware of additional runtimes. It seems to me that this would be an excellent starting point for preserving "/usr/bin/python" compatibility for end user scripts. Providing such a runtime multiplexer would also potentially provide a way to introduce per-user configuration of the "default Python", such that a user could run their *own* scripts in a different Python interpreter by default (e.g. an SCL, or PyPy), without having to touch the default Python at the system level (i.e. when running Python scripts as root). Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Status update: Python 3 as default on Fedora installs
by Miro Hrončok 14 Jul '15

14 Jul '15

Hi, just sharing a bit of information about our effort towards Python 3 as default in Fedora. About a week or two ago FESCo approved a System Wide Change for Fedora 23: let's make python3 the only python interpreter on default installs [1][2]. We are currently aiming to get Python 3 as the only Python interpreter on Fedora Workstation, Cloud, Atomic host and last but not least, Server. While the majority of packages required to be ported to Python 3 are already ready, there are still packages requiring some work. For Workstation, Cloud and Atomic host, here is the list: Need porting and/or are currently being ported: * abrt * audit * policycoreutils * setroubleshoot * system-storage-manager Require packaging work on Fedora level: * iscsi-initiator-utils * libtalloc * nfs-utils * sos * atomic * docker * icfg For the general idea, see the whole picture (table actually) [3]. I would like to thank all the contributors, who are helping us with this. We are working on a special Fedora Badge for this Python 3 effort [4]. [1] https://fedorahosted.org/fesco/ticket/1450 [2] https://fedoraproject.org/wiki/Changes/Python_3_as_Default [3] https://fedoraproject.org/wiki/User:Churchyard/python3 [4] https://fedorahosted.org/fedora-badges/ticket/386 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel July 2015