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