11:11 p.m.
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.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
5:50 p.m.
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
5:53 p.m.
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<
5:57 p.m.
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
3104
days inactive
3104
days old
python-devel@lists.fedoraproject.org
3 comments
3 participants
participants (3)
-
Jason L Tibbitts III -
Orion Poplawski -
Zbigniew Jędrzejewski-Szmek