[Distutils] Access to Python config info

[Greg Ward]

OK, we seem to have a better degree of consensus on this than on that
version number thing.  Good -- hopefully we won't scare anyone off with
an extended argument.

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'.)  My rationale for
calling it sys.config is that sys is "Python system stuff"; sys.config
would basically be more of the same, but probably a *lot* more -- so I
don't think it should clutter up the well-known, well-understood 'sys'
module.  One other possible name is, of course, 'config', but then the
Perl guys might sue us for copyright infringement.  >joke!<

Marc-Andre also said:
> 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?

[Marc-Andre again]
> 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
   etc.

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?

[Greg S. again]
> I'd also recommend ignoring all the dictionary vs instance stuff. Just
> have a bunch of assignments dropped into a sysconfig.py module. IMO, it
> would look a lot like FCNTL.py (h2py output files). No need to get fancy
> with defaults and stuff. Just write the dumb file out.

I (almost) completely agree.  If we put *everything* from config.h into
the config module, it might be nice to store it separately (eg. in a
hash).  But the stuff from Makefile and Setup should just be dumped in
flat as variables.  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?)

Finally, John Skaller respond to my sketch of what should be in the
config module:
>         This is too Unixy.

Absolutely true.  I never claimed to be anything but a Unix bigot.  Two
rebuttals though:

  * if platform X supports running the compiler from a command line or 
    a script, surely that compiler can take some arguments... and surely
    some of those arguments will deal with optimization/debugging, some
    will deal with preprocessor settings, and some are just plain
    miscellaneous
  * splitting the flags up into all those categories can be useful, but
    it could be that I'm confusing the Python build process with the
    extension module build process.  Perhaps the way to build an
    extension should be carved in stone when Python itself is built, and 
    extension builders shouldn't be allowed to muck with it.  If so,
    then John is absolutely right about just calling a function to
    invoke the compiler for such-and-such a situation.

Gee, I guess that second one wasn't much of a rebuttal.  So much for my
combative spirit. ;-)

>         An excellent sketch though. Why? because it is concrete
> enough to be argued about!

Thank you! that was the whole idea; I hate abstract arguments (the only
courses I came close to flunking in university were philosophy and
psychology...).  And I have a nasty tendency to attack anyone who brings
up airy-fairy concepts with *something* concrete to explain his ideas.

        Greg
-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                      voice: +1-703-620-8990 x287
Reston, Virginia, USA  20191-5434               fax: +1-703-620-0913