Dne 16. 12. 19 v 11:22 Petr Viktorin napsal(a):
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.
I think I understand and agree with your concerns and you are right that
I don't understand the details, because I was not aware about the
placement of *.pyc files. But I disagree with that it "is a lot more
than a macro to simplify current practice"
The Miro's proposal is to replace:
~~~
%files
%{python3_sitelib}/foo.py
%{python3_sitelib}/__pycache__/foo.cpython-38.*.pyc
~~~
by
~~~
%pycached %{python3_sitelib}/foo.py
~~~
which is IMO making any future progress harder. Instead, my proposal is
to replace:
~~~
%install
... snip ...
%files
%{python3_sitelib}/foo.py
%{python3_sitelib}/__pycache__/foo.cpython-38.*.pyc
~~~
by
~~~
%install
... snip ...
%pyfile %{python3_sitelib}/foo.py
%files -l pyfiles.lst
~~~
This does not add any complexity while it helps to abstract away the
.py/.pyc. IOW it still removes the "pyc" lines, while it opens the door
for the future.
Vít
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.
>>