python executable
The __os_install_macro defines some post-processing activities during an rpm
build; one of the scripts it calls is brp-python-bytecompile, which can take
an argument: the python executable with which to byte-compile .py files in the
package payload.
In some older versions of rpm (e.g. in RHEL 6), this invocation doesn't pass
in an argument, and brp-python-bytecompile defaults to using /usr/bin/python,
which can lead to the .py files being byte-compiled for the wrong version of
python. This has been fixed in later versions of rpm by passing in
%{__python} as an argument to brp-python-bytecompile.
Workaround this by detecting if __os_install_post has a 0-argument invocation
of brp-python-bytecompile, and if so generating an equivalent macro that has
the argument, and explicitly provide the new definition within the specfile.
python executable
The __os_install_macro defines some post-processing activities during an rpm
build; one of the scripts it calls is brp-python-bytecompile, which can take
an argument: the python executable with which to byte-compile .py files in the
package payload.
In some older versions of rpm (e.g. in RHEL 6), this invocation doesn't pass
in an argument, and brp-python-bytecompile defaults to using /usr/bin/python,
which can lead to the .py files being byte-compiled for the wrong version of
python. This has been fixed in later versions of rpm by passing in
%{__python} as an argument to brp-python-bytecompile.
Workaround this by detecting if __os_install_post has a 0-argument invocation
of brp-python-bytecompile, and if so generating an equivalent macro that has
the argument, and explicitly provide the new definition within the specfile.
Bug reported by Hartmut Goebel and patch contributed by Carl Robben.
Carl tested the fix and we have a buildbot with rpm installed, so I’m
committing even though I could not run this test (but I do understand
the changed code :)
* Use str.startswith(tuple): I didn't know this Python feature, Python rocks!
* Replace sometimes sys.platform.startswith('linux') with
sys.platform == 'linux'
* sys.platform doesn't contain the major version on Cygwin on Mac OS X
(it's just 'cygwin' and 'darwin')
The changed behavior of sdist in 3.1 broke packaging for projects that
wanted to use a manually-maintained MANIFEST file (instead of having a
MANIFEST.in template and letting distutils generate the MANIFEST).
The fixes that were committed for #8688 (76643c286b9f by Tarek and
d54da9248ed9 by me) did not fix all issues exposed in the bug report,
and also added one problem: the MANIFEST file format gained comments,
but the read_manifest method was not updated to handle (i.e. ignore)
them. This changeset should fix everything; the tests have been
expanded and I successfully tested the 2.7 version with Mercurial, which
suffered from this regression.
I have grouped the versionchanged directives for these bugs in one place
and added micro version numbers to help users know the quirks of the
exact version they’re using.
Initial report, thorough diagnosis and patch by John Dennis, further
work on the patch by Stephen Thorne, and a few edits and additions by
me.
build_scripts command of packaging now handles correctly non-ASCII path (path
to the Python executable). Open and write the script in binary mode, but ensure
that the shebang is decodable from UTF-8 and from the encoding of the script.
non-ASCII path (path to the Python executable). Open and write the script in
binary mode, but ensure that the shebang is decodable from UTF-8 and from the
encoding of the script.
non-ASCII path (path to the Python executable). Open and write the script in
binary mode, but ensure that the shebang is decodable from UTF-8 and from the
encoding of the script.
Brett Cannon
doko@ubuntu.com
Terry Jan Reedy
Andrew Svetlov
Éric Araujo
Vinay Sajip
Jesus Cea
Antoine Pitrou
David Malcolm
Nick Coghlan
Brian Curtin
Éric Araujo
Victor Stinner
Senthil Kumaran