Cygwin Python sys.platform and distutils.util.get_platform() patch
I would like to submit the attached patch (i.e., the first attachment) to Python CVS for inclusion in 2.2. IMO, this is the right solution for many reasons. I have included one example as the the second attachment. If the patch is accepted, then I will back patch and re-release my Cygwin Python 2.1 distribution. Since these two simple changes have possibly far reaching ramifications, I thought that it would be prudent to solicit feedback before submitting the patch. My goal is to eliminate (or at least minimize) the heartache caused by these changes, if any. Note that the two parts of the patch are actually independent but related so I have decided to submit them as one patch instead of two. The first part changes sys.platform, sys.path, and the platform specific module directory name as follows: $ # before patch $ python -c 'import sys; print sys.platform' cygwin_nt-4.01 $ python -c 'import sys; print sys.path' [..., '/usr/lib/python2.1/plat-cygwin_nt-4.01', ...] $ find /usr/lib/python2.1 -name '*cygwin*' -type d /usr/lib/python2.1/plat-cygwin_nt-4.01 $ # after patch $ python -c 'import sys; print sys.platform' cygwin $ python -c 'import sys; print sys.path' [..., '/usr/lib/python2.1/plat-cygwin', ...] $ find /usr/lib/python2.1 -name '*cygwin*' -type d /usr/lib/python2.1/plat-cygwin The second part changes sys.path (only when Python is run out of the build tree) and the directory names used by distutils when building extension modules: $ # before patch $ python -c 'import sys; print sys.path' [..., '/home/jt/src/Python-2.1/build/lib.cygwin_nt-4.0-1.3.2-i686-2.1'] $ find . -name '*cygwin*' ./build/lib.cygwin_nt-4.0-1.3.0-i686-2.1 ./build/temp.cygwin_nt-4.0-1.3.0-i686-2.1 $ # after patch $ python -c 'import sys; print sys.path' [..., '/home/jt/src/Python-2.1/build/lib.cygwin-1.3.2-i686-2.1'] $ find . -name '*cygwin*' ./build/lib.cygwin-1.3.2-i686-2.2 ./build/temp.cygwin-1.3.2-i686-2.2 If I don't receive any negative responses to this patch proposal by 2001/6/1 9:00 EDT, then I will submit this patch to the SourceForge Python Patch Manager. Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: 732.264.8770 x235 Dot Hill Systems Corp. Fax: 732.264.8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
I did something silly the other day in with PyXML, and ended up motivated to post a bugreport on the result. The developers kicked that back with the observation that it's a distutils issue. Sad to say, I've been on this list for a while but too busy to pay any real attention, these are probably old and thoroughly hashed-out issues, but I thought I'd toss this out here for comment before doing anything else with it: ==================== This is the result of operator error, but nonetheless... I accidentally launched an install of PyXML on a w2k system where it was already installed. I know the instructions say to remove old installations first (actually it wasn't an "old" installation, it was the same version, to be really nitpicky) as I said, Operator Error. However, at this point: (a) the existing installation is not detected with a bailout option ("blah blah already installed blah blah do you want to continue?") (b) there's no way to abort the installation once it starts (no cancel button) (c) you are prompted for EACH file as to whether to replace or not; there is no "yes to all" (or "no to all") so one would potentially have to click "yes" or "no" hundreds of times to complete for something like PyXML. ================== A little further comment: I ended up doing the NT/2000 equivalent of ps and kill: I brought up the task manager and blew the whole thing away. Needless to say, I don't think this is ideal or I wouldn't have gone to the effort of grumbling about it. ================== Here was the response to the report: The windows installer is created using the distutils bdist_wininst command. That means that we cannot easily change the user interface of the installation procedure. Please report this as a distutils bug in the Python project. ================== Any comments? Mats
Sorry for the late reply, but I've been very busy...
This is the result of operator error, but nonetheless... I accidentally launched an install of PyXML on a w2k system where it was already installed. I know the instructions say to remove old installations first (actually it wasn't an "old" installation, it was the same version, to be really nitpicky) as I said, Operator Error. However, at this point:
(a) the existing installation is not detected with a bailout option ("blah blah already installed blah blah do you want to continue?") This should probably wait until there is a distutils registry of installed modules.
(b) there's no way to abort the installation once it starts (no cancel button)
I've hesitated to add this because an installation cancelled in the middle of file-copying would certainly leave the system in a not very useful state.
(c) you are prompted for EACH file as to whether to replace or not; there is no "yes to all" (or "no to all") so one would potentially have to click "yes" or "no" hundreds of times to complete for something like PyXML. You could press the 'N' or 'Y' button and leave it pressed, so this would not take forever ;-) Seriously: I should add this. My excuse: The yes/no to all is asked once just before the start of the installation.
Thomas
Thanks for the comments!
(a) the existing installation is not detected with a bailout option ("blah blah already installed blah blah do you want to continue?") This should probably wait until there is a distutils registry of installed modules.
Is this in the works?
(c) you are prompted for EACH file as to whether to replace or not; there is no "yes to all" (or "no to all") so one would potentially have to click "yes" or "no" hundreds of times to complete for something like PyXML. Seriously: I should add this. My excuse: The yes/no to all is asked once just before the start of the installation.
Yes, I retried my "operator error" intentionally later just to confirm, and this time I noticed that initial box. I /think/ the problem was at that point I didn't yet know I was in trouble.... it was already a while ago so I don't remember that clearly. Mats
(a) the existing installation is not detected with a bailout option ("blah blah already installed blah blah do you want to continue?") This should probably wait until there is a distutils registry of installed modules.
Is this in the works?
No, I'm not aware of any activity. However, it's on the todo list. Here is a comment from a message 'Tasks arising from IPC9' by Andrew Kuchling, dated 3/10/2001: 3) Other Distutils changes would be to design and create a package database, and implement an uninstall command. The 'sdist' command would also grow an --upload or --register option that would automatically submit the package to the catalog (but first we'd need to finalize how that should be done). IIRC, Andrew said this would probably require a PEP. Thomas
Prior discussion has roughly been: My gripe: the fact that a package is already installed is not detected with a warning. Thomas Heller: This should probably wait until there is a distutils registry of installed modules. Me: Is this in the works? Thomas: No, I'm not aware of any activity. He goes on to say folks (well, AMK) know it's needed, and probably requires a PEP. Should we get that ball rolling? In the most general terms, it appears that PEP 241 formally, plus just "how distutils works", describes one of the software collection types we're interested in: the distribution (although PEP 241 itself appears to describe only one component of the distribution, the metadata, or what other terminology calls a "Software Definition File"). The other type we need, to implement things like removal, show installed packages, detection of previous install of same or different version, track dependencies (gack...no... not RPM!!!), etc., is an "installed software" collection. I'd propose that's an appropriate subject for a PEP. I don't have any idea how much or how little of this is considered "necessary" (as opposed to "might be nice"). (I can volunteer to carry the ball if necessary, but I'm sure I'm nowhere near the best qualified person). Mats
I thought the major point of supporting the creation of "native" binary packages was so that installation and dependencoes could be handled however the local architecure handles it. Doing "python setup.py install" is no different that "./configure && make install". Neither one is going to look to see if anything's already there. "python setup.py bdist_whatever", however will create a nice, neat little package. With the full implementation of PEP241 standards, (esp. standard names and versions) the package manager will know if a package is already installed, and _it_ will do appropriate warnings, allow for "forcing", deal with multiple version installs, ... , all the things that package managers do. If all this stuff is packed into distutils, then administrators will have to look in multiple places to figure out what is installed on which machine. I see distutils as a distribution tool, not an administration tool. Like it or not, different platforms come with different administration tools, and no matter how good open general-purpose replacements are, they're a pain to keep in sync with the one the vendor uses. mwa On Fri, 8 Jun 2001, Mats Wichmann wrote:
Prior discussion has roughly been:
My gripe: the fact that a package is already installed is not detected with a warning.
Thomas Heller: This should probably wait until there is a distutils registry of installed modules.
Me: Is this in the works?
Thomas: No, I'm not aware of any activity.
He goes on to say folks (well, AMK) know it's needed, and probably requires a PEP.
Should we get that ball rolling? In the most general terms, it appears that PEP 241 formally, plus just "how distutils works", describes one of the software collection types we're interested in: the distribution (although PEP 241 itself appears to describe only one component of the distribution, the metadata, or what other terminology calls a "Software Definition File").
The other type we need, to implement things like removal, show installed packages, detection of previous install of same or different version, track dependencies (gack...no... not RPM!!!), etc., is an "installed software" collection.
I'd propose that's an appropriate subject for a PEP. I don't have any idea how much or how little of this is considered "necessary" (as opposed to "might be nice").
(I can volunteer to carry the ball if necessary, but I'm sure I'm nowhere near the best qualified person).
Mats
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Mark W. Alexander slash@dotnetslash.net
participants (4)
-
Jason Tishler -
Mark W. Alexander -
Mats Wichmann -
Thomas Heller