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).
> 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.
>
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.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
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
