Thanks for the reply!

What throws me for a loop is that support for C extensions isn't documented in https://setuptools.readthedocs.io/en/latest/ , nor is there any mention of how to do something equivalent to the current "python setup.py build", so I can't tell what is "official" regarding continued setuptools support for my current use of distutils.

Here's how my setup.py starts:

  from setuptools import setup
  from distutils.core import Extension
  from distutils.command.build_ext import build_ext

I use Extension() to define the C extension.

I use build_ext to create a subclass which figures out the appropriate OpenMP compile and link flags, which depend on the compiler being used.

I also use that build_ext subclass to handle code generation. This Python code replaced a horribly complex set of preprocessor #defines and made it much easier to debug and profile the code.

Oh, and macOS's default C compiler doesn't support OpenMP so I added support for disabling the OpenMP flags, for example, with:

   CHEMFP_OPENMP=0 pip install chemfp-3.5.1.tar.gz

I looked at poetry. It says "only pure python wheels are supported", so that's not (yet?) a replacement for distutils, yes?

And it looks like pyproject.toml is supposed to replace MANIFEST/MANIFEST.in ?

Lastly, I have a commercial product. I prefer to distribute source code to my customers. I grudgingly provide pre-compiled wheels for Linux, which people use for evaluation. My main source repository has the license check code ("src/chemfp_lm.h"), which is used to make the wheels. The MANIFEST.in excludes src/chemfp_lm.h during the sdist that goes to my paying customers. To handle source compilation for both cases, setup.py changes the Extension() configuration depending on if src/chemfp_lm.h is present.

This was simple using distutils. I have no clue how to replace distutils in the first place, much less be able to handle my special case in this future Python world.

Or as you say, "all kinds of weird native interops".

FWIW, my code still supports 2.7 and 3.6+, and has no required dependencies on other Python packages, so I didn't realize there was a problem. ;)

To be clear, I have optional dependencies on "zstandard" (in PyPI), on three computational chemistry packages with Python APIs but which aren't available through PyPI, and on one Java computational chemistry JAR file, connected via jpype (in PyPI) and itself with an optional dependency on a ZStandard JAR file.

Which means pip-resolvable dependencies hasn't been something I've had to care about over the last 11 years of development.