sysconfig.get_config_h_filename() returns the path of pyconfig.h.  The Makefile is also used to return values from sysconfig but it's path is hidden in a non-public method, for no good reason that I can think of.  Therefore, sysconfig._get_makefile_filename() should be renamed to sysconfig.get_makefile_filename().

-1 The Makefile is very implementation specific to CPython.

On Sep 16, 2010, at 06:15 PM, Benjamin Peterson wrote:

>-1 The Makefile is very implementation specific to CPython.

and pyconfig.h isn't?

-Barry

Yes, it's unfortunate that that is exposed. Hopefully, sysconfig will evolve some way to find information independent of implementation.

I don't agree that it's a bad thing that sysconfig exposes implementation specific information - it seems kind of the point of it.

"The sysconfig module provides access to Python’s configuration information like the list of installation paths and the configuration variables relevant for the current platform."

Of course things like sysconfig.get_config_h_filename() should raise an exception or return None on implementations that don't have a pyconfig.h.

Patch attached.

> I don't agree that it's a bad thing that sysconfig exposes
> implementation specific information - it seems kind of the point of it.

Well, it exposes configuration information, for example paths (which should exist in all VMs), but things like the existence of a .h file seem implementation details that should not be public IMO.

On Sep 16, 2010, at 08:27 PM, Éric Araujo wrote:

>Éric Araujo <merwok@netwok.org> added the comment:
>
>> I don't agree that it's a bad thing that sysconfig exposes
>> implementation specific information - it seems kind of the point of
>> it.
>
>Well, it exposes configuration information, for example paths (which
>should exist in all VMs), but things like the existence of a .h file
>seem implementation details that should not be public IMO.

If that's the case, then where should this information be exposed?  I think it
needs to be exposed *somewhere*.  You don't want people just guessing or
reinventing all the file system search code that's already in sysconfig.

I'm also not convinced that the paths and schemes are implementation
agnostic.  For example, you'd have to add schemes for each of the other
implementations (and their variants, e.g. Jython installed on POSIX vs. Jython
installed on Windows).  And clearly, some of the scheme paths described in the
module are pretty specific to autoconf's model of the world.  (Does IronPython
really have platinclude?)

Now, I definitely have my own beefs about sysconfig's API, but it is what it
is, so unless there's a clear alternative, I think sysconfig should expose
information that will be useful for programmatically determining configuration
details of the Python you're running.

Barry's request looks reasonable. Any build information will have platform specificities to it.

On the other hand, this begs the question of why you want to access the Python makefile at all. Is there any information in there that isn't currently exposed? I think it would be nice if people could completely forget about the existence of that file, and instead have nice programmatic APIs to query properties they are interested in.

On Sep 18, 2010, at 12:23 PM, Antoine Pitrou wrote:

>Antoine Pitrou <pitrou@free.fr> added the comment:
>
>Barry's request looks reasonable. Any build information will have
>platform specificities to it.

Thanks.  I'll take that as approval to land it. :)

>On the other hand, this begs the question of why you want to access
>the Python makefile at all. Is there any information in there that
>isn't currently exposed? I think it would be nice if people could
>completely forget about the existence of that file, and instead have
>nice programmatic APIs to query properties they are interested in.

In principle I agree that the parsing of pyconfig.h and Makefile are
implementation details that shouldn't matter.  I'm working on the bug to
pre-parse these at build time and generate a _sysconfig module that sysconfig
would import.  However, for introspection purposes, since pyconfig.h's
location is exposed, I wanted symmetry for Makefile.

> >On the other hand, this begs the question of why you want to access
> >the Python makefile at all. Is there any information in there that
> >isn't currently exposed? I think it would be nice if people could
> >completely forget about the existence of that file, and instead have
> >nice programmatic APIs to query properties they are interested in.
> 
> In principle I agree that the parsing of pyconfig.h and Makefile are
> implementation details that shouldn't matter.  I'm working on the bug to
> pre-parse these at build time and generate a _sysconfig module that sysconfig
> would import.

I don't think you can pre-parse these at build time, since a Python
executable doesn't exist. You must adopt the reverse approach: pass all
necessary variables on the command-line (e.g. through -DCFLAGS switches)
when compiling the _sysconfig module, from the Makefile.

(I'm assuming that _sysconfig will have to be built-in rather than
dynamically loadable, since it exposes information which is critical for
building dynamic modules :-))

r84925

Sorry for being out of touch.  I’m fine with the new feature here and now; we still have the deprecation process if we want to make both get_config_h_filename and get_makefile_filename private later (as implementation details), or we could have them return None for other VMs.  We’ll see when we split the stdlib into its own repo or when we get feedback from other VMs.

Will backport to distutils2 shortly and close again.

Committed in distutils2/_backport/sysconfig.py as [4ef3e9e41c10].  I’ll push this week-end.

I noticed in the output of pydoc that get_makefile_filename does not have a docstring.  I added one in my local copy (“Return the path of the Makefile.”) and also removed “s” in verbs in other docstrings to comply with PEP 257.  Shall I commit it?

On Nov 21, 2010, at 11:02 PM, Éric Araujo wrote:

>I noticed in the output of pydoc that get_makefile_filename does not have a
>docstring.  I added one in my local copy (“Return the path of the Makefile.”)
>and also removed “s” in verbs in other docstrings to comply with PEP 257.
>Shall I commit it?

Please do.  Thanks.

Thanks, done as r86662 and [fbcddbb92b14].