bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?

[Ludovic Courtès]

Hello!

Tanguy LE CARROUR <tanguy@bioneland.org> skribis:

> I’m pretty sure you know everything that I’m about to write, but better
> say it out loud…

Nope, I know nothing (I’ve just been told about using ‘pyproject.toml’
and it seemed to kinda make sense. :-))

> For a "standard modern" project managed with Poetry, the Python source
> package contains `PKG-INFO` and `pyproject.toml ` that both contain
> the run time dependencies. The wheel package only contains `METADATA` that
> lists the dependencies. The source only contains a `pyproject.toml`.
> To make the installed package as small as possible, tests files and
> uncompiled assets are not (should not be) included.
> From a Guix stand point, it’s better to build from source to be able to
> run the test suite.
>
> For the `python-pypugjs` you used as an example, we build from source,
> so I guess the question does not arise. If we were to use the packages
> available on PyPI, what I said above is *NOT* confirmed 😱:
> - wheel (`.whl`) only contains `METADATA` with the dependencies; **BUT**
> - source (`.tar.gz`) contains `PKG-INFO` (without dependency information),
>   `pyproject.toml` (with dep’) and `setup.py` (also with dep’).
>
> … "fun" fact, the information in `pyproject.toml` are **NOT** the same as
> the one in `setup.py`!? 🤯 `pyproject.toml` says that `nose` is a run time
> dependency (which it is not), but `setup.py` properly lists it in 
> `tests_require`.

Oh my, such a mess.

> So, my answer would be: do not import from PyPI! Yes, I know, it’s radical! 😅
> But if you have to, rely on the wheel’s `METADATA` file.
>
> I hope this make sense. … I’m not really sure any more! 😅

It does!

But then I mean, we could offer, say, ‘guix import upstream https://…’,
and that thing could parse ‘setup.py’ or similar to produce a package
definition from that.  Maybe that’s what you had in mind: import
straight from upstream rather than via PyPI?

Thanks,
Ludo’.