Review Request 126345: PythonMacros: specify destination directory in byte-compiled files

[Alex Merry]

> On Dec. 14, 2015, 6:24 p.m., Alex Merry wrote:
> > Seems sensible to me. Are there any potential Python2 vs Python3 issues?
> 
> Raphael Kubo da Costa wrote:
>     I don't think there are any -- the `.pyc/.pyo` files are installed with a different name into a different location on Python >= 3.2, but that is already taken care of by the macro. This patch only deals with the path where the `.py` file gets installed, which it does not change.
>     
>     The only problem I see is in the use of the `argparse` module: it does not exist on Python < 2.7, Python 3.0 and Python 3.1. If that's an issue, I can rewrite the code to use `optparse`, which is deprecated but exists on all Python versions, including the deprecated ones.

I guess it depends whether it effectively causes a dependency bump over what was previously required, and whether that will have any practical impact on people upgrading kdelibs if it does (ie: does anyone actually use those Python versions any more?).


- Alex


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126345/#review89485
-----------------------------------------------------------


On Dec. 14, 2015, 4:48 p.m., Raphael Kubo da Costa wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126345/
> -----------------------------------------------------------
> 
> (Updated Dec. 14, 2015, 4:48 p.m.)
> 
> 
> Review request for Build System, kdelibs and Alex Merry.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> -------
> 
> The `PYTHON_INSTALL()` macro is a wrapper around the `py_compile` Python module that also installs the byte-code (.pyc) file it generates.
> 
> However, when a .py file is passed to `py_compile` without any additional arguments, its full path is recorded in the .pyc file. This is problematic, as most distributions install all files into a build root instead of simply copying files to `/` as part of the packaging process. In this case, the generated .pyc file will have something like
>     /wrkdir/buildroot/usr/lib/python2.7/site-packages/Foo/my_module.py
> in it. Not only does this show up in exception tracebacks, but if the user later invokes `my_module.py` and has write access to `my_module`'s directory, `my_module.pyc` will be rewritten with the right path to `my_module.py` (without the build root). This can lead to uninstallation errors if the package management system checks each file before removal, for example.
> 
> Fix it by rewritting the `PythonCompile.py` script so that it takes a `--destination-dir` argument that we use to pass the full path to `my_module.py` instead of letting it be (wrongly) deduced.
> 
> 
> Diffs
> -----
> 
>   cmake/modules/PythonCompile.py 156fea2 
>   cmake/modules/PythonMacros.cmake 6a82d88 
> 
> Diff: https://git.reviewboard.kde.org/r/126345/diff/
> 
> 
> Testing
> -------
> 
> Fedora has packaging macros that will regenerate .pyc and .pyo files with the right paths as part of the build, so it is not affected. Debian disables this macro in pykde4, FreeBSD and openSUSE contain wrong paths in its .pyc files. With this patch, I was able to verify with `hexdump` that the right path is present in the .pyc files installed by pykde4.
> 
> 
> Thanks,
> 
> Raphael Kubo da Costa
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20151214/f430f1c9/attachment.html>