Dne 16. 12. 19 v 12:46 Petr Viktorin napsal(a):
> On 2019-12-16 12:22, Vít Ondruch wrote:
>>
>> 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.
>
> I'm afraid your proposal doesn't open it wide enough: to support
> py-less installs, it will have to be changed (or removed) anyway.
Not sure what does "py-less installs" mean ¯\_(ツ)_/¯
> I also disagree disagree about the extra complexity, if only in the
> packager's mental model: "%pycached" expands to the given file and its
> cache; "%pyfile" writes these to a file and then lets you use "%files
> -l" to read that file back in.
I am not saying this is the best name. This is the first name I was able
come with which makes at least a bit of sense.
>
> Also, "%pyfile" would introduce extra issues. For example, how would
> one split several Python modules across several subpackages?
>
My proposal is high level idea. It is easy to shot it down based on "how
would one split several Python modules across several subpackages?". Of
course next step would be to output to wile lists, one for py files
while the other for pyc files. If you are talking about other possilbe
subpackages, it could be possible to use some parameter, or block to
create appropriately named file list.
Vít
_______________________________________________
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
