#1245 organize python 2/3 cases in spec file
Merged by mikem. Opened by mikem.
mikem/koji py23macros  into  master

Download 1245.patch

This is a follow up to the three py3 PRs merged earlier -- #1117, #891, and #921. This may need further adjustment. Feedback welcome.

This is an attempt to streamline the various py2/3 support cases we need to cover. Some targets are p2 only, others py3 only, and other both to different degrees.

@tkopecek please have a look

sed -e "s|#!/usr/bin/python2|#!/usr/bin/python3|" $RPM_BUILD_ROOT/usr/bin/koji is more readable...

@mikem The koji-utils and koji-vm content looks like they have Python 3 adaptations, so why can't they build for Python 3?

This will not work, since it's generated by brp-python-bytecompile later...

Added few things: #a92778c #1159de6 (https://pagure.io/fork/tkopecek/koji/commits/py23macros-tkopecek)

Btw, broken case I've hit was py2=1, py3=2 on F29. In such cases hub files were bytcompiled for py2 even if they were not packaged.

The koji-utils and koji-vm content looks like they have Python 3 adaptations, so why can't they build for Python 3?

Ah, it appears you are correct. I'd been focused on the three recent ones (hub, web, builder), and I'd simply forgotten that PR #685 included py3 work for utils. I don't know how thorough that work was though. A casual run of kojira with python3 seems to work. I'll adjust that then. Thanks

Btw, broken case I've hit was py2=1, py3=2 on F29. In such cases hub files were bytcompiled for py2 even if they were not packaged.

yep, this is because on F29 the __python macro is still pointed at python2. Our settings remain p2=2,p3=1 on f29, which works, and p2=1,p3=2 works for F30 at least in my testing.

I guess I might need to do something about the auto-byte-compiling, but I'm not sure the best way yet, particularly with the approach being quite different across recent Fedoras

https://fedoraproject.org/wiki/Packaging:Python_Appendix#Manual_byte_compilation

sed -e "s|#!/usr/bin/python2|#!/usr/bin/python3|" $RPM_BUILD_ROOT/usr/bin/koji is more readable...

good call

https://pagure.io/fork/tkopecek/koji/commits/py23macros-tkopecek

I have a few concerns with simply turning off _python_bytecompile_extra

  1. this is theoretically f29+ only
  2. we've been building with it on so far, we might be dropping some compiled files

I would just go ahead and say just always do byte compilation to keep it consistent with EL and older Fedoras. I do this with Pagure and MirrorManager2 in EPEL and Fedora.

I would just go ahead and say just always do byte compilation to keep it consistent with EL and older Fedoras. I do this with Pagure and MirrorManager2 in EPEL and Fedora.

The trick here are the .py files we have outside of python[23]_sitelib. These extra files are auto compiled with %{__python} (only) which is often not quite the right thing. The Fedora guidelines suggest disabling auto compilation and triggering it manually, but the details vary across Fedora versions.

Granted, Koji's Makefiles do their own byte compilation. We've had that in place since before the magic macros I think. However, auto compilation does things a little differently (e.g. it also generates .pyo files, while the Makefiles just generate .pyc files).

5 new commits added

  • manually trigger extra byte compilation
  • handle byte-compiling for fedora
  • remove qpid requires
  • vm and utils subpackages for py3 too
  • more readable sed expression

:thumbsup:

rebased onto 712b5af825450dcace01ad5979518461b6a3b924

1 new commit added

  • keep config in koji-web package

Metadata Update from @jcupova:
- Pull-request tagged with: testing-ready

+1 for koji 1.17

I'm not sure if we shouldn't switch from Makefile to setuptools later (as there is already setup.py for PyPi upload). It is de facto standard these days and automatic macros probably would behave more transparent with such input.

btw. .pyc generated by make are overwritten by autocompilation on Fedora anyway.

Metadata Update from @jcupova:
- Pull-request untagged with: testing-ready

I'm not sure if we shouldn't switch from Makefile to setuptools later

Agreed, though I think we'll want to rearrange a number of things to do that effectively. I'd be interested in pursuing that for 1.18

I think this is good to go as-is. We can look at replacing the Makefile with setuptools in 1.18, and when we do that, we can have a larger conversation about how Koji should be structured for that.

Commit dc7b367b fixes this pull-request

Pull-Request has been merged by mikem

Metadata