From: M.-A. Lemburg [mailto:mal@lemburg.com]
I don't know why distutils installs in Python\Lib\ instead of e.g. Lib\site-packages\, but I do know that you override this option using setup.cfg, so that your particular installer installs in a different destination directory.
But that only works if you're using distutils to install. As was pointed out, the installer doesn't (currently?) respect this setting. For modules with complex dependencies (OpenGL, Numeric, wxWindows are examples) building from scratch is often not a realistic option.
The problem of course is that distutils default setting will become a standard and changing the location would only cause more confusion...
Exactly my point. Is the current distutils default the best standard? If not, we should change it NOW, before the user base is too large to even contemplate a change. If the distributed site.py doesn't support the "obvious" place (site-packages), surely now is the time to lobby for the change?
There is no such thing as bdist_zip; bdist_dumb is probably what you meant and yes, it works the way you describe.
Thanks - sorry for the confusion. Thomas said that it currently uses absolute paths rather than relative, which means it needs fixing. But assuming it is fixed, would it get used? Would you distribute the mx utils as a bdist_dumb file as well as the bdist_wininst one you currently supply? Would others? The package repository proposal may make this happen, by distributing the job of building binary distributions. I don't know... Paul.