distutils deprecated

[coretl]

Distutils will be deleted in 3.12, and emits a DeprecationWarning:
Use setuptools or check PEP 632 for potential alternatives

The only runtime reference I can see is:
https://github.com/mdavidsaver/epicscorelibs/blob/cefd192d0cd4ab03e57cb908f14874f8ac56a1ae/src/python/epicscorelibs/config.py#L29

And PEP632 suggests using sysconfig instead: https://peps.python.org/pep-0632/#migration-advice

What does distutils.sysconfig provide that sysconfig does not?

[mdavidsaver]

I don't recall exactly why I had the fallback to distutils.sysconfig. Presumably I found that some older cpython didn't have 'CC' in sysconfig. From a quick check, it isn't necessary with 2.7.18 or 3.9.2.

fyi. The larger problem with distutils will be felt by setuptools-dso (epics-base/setuptools_dso#24) where things are not so simple. eg.

from distutils.sysconfig import customize_compiler

Isn't readily replaceable.

[mdavidsaver]

And PEP632 suggests using sysconfig instead: https://peps.python.org/pep-0632/#migration-advice

I've come across this "advice" before. It left me hoping to find some more concrete statement from the setuptools developers. Their recently demonstrated willingness to ~intentionally break API leaves me hesitant to guess at what will be supported.

[coretl]

I wonder if any of the new build tools will do this any better?

[mdavidsaver]

I wonder if any of the new build tools will do this any better?

Which are?

The only one which comes to my mind is meson, which numpy seems to be leaning towards. I haven't looked into this enough to know how large the impedance mismatch would be.

[mdavidsaver]

28d3b0b removes the distutils imports for this package. I am still uncertain about what course take with setuptools_dso, which probably doing nothing until something breaks.

[eli-schwartz]

I've come across this "advice" before. It left me hoping to find some more concrete statement from the setuptools developers. Their recently demonstrated willingness to ~intentionally break API leaves me hesitant to guess at what will be supported.

That advice is very careful to state "It is current at time of writing, but is not kept up to date." In other words, it's a best effort attempt to offer users some hopeful leads to investigate -- it's not some sort of stability guarantee. :P

I would personally suggest getting out of the business of monkey-patching setuptools or otherwise using its API for anything more than setup() / find_packages() / find_namespace_packages / Extension(). Although I may be biased...

Conveniently, that's all stuff that setuptools supports via setup.cfg, aside for Extension(), and... setuptools would like to add support for defining extensions via setup.cfg which would presumably "solve" that. :P

[coretl]

I wonder if any of the new build tools will do this any better?

Which are?

I was looking at Hatch the other day and noticed that it has a plugin for mypyc integration for building C extensions from pure Python code. Used in black. Doesn't help here, but maybe a sign of other plugins to come?

[mdavidsaver]

... it's a best effort attempt to offer users some hopeful leads to investigate ...

This is how I read PEP632, and what I have tried to do. However, my attempts to investigate have so far not been as fruitful as I had expected. I have only found some bits and pieces of advice from sources I don't trust to be authoritative. eg. commenters on github issues. Thus my grumbling. Still, maybe I'm not putting the right keywords into google...

... getting out of the business of monkey-patching setuptools ...

I would like to get out of this business. At the same time, I don't want to re-invent the whole of the setuptools ecosystem as a prerequisite to what I want to focus on. I am hoping that as the dust settles on the distutils situation, I will continue to be able to build onto setuptools.

... aside for Extension() ...

The effects I want to achieve revolve around compiled extensions, and their dependencies. So I really can't set this aside.