On Mon, Dec 16, 2019 at 12:46 PM Petr Viktorin <pviktori@xxxxxxxxxx> wrote:
>
> 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.
> 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.
>
> Also, "%pyfile" would introduce extra issues. For example, how would one
> split several Python modules across several subpackages?
Yeah, I think using file lists works OK-ish for some things
(translations with %find_lang, Java packaging, etc.), but it doesn't
really map to the way python packages work in fedora.
On the other hand, Miro's proposal is an incremental improvement over
the status quo without introducing more complexity (it just expands
one %files entry into two), and as such, I think it's a good idea.
Fabio
> _______________________________________________
> 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
_______________________________________________
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
