RE: [Distutils] Header installation
From: M.-A. Lemburg [mailto:mal@lemburg.com]
PS Do the installers butlt by distutils (bdist_wininst and the like) respect setup.cfg? If not, I believe they should. Or at least, the installer should include a way for the end user to specify an alternative install directory...
Hmm, the build commands do respect the settings in the setup.cfg file, but the installer itself doesn't.
It would be nice, if the wininst installer would allow even more flexibility, e.g. allow setting the install directory (this would then have to generate a .pth file to properly setup the Python path),
Not necessarily. All I care about is that I absolutely will not accept the default of putting modules in the Python executable directory. I feel that this is completely wrong, and needs change. There is a perfectly respectable Lib/site-packages directory, but Python ignores it (on Windows). The fix is a 1-line change to site.py, which I understand is not done because of some form of policy issue, rather than for any technical reason (ie, Guido doesn't like it...) I have hacked site.py to override this. I want to override the default location where modules are installed, as well. I simply will not use an installer which dumps arbitrary modules in the Python executable directory. The wininst installer is hackable, as it is basically an exe prepended onto a zip file, so I can unzip the distribution wherever I like. But I wish I didn't need to do this. OTOH, I don't want my Windows "add/remove programs" applet cluttered with loads of Python modules, either (which I believe is also something the wininst installer does). So personally, I would prefer to just have a zip which I could install myself... Two questions - is the bdist_zip option functional (no time to try it just now)? And how can we persuade package authors to provide a bdist_zip version of their packages as well as an installer version? (Sorry - I HATE installers, and particularly so when I have no way of controlling or limiting what they do...) Paul.
The wininst installer is hackable, as it is basically an exe prepended onto a zip file, so I can unzip the distribution wherever I like. But I wish I didn't need to do this. OTOH, I don't want my Windows "add/remove programs" applet cluttered with loads of Python modules, either (which I believe is also something the wininst installer does). Only in the newest version (1.0.2pre, as in python2.1b2) the module is added to the add/remove programs list. Of course I could include a flag into the installer to let the user decide whether to record deinstall information, but normally this is not decided by the poor user. IMO most Windows installers are already asking questions where no one can provide the correct answer (You have already installed xxx.dll in anther language and in another version. Would you like it to be replaced?)
So personally, I would prefer to just have a zip which I could install myself... Since the installer is an exe prepended onto a zip file (as you noted), Winzip is happy to open and extract it as a zip file. Maybe if this fact would be documented better, it could come to rescue for the 'expert' user who has his own opinions about the install location, uninstall, and so on.
Two questions - is the bdist_zip option functional (no time to try it just now)? And how can we persuade package authors to provide a bdist_zip version of their packages as well as an installer version? Last time I checked, 'bdist --formats=zip' creates a zip-file with pathnames relative to the root directory 'python20/package/module.py' or even worse 'Program Files/python/package/module.py' or 'Programme/python/package/module.py' depending on where your python is installed.
(Sorry - I HATE installers, and particularly so when I have no way of controlling or limiting what they do...)
This is (mostly) true for any installers I know. (OK, the install location is normally changeable...) Thomas
"Moore, Paul" wrote:
It would be nice, if the wininst installer would allow even more flexibility, e.g. allow setting the install directory (this would then have to generate a .pth file to properly setup the Python path),
Not necessarily. All I care about is that I absolutely will not accept the default of putting modules in the Python executable directory. I feel that this is completely wrong, and needs change. There is a perfectly respectable Lib/site-packages directory, but Python ignores it (on Windows). The fix is a 1-line change to site.py, which I understand is not done because of some form of policy issue, rather than for any technical reason (ie, Guido doesn't like it...)
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. The problem of course is that distutils default setting will become a standard and changing the location would only cause more confusion...
I have hacked site.py to override this. I want to override the default location where modules are installed, as well. I simply will not use an installer which dumps arbitrary modules in the Python executable directory.
The wininst installer is hackable, as it is basically an exe prepended onto a zip file, so I can unzip the distribution wherever I like. But I wish I didn't need to do this. OTOH, I don't want my Windows "add/remove programs" applet cluttered with loads of Python modules, either (which I believe is also something the wininst installer does). So personally, I would prefer to just have a zip which I could install myself...
Two questions - is the bdist_zip option functional (no time to try it just now)? And how can we persuade package authors to provide a bdist_zip version of their packages as well as an installer version?
There is no such thing as bdist_zip; bdist_dumb is probably what you meant and yes, it works the way you describe.
(Sorry - I HATE installers, and particularly so when I have no way of controlling or limiting what they do...)
Paul.
-- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
participants (3)
-
M.-A. Lemburg -
Moore, Paul -
Thomas Heller