classification
Title: Expose sysconfig._get_makefile_filename() in public API
Type: Stage: resolved
Components: Distutils2, Library (Lib) Versions: Python 3.2, 3rd party
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: eric.araujo Nosy List: barry, benjamin.peterson, eric.araujo, pitrou
Priority: normal Keywords: easy, patch

Created on 2010-09-16 17:50 by barry, last changed 2010-11-22 01:43 by eric.araujo. This issue is now closed.

Files
File name Uploaded Description Edit
9877.diff barry, 2010-09-16 19:05
docs.diff barry, 2010-09-16 19:34 doc update and NEWS entry
docstrings.diff eric.araujo, 2010-11-21 23:02
Messages (18)
msg116583 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2010-09-16 17:50
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().
msg116591 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2010-09-16 18:15
-1 The Makefile is very implementation specific to CPython.
msg116592 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2010-09-16 18:18
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
msg116594 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2010-09-16 19:05
Yes, it's unfortunate that that is exposed. Hopefully, sysconfig will evolve some way to find information independent of implementation.
msg116595 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2010-09-16 19:10
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.
msg116596 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2010-09-16 19:10
Patch attached.
msg116604 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-09-16 20:27
> 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.
msg116610 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2010-09-16 20:40
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.
msg116768 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-09-18 12:23
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.
msg116929 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2010-09-20 12:10
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.
msg116930 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-09-20 12:21
> >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 :-))
msg116951 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2010-09-20 15:30
r84925
msg116989 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-09-20 22:09
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.
msg117012 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-09-21 00:40
Will backport to distutils2 shortly and close again.
msg119351 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-10-21 23:13
Committed in distutils2/_backport/sysconfig.py as [4ef3e9e41c10].  I’ll push this week-end.
msg122014 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-11-21 23:02
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?
msg122054 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2010-11-22 01:17
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.
msg122058 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-11-22 01:43
Thanks, done as r86662 and [fbcddbb92b14].
History
Date User Action Args
2010-11-22 01:43:10eric.araujosetmessages: + msg122058
2010-11-22 01:17:17barrysetmessages: + msg122054
2010-11-21 23:02:00eric.araujosetfiles: + docstrings.diff

messages: + msg122014
2010-10-21 23:13:05eric.araujosetstatus: pending -> closed
versions: + 3rd party
nosy: barry, pitrou, benjamin.peterson, eric.araujo
messages: + msg119351

components: + Distutils2
2010-09-21 00:40:32eric.araujosetstatus: closed -> pending
assignee: barry -> eric.araujo
messages: + msg117012
2010-09-20 22:09:26eric.araujosetmessages: + msg116989
stage: patch review -> resolved
2010-09-20 15:30:16barrysetstatus: open -> closed
resolution: fixed
messages: + msg116951
2010-09-20 12:21:13pitrousetmessages: + msg116930
2010-09-20 12:10:05barrysetmessages: + msg116929
2010-09-18 12:23:34pitrousetnosy: + pitrou
messages: + msg116768
2010-09-17 15:06:35barrysetstage: patch review
2010-09-16 20:40:53barrysetmessages: + msg116610
2010-09-16 20:27:15eric.araujosetnosy: + eric.araujo
messages: + msg116604
2010-09-16 19:34:13barrysetfiles: + docs.diff
2010-09-16 19:10:48barrysetmessages: + msg116596
2010-09-16 19:10:30barrysetmessages: + msg116595
2010-09-16 19:05:40barrysetfiles: + 9877.diff
keywords: + patch
2010-09-16 19:05:10benjamin.petersonsetmessages: + msg116594
2010-09-16 18:18:26barrysetmessages: + msg116592
2010-09-16 18:15:04benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg116591
2010-09-16 17:50:58barrycreate