Re: Provisional pyproject RPM macros: Dynamic BuildRequires for Python packages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux