Hi,
On 2022-01-23 20:50:23 -0500, Tom Lane wrote:
> Andres Freund <[email protected]> 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
