> 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 > >
