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

[Tanguy LE CARROUR <tanguy@bioneland.org>]

Hi,

Quoting Tanguy LE CARROUR (2024-03-26 17:55:23)
> Quoting Ludovic Courtès (2024-03-26 17:04:52)
> > Tanguy LE CARROUR <tanguy@bioneland.org> skribis:
> > > 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.
> […]
> So I would say… let’s wait and see what the others think. In the
> meantime, I’ll have to dive deeper in the PEP and the actual importer
> code.

According to PEP 427 [1] a.k.a. Binary distribution format [2], if you
go for packaged/PyPI then we should go for `METADATA`.

[1]: https://peps.python.org/pep-0427/
[2]: https://packaging.python.org/en/latest/specifications/binary-distribution-format/#the-dist-info-directory

But, as stated earlier, we should build from source, to make sure we can
run the test suite. Active projects should slowly migrate to PEP 517 [3]
`pyproject.toml`. But, this is not a solution! 😱 This is actually yet
another problem! 😵

[3]: https://peps.python.org/pep-0517/

Each build system relies on it’s own file organization. For instance, Poetry
looks for a `[tool.poetry.dependencies]` section in the file. So the
importer should be "build system aware", which leads us to… `guix import poetry URL`!?
Not really generic any more! 😞

I guess we should sleep on it…

-- 
Tanguy