On 2019-12-16 10:19, Vít Ondruch wrote:
I though about this a bit and to be more constructive, I think that you
should probably move the file list creation out of %files section. Do it
probably in %install section instead. That way, you would have more
flexibility. You could have something like "%pyfile
%{python3_sitelib}/foo.py" and it would do on background something like:
~~~
echo %{python3_sitelib}/foo.py > pyfiles.lst
echo %{python3_sitelib}/foo.pyc > pycache.lst
~~~
Later you would just submit these file lists to the appropriate
packages. This would be IMO more flexible.
Vít
I believe this is a good general direction to go in, but the devil is in
the details. You're asking to change the way file lists are generated,
which is a lot more than a macro to simplify current practice.
You seem to want to not have .py files from the system, and only install
.pyc. The basic issue there is that the current way (.py+.pyc) is to
install:
%{python3_sitelib}/foo.py
%{python3_sitelib}/__pycache__/foo.cpython-38.*.pyc
... but to make a lone .pyc importable, it needs to be at:
%{python3_sitelib}/foo.pyc
... i.e. it's not only a matter of omitting the .py file, but you also
need to rename the .pyc.
That is solvable, of course, but it's just the start of the rabbit hole.
There are enough other issues and details to be thought out that I'm not
sure your %pyfile macro would be useful in the end.
(We're actually brainstorming ideas to minimize Python's footprint
internally, but right now is not a good time so start a big flaming
discussion -- many of us are taking a break from computers near the end
of the year. So we're holding the discussion off until next year.)
Back to the proposed %pycached macro: I can see how it looks like a step
backwards, if your goal is minimization. But I believe it's orthogonal,
a step sideways :)
It's meant to make current spec files specify the intent rather than the
implementation, so we're better able to tweak the implementation. (Not
just in released Fedora or CPython, but also for things like experiments
in COPR.)
Dne 12. 12. 19 v 15:36 Miro Hrončok napsal(a):
Hello,
we are considering to add a %pycached macro to be used in the %files
section:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/37
We'd like to receive feedback. We plan to add it to rawhide and
backport it to all Fedoras + EPEL7+.
Usage:
%files
...
%pycached %{python3_sitelib}/foo.py
This will list:
/usr/lib/python3.8/site-packages/foo.py
/usr/lib/python3.8/site-packages/__pycache__/foo.cpython-38{,.opt-?}.pyc
Assuming the Python 3 version is 3.8.
The bytecode files are globbed, their presence is not checked.
This will fail:
%pycached %{python3_sitelib}/foo
error: %pycached can only be used with paths explicitly ending with .py
And so will any of this:
%pycached %{python3_sitelib}/*
%pycached %{python3_sitelib}/foo.*
%pycached %{python3_sitelib}/foo.p?
%pycached %{python3_sitelib}/foo.?y
%pycached %{python3_sitelib}/foo.??
But this will work:
%pycached %{python3_sitelib}/foo*.py
And it will generate the following globs:
/usr/lib/python3.8/site-packages/foo*.py
/usr/lib/python3.8/site-packages/__pycache__/foo*.cpython-38{,.opt-?}.pyc
When used with paths that include Python 3 version, it globs with the
version:
%pycached /opt/python3.10/foo.py
Generates:
/opt/python3.10/foo.py
/opt/python3.10/__pycache__/foo.cpython-310{,.opt-?}.pyc
While paths without version have less strict globs:
%pycached /custom/foo.py
/custom/foo.py
/custom/__pycache__/foo.cpython-3*{,.opt-?}.pyc
This will generate a warning in RPM build:
warning: File listed twice: /custom/__pycache__/foo.cpython-38.opt-1.pyc
However it ensures the optimized bytecode is there.
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
