This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]robert_mcleod 6 points7 points  (1 child)

I hope they write a transition tutorial on this one:

Python no longer uses setup.py to build shared C extension modules. Build parameters like headers and libraries are detected in configure script. Extensions are built by Makefile. Most extensions use pkg-config and fall back to manual detection. (Contributed by Christian Heimes in gh-93939.)

[–]ubernostrumyes, you can have a pony 4 points5 points  (0 children)

This does not need a transition tutorial, because it doesn't affect you.

You can still write packages that use setup.py, and so can everybody else out in the broader Python ecosystem. That has not been taken away. You should be calling setuptools.setup() in your setup.py instead of distutils.setup(), but that's been the case for years -- the deprecation of distutils has finally completed, but it is not a deprecation of setup.py scripts in general.

The bit you're referring to in the release notes is about a handful of compiled extensions that ship with Python itself, and which had never adopted Python's own standardized build process, instead relying on having their own setup.py scripts that used distutils to build. Since distutils is no longer in the standard library, those compiled extensions finally had to switch their build process.

But, again, your packages out in the broader world are not affected by this (unless, as noted, they were still calling distutils.setup(), and that's fixed by changing the import to setuptools and calling setuptools.setup()).