Hello! Tanguy LE CARROUR <tan...@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’.
