On 30. 11. 19 18:54, Neal Gompa wrote:
On Sat, Nov 30, 2019 at 12:49 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
On 30. 11. 19 17:26, Dominik 'Rathann' Mierzejewski wrote:
1. It actually generates more BRs than I specify manually (I had 3). It
adds python3-wheel and it brings in python3-pip and python3-pytoml on it
own, so my package ends up with 4 additional BRs for no apparent gain.
python3-pytoml or python3-toml is used to parse the pyproject.toml file.
Unfortunately, while the toml format has been selected for this file, a
standardized python packaging file, there is no toml parser in the stdlib. This
might change in the future some day, but this is what we have now.
Has anyone considered proposing a PEP to mainline a TOML parser
implementation into the standard library yet? We're now nearly two
years into PEP 517 being in force and with Python 2's EOL, I suspect
we'll see the classical setup.py method go away very rapidly. I know
that for my personal projects, the only reason I haven't migrated to
Poetry is because I'm being asked to keep Python 2 compatibility
upstream and dealing with environments running Python 2 makes
pyproject.toml stuff annoying (as they're usually quite old and don't
support it).
Yes and no. See
https://mail.python.org/archives/list/python-ideas@xxxxxxxxxx/thread/HOZNLCLYPKVCOADNKPTQJDUTNCNZZNZF/#HOKQOMMX2XSS5R2SMXJEHLKXNLW6MVE7
https://github.com/python/peps/issues/1133
2. It would be useful if it generated the file list automatically, too.
I had to drop .egg-info and .dist-info manually.
It would. I don't know if we track this somewhere but it is certainly on our
radar. Patrik (CCed) is working on it.
I have done some API drafting and based on RPM limitations, we might end up with
something like this:
%files -n python3-foo -f %{pyproject_files}
Note however that it has a certain drawback. If your "foo" package decides to
suddenly starts installing %{python3_sitelib}/requests or even %{_bindir}/rpm,
you will not be able to prevent it via a more strict file rules. That's why I
would also like to offer more "soft" option of this, that would be used somewhat
like this:
%files -n python3-foo -f %{pyproject_metadata}
%{_bindir}/abc
%{python3_sitelib}/xyz/
I.e. it would only contain the dist-info directory. Possibly pycache.
With the dist info directory file list generated (in both concepts), we would be
able to do things like this:
%dir %{python_sitlib}/foo-%{py_version}.dist-info
%license %{python_sitlib}/foo-%{py_version}.dist-info/LICENSE.txt
%{python_sitlib}/foo-%{py_version}.dist-info/...
That would however require an upstream way to mark the license file as a license
file. I plan to explore that option early next year.
I'm generally not a fan of the whole generated filelist thing, but
I'll reserve judgement until we have a better idea of what this would
look like.
The general idea I start to like is that the "allowed" (in Fedora) option would
be %{pyproject_metadata} and that would only ever include the dist-info
directory and assertions would be made about it, such as it is only one of them.
Technically all files macro would be possible for fully automated setups, but I
would probably like it banned in regular Fedora.
That is however just my personal view, not an actual plan.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
