I just ran into an issue with a package under review where stray python2 .pyc files were getting put into the python3_sitelib directory. The tests were run with:
PYTHONPATH=%{buildroot}%{python3_sitelib} py.test-%{python3_version} -vv
and one of the tests ended up calling /usr/bin/python.setup.py --version triggering the loading and byte-compiling of the installed module. I don't know if this is common issue or not (I suspect not). Just a heads up I guess. Not sure if this is something that can be prevented in any other general way.
On Mon, Oct 19, 2015 at 10:11:12PM -0600, Orion Poplawski wrote:
I just ran into an issue with a package under review where stray python2 .pyc files were getting put into the python3_sitelib directory. The tests were run with:
PYTHONPATH=%{buildroot}%{python3_sitelib} py.test-%{python3_version} -vv
and one of the tests ended up calling /usr/bin/python.setup.py --version triggering the loading and byte-compiling of the installed module. I don't know if this is common issue or not (I suspect not).
I think it happens regularly:
$ dnf whatprovides '/usr/lib64/python3.4/site-packages/*'|grep fc|cut -d' ' -f1 > /tmp/list $ dnf repoquery -l $(cat /tmp/list)|grep -v __pycache__|grep 'python3.4.*py[co]$'|grep -v doc /usr/lib64/python3.4/site-packages/arc/__init__.pyc /usr/lib64/python3.4/site-packages/arc/__init__.pyo /usr/lib64/python3.4/site-packages/arc/common.pyc /usr/lib64/python3.4/site-packages/arc/common.pyo /usr/lib64/python3.4/site-packages/arc/communication.pyc /usr/lib64/python3.4/site-packages/arc/communication.pyo /usr/lib64/python3.4/site-packages/arc/compute.pyc /usr/lib64/python3.4/site-packages/arc/compute.pyo /usr/lib64/python3.4/site-packages/arc/credential.pyc /usr/lib64/python3.4/site-packages/arc/credential.pyo /usr/lib64/python3.4/site-packages/arc/data.pyc /usr/lib64/python3.4/site-packages/arc/data.pyo /usr/lib64/python3.4/site-packages/arc/delegation.pyc /usr/lib64/python3.4/site-packages/arc/delegation.pyo /usr/lib64/python3.4/site-packages/arc/loader.pyc /usr/lib64/python3.4/site-packages/arc/loader.pyo /usr/lib64/python3.4/site-packages/arc/message.pyc /usr/lib64/python3.4/site-packages/arc/message.pyo /usr/lib64/python3.4/site-packages/arc/security.pyc /usr/lib64/python3.4/site-packages/arc/security.pyo /usr/lib64/python3.4/site-packages/cairo/__init__.pyc /usr/lib64/python3.4/site-packages/cairo/__init__.pyo
I filed https://bugzilla.redhat.com/show_bug.cgi?id=1273661 https://bugzilla.redhat.com/show_bug.cgi?id=1273662 but since this shouldn't cause any problems, it's a minor issue. Probably not worth an automated check. There's some more .py[co] files in documentation directories, which are probably not useful either.
Zbyszek
In the new python macros that some folks have been writing, we could easily pass -B or export PYTHONDONTWRITEBYTECODE in the %check section. Would this be a reasonable thing to do?
- J<
On Tue, Oct 20, 2015 at 05:53:45PM -0500, Jason L Tibbitts III wrote:
In the new python macros that some folks have been writing, we could easily pass -B or export PYTHONDONTWRITEBYTECODE in the %check section. Would this be a reasonable thing to do?
I think it would, considering that we run bytecode compilation later on anyway.
Zbyszek
python-devel@lists.fedoraproject.org
-
Jason L Tibbitts III -
Orion Poplawski -
Zbigniew Jędrzejewski-Szmek