[Distutils] Access to Python config info

[M.-A. Lemburg]

Greg Ward wrote:
> 
> On the superficial front, Marc-Andre hasn't convinced me that sysconfig
> is a better name than sys.config.  (On the other hand, I never said
> whether I thought it should be a sub-module of sys, or a [potentially
> ambiguous] module under a package called 'sys'.)

Gee, naming issues again... anything with a dot in it reminds
me of packages and thus should act like one (submodules are
really not a good idea: they contain code that is executed but
not necessarily needed by the one who imports the main module).
Yet, the sys module is written in C and all the distutils stuff
should, IMHO, be done in Python.

So the reasons I renamed it from sys.config to sysconfig were simply:
· don't make it look like a package when it is not
· don't have 'import sys' fill unneeded dictionaries
· just naming it 'config' would probably cause name clashes

Alternative name: 'pyconfig'

> > Rather than discuss which things to include or not, just
> > put all the information in there you can find by simply parsing
> > Makefile. Note that the parsing mechanism should also allow
> > for fairly decent $(VARIABLE) expansion.
> 
> No!  At least not in the long term: as Greg Stein pointed out, the
> config module (whatever it gets called) should just be generated when
> Python is built.  Or were you talking about the near term, where we will
> need a distutils release that works with Python 1.5.2 and is allowed all
> manner of grotesque hackery to work around the lack of a config module,
> such as digging up and parsing Python's config.h, Makefile, and Setup?

I wouldn't consider this grotesque hackery. The idea I had
was to have the sysconfig module initialize itself at import
time (rather than install time). Since it is not often needed
this should be a feasable approach. Most of all it works
without any changes to the distribution as it is, except maybe...

> > But the install dirs are changeable during configure... we might
> > need some help from Guido here, e.g. the sys module could
> > include the information: sys.configdir, sys.incldir and sys.libdir.
> 
> Now you're cluttering 'sys' up with stuff in the yet-to-be-named config
> module. 
>
> These directories should just be accessible variables in
> sys.config, eg.
> 
>    sys.config.install_bindir
>    sys.config.install_scriptdir
>    sys.config.install_libdir

They are... once the module is initialized. But for it to find the
necessary templates (Setup, config.h and Makefile) it needs some
path information first. Looking at the current Makefile.pre.in
though, it seems that this doesn't directly support non-standard install
directories either.

The parsed information could then be stored in a _sysconfig module
which subsequent invocations then use which is close to what Greg
proposed except that the first run is not necessarily done by the
installation Makefile.

> Greg Stein pointed out:
> > Actually, at the discussion, we planned on compiling them right into the
> > interpreter. That would prevent version skews between a compiled Python
> > and the libraries.
> >
> > However, now that I'm thinking about it... screw that. If "import
> > sysconfig" picks up the wrong version, then you have plenty of other
> > issues to deal with. I'd much rather see a .py file that a bunch of
> > stuff compiled into the interpreter.
> 
> I'm torn on this one.  Building into Python prevents version skew,
> keeping it separate means it's easily readable without writing code.
> Both are compelling arguments.  Greg has given one voice in favour of a
> separate .py file... anyone else?

The current system has the same problems: Makefile.pre.in looks
in the install dirs at boot time. If it finds wrong information
then the resulting Makefile will use bogus data.

Some people have reported effects of this: strange core dumps
and unresolved symbols, even bus errors. Most of them had the
install dirs mounted via NFS containing data for other machines
than the one they built the extensions on.

> Are there other sources of information we should be
> worrying about?  (Eg. does config.cache have anything valuable that
> doesn't wind up in config.h or Makefile?)

I think the three files pretty much cover all information that
is available to Python at compile time (except maybe the os.environ
at compile time).

-- 
Marc-Andre Lemburg                               Y2000: 380 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------