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