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