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/ : ---------------------------------------------------------