Is there a plan to migrate away from pyproject2setuppy?
salfter opened this issue · 4 comments
Gentoo Linux has masked dev-python/pyproject2setuppy in Portage, probably because upstream is no longer maintained:
pyproject2setuppy is no longer maintained. Thanks to PEP 517, new Python build systems are sprouting very fast, and every single one of them seems to follow the XKCD#927 principle. Copying all the hacks and adding test cases for all the possible scenarios is simply a humongous amount of work. At this point, I have given up and Gentoo is going to utilize PEP 517 entry points directly.
I've unmasked pyproject2setuppy and copied it to my overlay so that it doesn't disappear when it gets yeeted out of Portage, but it sounds like it might not be a bad idea in the longer term to migrate away from using it.
Could you explain the issue a little bit more.....
Where does solidpython use pyproject2setuppy? Or where does it depend on it?
Is it possible, that what you're talking about is a gentoo (packaging?) issue?
pyproject2setuppy seems to me like a gentoo packaging "hack" to install toml based projects. Compare:
https://packages.gentoo.org/packages/dev-python/pyproject2setuppy
I tried uninstalling pyproject2setuppy earlier today when upgrading this package from 1.1.2 to 1.1.3 and got an error. If it is something Gentoo-specific (might be, since it was maintained by a Gentoo maintainer), perhaps I need to poke around a bit over there.
I found this:
https://projects.gentoo.org/python/guide/distutils.html
Looks like Python package developers are drawing the wrong conclusion from xkcd #927 and migrating away from setuptools. This just happens to be the first such package I've run across for which I've needed to write an ebuild to satisfy a dependency for some other package (in this case, KiKit). The fix was simple enough: declare DISTUTILS_USE_PEP517=poetry and remove pypy3 from PYTHON_COMPAT.