GNU bug report logs -
#69997
Should ‘guix import pypi’ get dependencies from pyproject files?
Previous Next
Full log
View this message in rfc822 format
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 <at> 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
This bug report was last modified 209 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.