Hi, Quoting Tanguy LE CARROUR (2024-03-26 17:55:23) > Quoting Ludovic Courtès (2024-03-26 17:04:52) > > Tanguy LE CARROUR <tan...@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
