Current copyright notice says @torsava. Since others including me contributed, I suggest to make it one of the following:

• Red Hat Inc.
• @torsava and other PRM Porting Guide contributors (link to GitHub repo contributors)

It would also be good if this thing was somehow Creative Commons (BY-SA maybe) and the examples Public Domain, otherwise it is useless for others, legally speaking.

Any chance we can move this repo to fedora-python organisation?

In that case, I get the notification e-mails to @redhat.com address and not to my personal one.

@hroncok , @encukou I encountered a bit of a problem.

For the section "Porting an application and a module in one package" we have a package python-example that contains both a Python module and an Python version-independent application.

In compliance with the guidelines we have to package the Python 3 version of the application, and therefore we can include it in the Python 3 subpackage or create a new subpackage named just example that will depend on the Python 3 subpackage.

The problem is, the users that have python-example currently installed: If they do dnf update the dnf will replace the python-example package with the python2-example package (as it contains the currently active %python_provide macro), and therefore will lose the bundled application from their system.

A subsequent problem is also that after this change the packager will have to find all packages that depend on this package, figure out which of them depend on the application, and then change the Requires tag in all those packages to require the new Python 3 subpackage or the application subpackage.

I can't find a better way around this, any idea?

In many cases, it's not necessary to rewrite shebangs in %prep, because setuptools sets shebangs of scripts it installs. So the find/sed lines should only be necessary if setuptools entry points are not used, for example if executables are copied to /usr/bin directly using cp or make.

I've seen applications written in Python that used Makefiles to install themselves.
In this guide, we assume every Python package is nicely done invoking the setup.py. Do we want to cover any other case? At least in some general manner?

See:

https://src.fedoraproject.org/rpms/chromium/pull-request/11

chromium used a copy pasted sed from our guide. yet it was wrong.

The problematic shebang was (something like):

#! /usr/bin/env python

Notice the space.

BTW Instead of fixing the shebang in the guide and making it even more complicated, we can recommend pathfix.py as described in #24

There is a script in /usr/lib64/python3.6/Tools/scripts/pathfix.py that changes shebangs. We may want to:

• recommend that in the shebang sections of this guide
• use it automagically in rpm builds to fix shebangs? (with similar logic to pybytecompile script)

I'm opening this here, because of the first above point. If we say we want to use this automatically, we can discuss this in some ML.

Example usage:

%install
...
%{python3_sitearch}/Tools/scripts/pathfix.py -i "%{__python3} -s" -p %{buildroot}%{_bindir}/*

Note: A small problem with this script is that it only converts files where the name matches r'^[a-zA-Z0-9_]+\.py$' when called on directory, but you can call it directly on files.

Shebangs are often forgotten and drag python2 dependency.

I didn't find anything about this in the guide, maybe we can mention it?

Note that proper installs using setup.py might not have such problem, but other means of installation probably will. So this might go near the note about custom install scripts.

How does having a plugin system justifies having both legacy Python and Python 3 version packaged?

What about a module that other packages use, but with executables?