Re: Replace uses of deprecated Python module distutils.sysconfig

Hi,

On 2022-01-23 20:50:23 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I think this might be problem on our own end, actually. The distutils.sysconfig
> > code did
> > a = '-I' + distutils.sysconfig.get_python_inc(False)
> > b = '-I' + distutils.sysconfig.get_python_inc(True)
> > which the patch upthread  changed to
> > +a = '-I' + sysconfig.get_path('include')
> > +b = '-I' + sysconfig.get_path('platinclude')
> > but I think that's possibly not quite the right translation?
>
> I don't buy it.  The sysconfig documentation says pretty clearly
> that get_path('include') and get_path('platinclude') are supposed
> to return the directories we want, and there's nothing there
> suggesting that we ought to magically know to look in a
> non-default scheme.

I'm not really convinced. Note that the whole thing is prefixed with

  Every new component that is installed using distutils or a Distutils-based
  system will follow the same scheme to copy its file in the right places.

and then

  Each scheme is itself composed of a series of paths and each path has a
  unique identifier. Python currently uses eight paths:

and that get_path()'s documentation says:

  If scheme is provided, it must be a value from the list returned by
  get_scheme_names(). Otherwise, the default scheme for the current platform is
  used.

(with some 2.7 vs 3.x differences)

The list of schemas explicitly includes stuff like posix_home, posix_user,
nt_user, which all won't contain python.h in 'include'.  I don't see anything
implying scheme on some platform isn't *_user or such.


> > But even so, it seems using sysconfig.get_config_vars('INCLUDEPY') or such
> > seems like it might be a better translation than the above
> > sysconfig.get_path() stuff?
>
> Can you find ANY documentation suggesting that INCLUDEPY is
> meant as a stable API for outside code to use?  That seems
> far more fragile than anything else we've discussed, even
> if it happens to work today.

No, not really. There generally seems to be very little documentation about
what one is supposed to use when embedding python (rather than building a
python module). The only thing I really see is:

https://docs.python.org/3/extending/embedding.html#compiling-and-linking-under-unix-like-systems

which says to use python-config.

Note that we are already using get_config_vars() for LIBDIR, LDLIBRARY,
LDVERSION, VERSION, LIBS, ... which all seem equally undocumented.


> I remain of the persuasion that these Debian packages are
> broken.  The fact that they've not perpetuated the scheme
> into their python3 packages shows that they came to the
> same conclusion.

Yea, I don't like it at all.


Greetings,

Andres Freund