I've been trying to install Python2.0 on my Darwin box. I have not had much success.
The main issue seems to be that my filesystem is case insensitive (HFS+), and python's build sequence wants to do something like "mv Python/python ./python". One can get around some of this by editing the top level makefile to set the variable EXE to .exe:
EXE= .exe
But even then, the binary that is built is named "python" and you have to move and rename it manually. Setting --program-suffix=exe when running configure had no discernible effect at all.
Anyway, it also seems that the binary is not able to import modules correctly once installed (it works fine from within the build directory). This is obviously a very bad problem. (Setting PYTHONHOME got rid of some error messages, but still would not allow the importing of modules).
Anyway, a lot of these errors seem to result from the case insensitive file system, because I had much better behavior on my UFS Mac OS X system.
Has anyone had better luck with Python 2.0? It would be great to make this part of the distro. Unfortunately, I don't think it could be in any case as Python 2.0's licence is incompatible with the GPL according to RMS.
--
Lagos
mp98@cornell.edu
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I configure with:
./configure --with-dyld --with-suffix=.app --host=Darwin --includedir=/System/Library/Frameworks/System.framework/Headers
Which seems to work pretty well and correctly makes python.app. With this configuration, the problems seem solved. Except that test_re still fails. So it goes. Sorry, I'm tired right now and not entirely lucid.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good! We have a version in ftp. I'm fairly sure that it works ok, but I have done much better recently. Still, you might want to have a look at it. It shows how this problem is solved.
1. configure as per usual.
2. mv Python Python.dir
3. edit the Makefiles to reflect this change.
4 build it.
Step 3 is the tough one, because you have to read the Makefiles to see whether they are refering to python or Python.dir. At step 4, the newly built python should compile all the *.py files. And there is some site dependent information that must be deposited in the Python directories. That last, is a little hard to detect, but if you get that far, you have a good Python installation.
I think that we have uncovered one basic bit of poor programming practice on the part of the Python developers, although I am extremely impressed with the package otherwise. Yes, I realize that there is still a fundamental shortcoming in the MacOS file system, but developer's should take this possibility into account. We should submit a change to the Python team.
You may also run into a similar problem with some of the Perl::Net modules, and a related problem with packages using non-english character sets.
So far, despite this one problem, Python seems to be very good. Based on my experience with the ports, Guile appears to be best of class to me, with Python a close second, then Perl and Ruby.
I think that I would use Perl, if I had to fetch massive amounts of info, as in a data mining operation or some such.
Regards,
proclus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been trying to install Python2.0 on my Darwin box. I have not had much success.
The main issue seems to be that my filesystem is case insensitive (HFS+), and python's build sequence wants to do something like "mv Python/python ./python". One can get around some of this by editing the top level makefile to set the variable EXE to .exe:
EXE= .exe
But even then, the binary that is built is named "python" and you have to move and rename it manually. Setting --program-suffix=exe when running configure had no discernible effect at all.
Anyway, it also seems that the binary is not able to import modules correctly once installed (it works fine from within the build directory). This is obviously a very bad problem. (Setting PYTHONHOME got rid of some error messages, but still would not allow the importing of modules).
Anyway, a lot of these errors seem to result from the case insensitive file system, because I had much better behavior on my UFS Mac OS X system.
Has anyone had better luck with Python 2.0? It would be great to make this part of the distro. Unfortunately, I don't think it could be in any case as Python 2.0's licence is incompatible with the GPL according to RMS.
--
Lagos
mp98@cornell.edu
Some clarification:
I configure with:
./configure --with-dyld --with-suffix=.app --host=Darwin --includedir=/System/Library/Frameworks/System.framework/Headers
Which seems to work pretty well and correctly makes python.app. With this configuration, the problems seem solved. Except that test_re still fails. So it goes. Sorry, I'm tired right now and not entirely lucid.
Good! We have a version in ftp. I'm fairly sure that it works ok, but I have done much better recently. Still, you might want to have a look at it. It shows how this problem is solved.
1. configure as per usual.
2. mv Python Python.dir
3. edit the Makefiles to reflect this change.
4 build it.
Step 3 is the tough one, because you have to read the Makefiles to see whether they are refering to python or Python.dir. At step 4, the newly built python should compile all the *.py files. And there is some site dependent information that must be deposited in the Python directories. That last, is a little hard to detect, but if you get that far, you have a good Python installation.
I think that we have uncovered one basic bit of poor programming practice on the part of the Python developers, although I am extremely impressed with the package otherwise. Yes, I realize that there is still a fundamental shortcoming in the MacOS file system, but developer's should take this possibility into account. We should submit a change to the Python team.
You may also run into a similar problem with some of the Perl::Net modules, and a related problem with packages using non-english character sets.
So far, despite this one problem, Python seems to be very good. Based on my experience with the ports, Guile appears to be best of class to me, with Python a close second, then Perl and Ruby.
I think that I would use Perl, if I had to fetch massive amounts of info, as in a data mining operation or some such.
Regards,
proclus