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.
Toml parsing is bundled in pip. We could possibly use that instead of an
additional package, but the API for this is "private" and might change any time.
pip itself is used to build the package via pyproject.toml specified build
backend. We could possibly re-implement everything in the pyproject macros
project, but given that pip is driving the pyproject.toml standard, we would
just be in constant need to follow up pip recent development. Not to mention
NIH. We didnt want to go that way.
Setuptools and wheel is your build backend specified in pyproject.toml (or the
assumed default). If the upstream chooses to use e.g. flit, sheel would not be
needed.
Technically, the package gained more dependencies when compared with plain
"python setup.py build/install". However it is now built differently, more
close to how things are done in upstream. Frankly speaking the "python setup.py
build/install" is becoming so heavily obsoleted that I suspect modern projects
to drop setup.py soon-ish.
The entire idea here is that there are more build backends to choose from. Hence
depending on the upstream choices, you'll get:
(py)toml - to parse the files in our macros
pip - the build frontend
"whatever" - the build backed
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
