RE: [Distutils] Binaries for Windows (Header installation)
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.
"Moore, Paul" wrote:
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.
True.
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?
The right way to do this is by writing up a PEP and submitting it for approval. I would certainly vote for moving to site-packages on Windows too, since it makes support easier (same setup on Windows and Unix). I'm not sure how the situation is on other platforms such as Mac or OpenVMS... but that's what PEPs are for :)
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?
If there's demand I would add that option to the download page as well -- fortunately, distutils makes creating additional shipping formats easy.
The package repository proposal may make this happen, by distributing the job of building binary distributions. I don't know...
ActiveState is pushing for their new PPM format and will also setup a repository to make installing Python binaries easier. Don't know when this will acutally happen, though. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
participants (2)
-
M.-A. Lemburg -
Moore, Paul