Re: [GRASS-dev] PYTHONPATH question
Thanks for the series of explanations. It sounds like there is no perfect solution, but that #!/usr/bin/env python will be most likely to work on most systems. For my own system, I might add a PYTHONPATH line to my .profile that references both 'system' and 'macpython' site-packages. This might help in other circumstances. Michael On Jul 29, 2008, at 8:37 PM, Glynn Clements wrote: William Kyngesburye wrote: Given that the two versions are almost identical (2.5.1 vs 2.5.2), I suggest setting PYTHONPATH to contain both modules' site-packages directories, and nothing else. Or make sure the correct python is running. They are similar versions, but compiled differently - one (2.5.1) for OSX Leopard, the other (2.5.2) for Tiger and also-works-on- Leopard. The Mac Python list would have a better idea if this a workable solution, or crazy. Right. Python code isn't likely to care about the specific version, but binary extensions might. Michael Barton wrote: The important thing is that additional libraries like wxpython and matplotlib get installed for the default version, whatever that is. We want to make sure that a script is running the same python that you get when you type "python" from the command line. If you *want* to run it through a different python, you should just be able to use: [path to desired python] myscript.py. So what is the best way to make sure that the 'default' python is used in a script? If by "default", you mean "first in $PATH", then use the /usr/bin/env trick. Of course, there's no guarantee that $PATH will be the same in all contexts. E.g. if you modify PATH in ~/.bash_profile, you may get a different result when running a script from a terminal compared to running the same script from a GUI application. If you want to guarantee consistency above all else, use #!/usr/bin/python in the script. But then we would need to process such scripts during installation (e.g. MSys doesn't have /usr/bin/python, and it doesn't have symlinks so you can't just make /usr/bin/python a symlink to the actual program). -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
William Kyngesburye wrote: > > Given that the two versions are almost identical (2.5.1 vs 2.5.2), I > > suggest setting PYTHONPATH to contain both modules' site-packages > > directories, and nothing else. > > Or make sure the correct python is running. > > They are similar versions, but compiled differently - one (2.5.1) > for OSX Leopard, the other (2.5.2) for Tiger and also-works-on- > Leopard. The Mac Python list would have a better idea if this a > workable solution, or crazy. Right. Python code isn't likely to care about the specific version, but binary extensions might. Michael Barton wrote: > The important thing is that additional libraries like wxpython and > matplotlib get installed for the default version, whatever that is. We > want to make sure that a script is running the same python that you > get when you type "python" from the command line. If you *want* to run > it through a different python, you should just be able to use: [path > to desired python] myscript.py. > > So what is the best way to make sure that the 'default' python is used > in a script? If by "default", you mean "first in $PATH", then use the /usr/bin/env trick. Of course, there's no guarantee that $PATH will be the same in all contexts. E.g. if you modify PATH in ~/.bash_profile, you may get a different result when running a script from a terminal compared to running the same script from a GUI application. If you want to guarantee consistency above all else, use #!/usr/bin/python in the script. But then we would need to process such scripts during installation (e.g. MSys doesn't have /usr/bin/python, and it doesn't have symlinks so you can't just make /usr/bin/python a symlink to the actual program). -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
Michael Barton wrote: > >> So it IS the shebang at the top. > > > > Is "python" an alias? In the shell, type "alias python" and > > "type python". > > anthgradpc7:~ cmbarton$ alias python > -bash: alias: python: not found > anthgradpc7:~ cmbarton$ type python > python is hashed > (/Library/Frameworks/Python.framework/Versions/Current/bin/python) So that will be the first one in the path (although it may be referenced through a symlink). As for the "hashed" part, bash maintains a hashtable of name to pathname mappings, so that it doesn't have to scan $PATH each time. It discards the mapping if PATH is modified, although you can use "hash -r" to manually discard the hashtable. The only time that the hashing is likely to make itself visibile is if you add an existing program to a directory which appears earlier in $PATH. In that situation, bash will continue to use the hashed location even after the same name has appeared in an earlier directory. > >> So what to do to make this work? > >> > >> #!/usr/bin/env python > >> > >> This works on my Mac. Does it work for others? > > > > The use of /usr/bin/env is a hack to make it look for "python" in > > $PATH. The #! syntax requires an absolute path, but there's no telling > > where python will be installled (Python isn't part of POSIX, so you > > can't rely up on it being installed in /usr/bin). > > > > The actual purpose of env is to run commands with a modified > > environment. The reason it's being used here (without any environment > > changes) is just because it allows the program to run to be specified > > as a name rather than a full path, and because /usr/bin/env will > > always be available. > > So is this OK? If so, we should put this in the WIKI. Is there a > better alternative, since we don't know where python is going to be > installed? The /usr/bin/env trick seems to be quite widely used, and there doesn't appear to be any other way to make a python script which looks for python in the path. OTOH, for your particular system, it's probably a good idea to make /usr/bin/python refer to whichever version has the most-populated site-packages directory, as that's the most useful version. -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
Michael Barton wrote: > Anyway, it looks like the shebang should be #!/usr/bin/env python > unless that is a problem on a non-Mac system. What about Windows? For MSys, "#!/usr/bin/env python" is fine. Natively, Windows doesn't understand #! syntax, so you would need to either: 1. Add a .py suffix and add .py to PATHEXT. 2. Create a .bat wrapper (as is currently done for shell scripts). 3. Explicitly invoke the script via python. -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
The important thing is that additional libraries like wxpython and matplotlib get installed for the default version, whatever that is. We want to make sure that a script is running the same python that you get when you type "python" from the command line. If you *want* to run it through a different python, you should just be able to use: [path to desired python] myscript.py. So what is the best way to make sure that the 'default' python is used in a script? Michael __ C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262; fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton On Jul 29, 2008, at 2:59 PM, William Kyngesburye wrote: On Jul 29, 2008, at 3:30 PM, Glynn Clements wrote: Michael Barton wrote: See below... William has already identified the core problem: scripts are using a different version of Python to the interactive interpreter, and presumably only one of the two versions has matplotlib installed. If you set PYTHONPATH, all interpreters will find modules in those directories (it will even override system modules, so don't put the system directories in PYTHONPATH, only site-packages). If PYTHONPATH is unset, each version will use its own site-packages directory. Given that the two versions are almost identical (2.5.1 vs 2.5.2), I suggest setting PYTHONPATH to contain both modules' site-packages directories, and nothing else. Or make sure the correct python is running. They are similar versions, but compiled differently - one (2.5.1) for OSX Leopard, the other (2.5.2) for Tiger and also-works-on- Leopard. The Mac Python list would have a better idea if this a workable solution, or crazy. - William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 29, 2008, at 3:30 PM, Glynn Clements wrote: Michael Barton wrote: See below... William has already identified the core problem: scripts are using a different version of Python to the interactive interpreter, and presumably only one of the two versions has matplotlib installed. If you set PYTHONPATH, all interpreters will find modules in those directories (it will even override system modules, so don't put the system directories in PYTHONPATH, only site-packages). If PYTHONPATH is unset, each version will use its own site-packages directory. Given that the two versions are almost identical (2.5.1 vs 2.5.2), I suggest setting PYTHONPATH to contain both modules' site-packages directories, and nothing else. Or make sure the correct python is running. They are similar versions, but compiled differently - one (2.5.1) for OSX Leopard, the other (2.5.2) for Tiger and also-works-on-Leopard. The Mac Python list would have a better idea if this a workable solution, or crazy. - William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
Michael Barton wrote: > See below... William has already identified the core problem: scripts are using a different version of Python to the interactive interpreter, and presumably only one of the two versions has matplotlib installed. If you set PYTHONPATH, all interpreters will find modules in those directories (it will even override system modules, so don't put the system directories in PYTHONPATH, only site-packages). If PYTHONPATH is unset, each version will use its own site-packages directory. Given that the two versions are almost identical (2.5.1 vs 2.5.2), I suggest setting PYTHONPATH to contain both modules' site-packages directories, and nothing else. -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
voice: 480-965-6262; fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton On Jul 29, 2008, at 1:03 PM, Glynn Clements wrote: So it IS the shebang at the top. Is "python" an alias? In the shell, type "alias python" and "type python". anthgradpc7:~ cmbarton$ alias python -bash: alias: python: not found anthgradpc7:~ cmbarton$ type python python is hashed (/Library/Frameworks/Python.framework/Versions/ Current/bin/python) So what to do to make this work? #!/usr/bin/env python This works on my Mac. Does it work for others? The use of /usr/bin/env is a hack to make it look for "python" in $PATH. The #! syntax requires an absolute path, but there's no telling where python will be installled (Python isn't part of POSIX, so you can't rely up on it being installed in /usr/bin). The actual purpose of env is to run commands with a modified environment. The reason it's being used here (without any environment changes) is just because it allows the program to run to be specified as a name rather than a full path, and because /usr/bin/env will always be available. So is this OK? If so, we should put this in the WIKI. Is there a better alternative, since we don't know where python is going to be installed? Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
Michael Barton wrote: > > It looks like, when run from a python script in GRASS, you're > > getting the system python. > > > > Yet, when you run python itself from GRASS, you get the python.org > > Python. What is the shebang line (first line) in your python > > script, it may be pointing to the system python? > > > > > > On Jul 27, 2008, at 7:40 PM, Michael Barton wrote: > > > >>> Is "python" the actual executable, or is it a front-end script? > >> > >> /usr/bin/python and /usr/local/bin/python are symlinks to /Library/ > >> Frameworks/.../python2.5, which is an executable. I've checked and > >> this is the only "python" in my path > > > > /usr/bin/python should be a symlink to the SYSTEM python. > > > Weird. When I do 'show original' for /usr/bin/python, it shows as a > symlink to > > /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python > > ...which is a symlink to /System/Library/Frameworks/Python.framework/ > Versions/2.5/bin/python2.5 > > BUT, if I start it... > > cmb-MBP-2:~ cmbarton$ python > Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) > [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> > cmb-MBP-2:~ cmbarton$ /usr/bin/python > Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) > [GCC 4.0.1 (Apple Inc. build 5465)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> ^D > cmb-MBP-2:~ cmbarton$ /usr/bin/python2.5 > Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) > [GCC 4.0.1 (Apple Inc. build 5465)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> > cmb-MBP-2:~ cmbarton$ /usr/local/bin/python > Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) > [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> > > So it IS the shebang at the top. Is "python" an alias? In the shell, type "alias python" and "type python". > So what to do to make this work? > > #!/usr/bin/env python > > This works on my Mac. Does it work for others? The use of /usr/bin/env is a hack to make it look for "python" in $PATH. The #! syntax requires an absolute path, but there's no telling where python will be installled (Python isn't part of POSIX, so you can't rely up on it being installed in /usr/bin). The actual purpose of env is to run commands with a modified environment. The reason it's being used here (without any environment changes) is just because it allows the program to run to be specified as a name rather than a full path, and because /usr/bin/env will always be available. -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 29, 2008, at 11:03 AM, William Kyngesburye wrote: On Jul 29, 2008, at 12:42 PM, Michael Barton wrote: Looking more closely, one is in... /Library/Frameworks/Python.framework/Versions/2.5/bin/python and the other is in... /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python Is one of these a System Python, or has MacPython shifted where it installs? Michael I thought that would be obvious: /System/Library/... is the system python. The MacPython packagers would have been out of their minds to install in there. You never know... Anyway, it looks like the shebang should be #!/usr/bin/env python unless that is a problem on a non-Mac system. What about Windows? Michael Technically, they're both "MacPython", or just plain "Python" since the MacPython packaging became the official distribution. But it's still helpful to say "system python" and "MacPython" (or as I say, "python.org python") to distinguish between the two. Apple builds the standard [Mac]Python, just in the system location (and a few tweaks, like site-packages in /Library/Python). - William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 29, 2008, at 12:42 PM, Michael Barton wrote: Looking more closely, one is in... /Library/Frameworks/Python.framework/Versions/2.5/bin/python and the other is in... /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python Is one of these a System Python, or has MacPython shifted where it installs? Michael I thought that would be obvious: /System/Library/... is the system python. The MacPython packagers would have been out of their minds to install in there. Technically, they're both "MacPython", or just plain "Python" since the MacPython packaging became the official distribution. But it's still helpful to say "system python" and "MacPython" (or as I say, "python.org python") to distinguish between the two. Apple builds the standard [Mac]Python, just in the system location (and a few tweaks, like site-packages in /Library/Python). - William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 29, 2008, at 10:34 AM, William Kyngesburye wrote: On Jul 29, 2008, at 12:15 PM, Michael Barton wrote: cmb-MBP-2:~ cmbarton$ ls -l /usr/bin/python lrwxr-xr-x 1 root wheel 72 May 9 15:32 /usr/bin/python -> ../../ System/Library/Frameworks/Python.framework/Versions/2.5/bin/python cmb-MBP-2:~ cmbarton$ ls -l /usr/local/bin/python lrwxr-xr-x 1 root wheel 68 May 9 23:07 /usr/local/bin/python - > ../../../Library/Frameworks/Python.framework/Versions/2.5/bin/ python cmb-MBP-2:~ cmbarton$ They're each pointing to the right python. Looking more closely, one is in... /Library/Frameworks/Python.framework/Versions/2.5/bin/python and the other is in... /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python Is one of these a System Python, or has MacPython shifted where it installs? Michael #!/usr/bin/env python No. The was just me questioning if I should use that format. So, it should work, and run Mac Python. Or did you not have that there before, and *now* it's working? - William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 29, 2008, at 11:59 AM, Michael Barton wrote: On Jul 29, 2008, at 9:54 AM, Michael Barton wrote: Weird. When I do 'show original' for /usr/bin/python, it shows as a symlink to /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python ...which is a symlink to /System/Library/Frameworks/ Python.framework/Versions/2.5/bin/python2.5 Note that when I do a 'show original' for both symlinks /usr/bin/ python and /usr/local/bin/python, they both go to the same place: /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python But one calls the System 2.5.1 and the other one calls the MacPython 2.5.2 Michael By "show original", do you mean right-click->show original in the Finder? What about: ls -l /usr/bin/python ls -l /usr/local/bin/python - William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 29, 2008, at 12:15 PM, Michael Barton wrote: cmb-MBP-2:~ cmbarton$ ls -l /usr/bin/python lrwxr-xr-x 1 root wheel 72 May 9 15:32 /usr/bin/python -> ../../ System/Library/Frameworks/Python.framework/Versions/2.5/bin/python cmb-MBP-2:~ cmbarton$ ls -l /usr/local/bin/python lrwxr-xr-x 1 root wheel 68 May 9 23:07 /usr/local/bin/python - > ../../../Library/Frameworks/Python.framework/Versions/2.5/bin/python cmb-MBP-2:~ cmbarton$ They're each pointing to the right python. #!/usr/bin/env python No. The was just me questioning if I should use that format. So, it should work, and run Mac Python. Or did you not have that there before, and *now* it's working? - William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 29, 2008, at 10:16 AM, William Kyngesburye wrote: On Jul 29, 2008, at 11:54 AM, Michael Barton wrote: So it IS the shebang at the top. So what to do to make this work? #!/usr/bin/env python This works on my Mac. Does it work for others? Are those literally in the shebang? I don't know the finer details of env, but that doesn't look right. Try removing them: #!/usr/bin/env python No. The was just me questioning if I should use that format. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 29, 2008, at 11:54 AM, Michael Barton wrote: So it IS the shebang at the top. So what to do to make this work? #!/usr/bin/env python This works on my Mac. Does it work for others? Are those literally in the shebang? I don't know the finer details of env, but that doesn't look right. Try removing them: #!/usr/bin/env python - William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 29, 2008, at 10:10 AM, William Kyngesburye wrote: On Jul 29, 2008, at 11:59 AM, Michael Barton wrote: On Jul 29, 2008, at 9:54 AM, Michael Barton wrote: Weird. When I do 'show original' for /usr/bin/python, it shows as a symlink to /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python ...which is a symlink to /System/Library/Frameworks/ Python.framework/Versions/2.5/bin/python2.5 Note that when I do a 'show original' for both symlinks /usr/bin/ python and /usr/local/bin/python, they both go to the same place: /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python But one calls the System 2.5.1 and the other one calls the MacPython 2.5.2 Michael By "show original", do you mean right-click->show original in the Finder? Yup What about: ls -l /usr/bin/python ls -l /usr/local/bin/python cmb-MBP-2:~ cmbarton$ ls -l /usr/bin/python lrwxr-xr-x 1 root wheel 72 May 9 15:32 /usr/bin/python -> ../../ System/Library/Frameworks/Python.framework/Versions/2.5/bin/python cmb-MBP-2:~ cmbarton$ ls -l /usr/local/bin/python lrwxr-xr-x 1 root wheel 68 May 9 23:07 /usr/local/bin/python - > ../../../Library/Frameworks/Python.framework/Versions/2.5/bin/python cmb-MBP-2:~ cmbarton$ - William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 29, 2008, at 9:54 AM, Michael Barton wrote: On Jul 29, 2008, at 9:37 AM, William Kyngesburye wrote: [coming out of lurking on this one] It looks like, when run from a python script in GRASS, you're getting the system python. Yet, when you run python itself from GRASS, you get the python.org Python. What is the shebang line (first line) in your python script, it may be pointing to the system python? On Jul 27, 2008, at 7:40 PM, Michael Barton wrote: Is "python" the actual executable, or is it a front-end script? /usr/bin/python and /usr/local/bin/python are symlinks to /Library/ Frameworks/.../python2.5, which is an executable. I've checked and this is the only "python" in my path /usr/bin/python should be a symlink to the SYSTEM python. Weird. When I do 'show original' for /usr/bin/python, it shows as a symlink to /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python ...which is a symlink to /System/Library/Frameworks/Python.framework/ Versions/2.5/bin/python2.5 Note that when I do a 'show original' for both symlinks /usr/bin/ python and /usr/local/bin/python, they both go to the same place: /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python But one calls the System 2.5.1 and the other one calls the MacPython 2.5.2 Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 29, 2008, at 9:37 AM, William Kyngesburye wrote: [coming out of lurking on this one] It looks like, when run from a python script in GRASS, you're getting the system python. Yet, when you run python itself from GRASS, you get the python.org Python. What is the shebang line (first line) in your python script, it may be pointing to the system python? On Jul 27, 2008, at 7:40 PM, Michael Barton wrote: Is "python" the actual executable, or is it a front-end script? /usr/bin/python and /usr/local/bin/python are symlinks to /Library/ Frameworks/.../python2.5, which is an executable. I've checked and this is the only "python" in my path /usr/bin/python should be a symlink to the SYSTEM python. Weird. When I do 'show original' for /usr/bin/python, it shows as a symlink to /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python ...which is a symlink to /System/Library/Frameworks/Python.framework/ Versions/2.5/bin/python2.5 BUT, if I start it... cmb-MBP-2:~ cmbarton$ python Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> cmb-MBP-2:~ cmbarton$ /usr/bin/python Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> ^D cmb-MBP-2:~ cmbarton$ /usr/bin/python2.5 Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> cmb-MBP-2:~ cmbarton$ /usr/local/bin/python Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> So it IS the shebang at the top. So what to do to make this work? #!/usr/bin/env python This works on my Mac. Does it work for others? Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 29, 2008, at 11:22 AM, Michael Barton wrote: GRASS 7.0.svn (Spearfish60_test):~ > histogram_mpldemo.py * sys.argv *** /Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts/ histogram_mpldemo.py * sys.path *** /Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts /Library/Python/2.5/site-packages/GDAL-1.5.2-py2.5-macosx-10.5- i386.egg /Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python /Users/cmbarton /usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5/site-packages /usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5/site-packages/ wx-2.8-mac-unicode /System/Library/Frameworks/Python.framework/Versions/2.5/lib/ python25.zip /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5 /System/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/plat-darwin /System/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/plat-mac /System/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/plat-mac/lib-scriptpackages /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/ python /System/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/lib-tk /System/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/lib-dynload /Library/Python/2.5/site-packages /usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5 /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/ python/PyObjC Traceback (most recent call last): File "/Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts/ histogram_mpldemo.py", line 104, in import matplotlib ImportError: No module named matplotlib GRASS 7.0.svn (Spearfish60_test):~ > [coming out of lurking on this one] It looks like, when run from a python script in GRASS, you're getting the system python. Yet, when you run python itself from GRASS, you get the python.org Python. What is the shebang line (first line) in your python script, it may be pointing to the system python? On Jul 27, 2008, at 7:40 PM, Michael Barton wrote: Is "python" the actual executable, or is it a front-end script? /usr/bin/python and /usr/local/bin/python are symlinks to /Library/ Frameworks/.../python2.5, which is an executable. I've checked and this is the only "python" in my path /usr/bin/python should be a symlink to the SYSTEM python. - William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
Glynn, See below... On Jul 29, 2008, at 6:36 AM, Glynn Clements wrote: Michael Barton wrote: AFAICT, everything works without $PYTHONPATH in all cases EXCEPT in a script running under the GRASS parser. So what changes before and after g.parser? In the scripts which I have seen so far, the imports are at the top level, so they will be executed on both occasions. I can't think of any reason why an import would fail when the script is run initially but then work when the script is re-invoked from g.parser. Can you add commands to print sys.argv and sys.path (and, if you can import "os", os.environ) to the top of the script, and see what is changing before and after g.parser. I'm not sure I understand. The structure is a 'standard GRASS script' for Python. ## #!/usr/bin/python At this point, put: import sys print sys.argv print sys.path import os print os.environ GRASS 7.0.svn (Spearfish60_test):~ > histogram_mpldemo.py * sys.argv *** /Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts/ histogram_mpldemo.py * sys.path *** /Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts /Library/Python/2.5/site-packages/GDAL-1.5.2-py2.5-macosx-10.5-i386.egg /Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python /Users/cmbarton /usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5/site-packages /usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5/site-packages/ wx-2.8-mac-unicode /System/Library/Frameworks/Python.framework/Versions/2.5/lib/ python25.zip /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5 /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ plat-darwin /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ plat-mac /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ plat-mac/lib-scriptpackages /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/ python /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ lib-tk /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ lib-dynload /Library/Python/2.5/site-packages /usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5 /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/ python/PyObjC * os.environ *** _ HISTFILE GRASS_FONT GRASS_HTML_BROWSER TERM_PROGRAM_VERSION CVS_RSH GRASS_SH USER HOME PATH GRASS_GNUPLOT DISPLAY TERM_PROGRAM LANG GRASS_ADDON_PATH TERM Apple_PubSub_Socket_Render INFOPATH SHLVL SECURITYSESSIONID GRASS_PAGER HISTSIZE EDITOR MANPATH GISBASE CVSROOT TK_LIBRARY GRASS_PERL PYTHONPATH SSH_AUTH_SOCK GRASS_HTML_BROWSER_MACOSX TCL_LIBRARY DYLD_LIBRARY_PATH PWD SHELL GRASS_XTERM GRASS_ADDON_ETC GRASS_OS_STARTUP TMPDIR PERL5LIB GRASS_LD_LIBRARY_PATH GRASS_PROJSHARE GRASS_PYTHON __CF_USER_TEXT_ENCODING GRASS_WISH GISRC GRASS_TCLSH GRASS_VERSION GRASS_FONT_CAP LOGNAME GIS_LOCK COMMAND_MODE Traceback (most recent call last): File "/Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts/ histogram_mpldemo.py", line 104, in import matplotlib ImportError: No module named matplotlib GRASS 7.0.svn (Spearfish60_test):~ > . This works fine if I type the following on at the GRASS command prompt before executing PYTHONPATH="/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages"$PYTHONPATH There ought to be a colon between the literal and $PYTHONPATH. Typo in the email. It is usually there. Unless it's started with the -S switch, the Python interpreter performs an automatic "import site". This module adds the site-packages directory to sys.path; it also adds each subdirectory which is named in one fo the site-packages/*.pth files. http://docs.python.org/lib/module-site.html It shoudn't be necessary for PYTHONPATH to be set unless you need to use modules which aren't installed in Python's lib directory. Are any of the other PYTHON* environment variables set? If $PYTHONSTARTUP is set, that could cause an interactive interpreter to behave differently from a script. Not that I've set anywhere. $PYTHONSTARTUP is not set. You could try starting python with and without the -S flag, printing sys.path in each case. It's possible that there's some oddity in your setup that is causing site.py to misbehave. with -S does not have any site-packages; without -S has site-packages. See below. GRASS 7.0.svn (Spearfish60_test):~ > python Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print '\n'.join(sys.path) /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- packages/Dabo-0.8.3-py2.5.egg /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- packages/setuptools-0.6c8-py2.5.egg /Library/Frameworks/Python.framework/Version
Re: [GRASS-dev] PYTHONPATH question
Michael Barton wrote: > >> AFAICT, everything works without $PYTHONPATH in all cases EXCEPT in > >> a script running under the GRASS parser. > > > > So what changes before and after g.parser? > > > > In the scripts which I have seen so far, the imports are at the top > > level, so they will be executed on both occasions. I can't think of > > any reason why an import would fail when the script is run initially > > but then work when the script is re-invoked from g.parser. > > > > Can you add commands to print sys.argv and sys.path (and, if you can > > import "os", os.environ) to the top of the script, and see what is > > changing before and after g.parser. > > I'm not sure I understand. The structure is a 'standard GRASS script' > for Python. > > ## > > #!/usr/bin/python At this point, put: import sys print sys.argv print sys.path import os print os.environ When you run the script, you should get two lots of output, one from before g.parser, one from when the script is re-invoked. Unless g.parser is never being invoked in the first place. > This works fine if I type the following on at the GRASS command prompt > before executing > > PYTHONPATH="/Library/Frameworks/Python.framework/Versions/2.5/lib/ > python2.5/site-packages"$PYTHONPATH There ought to be a colon between the literal and $PYTHONPATH. > I thought I'd show you how setting PYTHONPATH in Init.sh was causing > the trouble, but discovered something that seems a bit odd. I tried > unsetting PYTHONPATH and got the same results as before. > > GRASS 7.0.svn (Spearfish60_test):~ > $PYTHONPATH > bash: /Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python:: No > such file or directory To print a variable, use "echo", e.g. "echo $PYTHONPATH". If you just type "$PYTHONPATH", the shell will try to execute its value as a command. > GRASS 7.0.svn (Spearfish60_test):~ > export PYTHONPATH="" > GRASS 7.0.svn (Spearfish60_test):~ > $PYTHONPATH > GRASS 7.0.svn (Spearfish60_test):~ > > GRASS 7.0.svn (Spearfish60_test):~ > histogram_mpldemo.py > Traceback (most recent call last): >File "/Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts/ > histogram_mpldemo.py", line 93, in > import matplotlib > ImportError: No module named matplotlib > > > If I start Python from the GRASS command prompt, sys.path is as before > and $PYTHONPATH is unset. So what is setting the search path for > Python modules now? Unless it's started with the -S switch, the Python interpreter performs an automatic "import site". This module adds the site-packages directory to sys.path; it also adds each subdirectory which is named in one fo the site-packages/*.pth files. http://docs.python.org/lib/module-site.html It shoudn't be necessary for PYTHONPATH to be set unless you need to use modules which aren't installed in Python's lib directory. Are any of the other PYTHON* environment variables set? If $PYTHONSTARTUP is set, that could cause an interactive interpreter to behave differently from a script. You could try starting python with and without the -S flag, printing sys.path in each case. It's possible that there's some oddity in your setup that is causing site.py to misbehave. -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 28, 2008, at 5:44 AM, Glynn Clements wrote: Michael Barton wrote: Is there any pattern to which modules will import and which won't? All the paths in sys.path are valid. That isn't what I asked. Which modules will import, and which won't? Presumably "sys" imports (that's built into Python)? What about "os"? Is it just the modules in site-packages, or the "system" modules as well? System modules import fine. It's just site-packages modules AFAICT, everything works without $PYTHONPATH in all cases EXCEPT in a script running under the GRASS parser. So what changes before and after g.parser? In the scripts which I have seen so far, the imports are at the top level, so they will be executed on both occasions. I can't think of any reason why an import would fail when the script is run initially but then work when the script is re-invoked from g.parser. Can you add commands to print sys.argv and sys.path (and, if you can import "os", os.environ) to the top of the script, and see what is changing before and after g.parser. I'm not sure I understand. The structure is a 'standard GRASS script' for Python. ## #!/usr/bin/python GRASS doc area GUI description area most import statements (this is where it stops with an import from site-packages; the 'system' modules import fine) def Main(): (i.e., the first procedure called by the parser line) other procedures if __name__ == "__main__": options, flags = grass.parser() main() ## This works fine if I type the following on at the GRASS command prompt before executing PYTHONPATH="/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages"$PYTHONPATH I thought I'd show you how setting PYTHONPATH in Init.sh was causing the trouble, but discovered something that seems a bit odd. I tried unsetting PYTHONPATH and got the same results as before. GRASS 7.0.svn (Spearfish60_test):~ > $PYTHONPATH bash: /Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python:: No such file or directory GRASS 7.0.svn (Spearfish60_test):~ > export PYTHONPATH="" GRASS 7.0.svn (Spearfish60_test):~ > $PYTHONPATH GRASS 7.0.svn (Spearfish60_test):~ > GRASS 7.0.svn (Spearfish60_test):~ > histogram_mpldemo.py Traceback (most recent call last): File "/Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts/ histogram_mpldemo.py", line 93, in import matplotlib ImportError: No module named matplotlib If I start Python from the GRASS command prompt, sys.path is as before and $PYTHONPATH is unset. So what is setting the search path for Python modules now? Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
Michael Barton wrote: > > Is there any pattern to which modules will import and which won't? > > All the paths in sys.path are valid. That isn't what I asked. Which modules will import, and which won't? Presumably "sys" imports (that's built into Python)? What about "os"? Is it just the modules in site-packages, or the "system" modules as well? > AFAICT, everything works without $PYTHONPATH in all cases EXCEPT in > a script running under the GRASS parser. So what changes before and after g.parser? In the scripts which I have seen so far, the imports are at the top level, so they will be executed on both occasions. I can't think of any reason why an import would fail when the script is run initially but then work when the script is re-invoked from g.parser. Can you add commands to print sys.argv and sys.path (and, if you can import "os", os.environ) to the top of the script, and see what is changing before and after g.parser. -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 27, 2008, at 6:53 PM, Glynn Clements wrote: Is there any pattern to which modules will import and which won't? All the paths in sys.path are valid. AFAICT, everything works without $PYTHONPATH in all cases EXCEPT in a script running under the GRASS parser. Michael I notice that matplotlib is a .egg file. I don't have any of these on my system (I do have a bunch of .egg-info files, which are just plain text), probably because Gentoo builds everything from source. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
Michael Barton wrote: > I suggest completely unsetting PYTHONPATH, and seeing what problems > >>> (if any) that causes. > >> > >> Interesting. This was something the Mac Python installation puts in, > >> though I can tell it not to do so. If I unset this, Python works fine > >> from a terminal and importing in the Python interpreter works fine > >> too. > >> > >> BUT, there are problems in GRASS because Init.sh now sets $PYTHONPATH > >> to $GISBASE/etc. This is fine for grass.py, but it causes problems > >> accessing anything else in site-packages. Here is the result of > >> running one of the MatPlotLib demo scripts. > >> > >> GRASS 7.0.svn (Spearfish60_test):~ > histogram_mpldemo.py > >> Traceback (most recent call last): > >> File "/Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts/ > >> histogram_mpldemo.py", line 94, in > >> import matplotlib > >> ImportError: No module named matplotlib > >> > >> It's looking for matplotlib in $GISBASE/etc now. > > > > Any directories in PYTHONPATH should be in addition to the Python > > system directories, not instead of them. > > > > What do you get from: > > > > import sys > > print '\n'.join(sys.path) > > ? > > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/Dabo-0.8.3-py2.5.egg > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/ipython-0.8.4-py2.5.egg > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy-1.1.0-py2.5-macosx-10.3-i386.egg > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib-0.98.1-py2.5-macosx-10.3.egg > /Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages > /usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5/site-packages > /usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5/site-packages/wx-2.8-mac-unicode > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload > /usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5 > /Library/Frameworks/Python.framework/Versions/2.5/lib/python25.zip > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5 > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-darwin > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac/lib-scriptpackages > /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk Is this for a configuration which works, or which doesn't work? I note that GRASS' etc/python directory is there. > > I'm wondering whether python is being invoked with the -S switch, > > which suppresses the automatic "import site" (which causes > > site-packages to be added to sys.path, along with any subdirectories > > referenced by any site-packages/*.pth files). > > I don't think so. It works fine when just calling the python > interpreter from the shell. I think the issue is now just down to the > fact that Init.sh creates a $PYTHONPATH that has $GISBASE/etc/python. > Once this is created, the python side of g.parser only looks for > modules to import in $PYTHONPATH. If I just invoke python from the > GRASS shell to start the interpreter, there is no problem importing > matplotlib or anything else. It's only having parsing import > matplotlib when it's in a script. This is an improvement over previous > complications. I really appreciate your help. Is there any pattern to which modules will import and which won't? I notice that matplotlib is a .egg file. I don't have any of these on my system (I do have a bunch of .egg-info files, which are just plain text), probably because Gentoo builds everything from source. -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 27, 2008, at 5:19 PM, Glynn Clements wrote: Michael Barton wrote: I suggest completely unsetting PYTHONPATH, and seeing what problems (if any) that causes. Interesting. This was something the Mac Python installation puts in, though I can tell it not to do so. If I unset this, Python works fine from a terminal and importing in the Python interpreter works fine too. BUT, there are problems in GRASS because Init.sh now sets $PYTHONPATH to $GISBASE/etc. This is fine for grass.py, but it causes problems accessing anything else in site-packages. Here is the result of running one of the MatPlotLib demo scripts. GRASS 7.0.svn (Spearfish60_test):~ > histogram_mpldemo.py Traceback (most recent call last): File "/Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts/ histogram_mpldemo.py", line 94, in import matplotlib ImportError: No module named matplotlib It's looking for matplotlib in $GISBASE/etc now. Any directories in PYTHONPATH should be in addition to the Python system directories, not instead of them. What do you get from: import sys print '\n'.join(sys.path) ? /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- packages/setuptools-0.6c8-py2.5.egg /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- packages/Dabo-0.8.3-py2.5.egg /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- packages/setuptools-0.6c8-py2.5.egg /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- packages/ipython-0.8.4-py2.5.egg /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- packages/numpy-1.1.0-py2.5-macosx-10.3-i386.egg /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- packages/matplotlib-0.98.1-py2.5-macosx-10.3.egg /Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- packages /usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5/site-packages /usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5/site-packages/ wx-2.8-mac-unicode /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib- dynload /usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5 /Library/Frameworks/Python.framework/Versions/2.5/lib/python25.zip /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5 /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat- darwin /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat- mac/lib-scriptpackages /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk When you say that you can tell the Mac Python installer not to set PYTHONPATH, do you know if does something else instead? No. It simply has an option (default, but can turn off) to modify .profile. Is "python" the actual executable, or is it a front-end script? /usr/bin/python and /usr/local/bin/python are symlinks to /Library/ Frameworks/.../python2.5, which is an executable. I've checked and this is the only "python" in my path I'm wondering whether python is being invoked with the -S switch, which suppresses the automatic "import site" (which causes site-packages to be added to sys.path, along with any subdirectories referenced by any site-packages/*.pth files). I don't think so. It works fine when just calling the python interpreter from the shell. I think the issue is now just down to the fact that Init.sh creates a $PYTHONPATH that has $GISBASE/etc/python. Once this is created, the python side of g.parser only looks for modules to import in $PYTHONPATH. If I just invoke python from the GRASS shell to start the interpreter, there is no problem importing matplotlib or anything else. It's only having parsing import matplotlib when it's in a script. This is an improvement over previous complications. I really appreciate your help. Michael -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
Michael Barton wrote:
> >> Any idea why the following PYTHONPATH in my .profile works fine for
> >> GRASS finding packages like MatPlotLib and a version with the site-
> >> packages entry last does not?
> >>
> >> PYTHONPATH="/Library/Frameworks/Python.framework/Versions/2.5/lib/
> >> python2.5/site-packages:/Library/Frameworks/Python.framework/
> >> Versions/
> >> 2.5/lib/python25.zip:/Library/Frameworks/Python.framework/Versions/
> >> 2.5/
> >> lib/python2.5:/Library/Frameworks/Python.framework/Versions/2.5/lib/
> >> python2.5/plat-darwin:/Library/Frameworks/Python.framework/Versions/
> >> 2.5/lib/python2.5/plat-mac:/Library/Frameworks/Python.framework/
> >> Versions/2.5/lib/python2.5/plat-mac/lib-scriptpackages:/Library/
> >> Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk:/
> >> Library/
> >> Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-
> >> dynload:"$PYTHONPATH
> >
> > Why do you have all of your Python system directories in PYTHONPATH?
> > Those should already be in sys.path.
> >
> > FWIW, on Gentoo, the only directory which is added to PYTHONPATH by
> > the OS configuration is /usr/lib/portage/pym ("portage" is Gentoo's
> > package manager, and it's written mainly in Python).
> >
> > I suggest completely unsetting PYTHONPATH, and seeing what problems
> > (if any) that causes.
>
> Interesting. This was something the Mac Python installation puts in,
> though I can tell it not to do so. If I unset this, Python works fine
> from a terminal and importing in the Python interpreter works fine too.
>
> BUT, there are problems in GRASS because Init.sh now sets $PYTHONPATH
> to $GISBASE/etc. This is fine for grass.py, but it causes problems
> accessing anything else in site-packages. Here is the result of
> running one of the MatPlotLib demo scripts.
>
> GRASS 7.0.svn (Spearfish60_test):~ > histogram_mpldemo.py
> Traceback (most recent call last):
>File "/Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts/
> histogram_mpldemo.py", line 94, in
> import matplotlib
> ImportError: No module named matplotlib
>
> It's looking for matplotlib in $GISBASE/etc now.
Any directories in PYTHONPATH should be in addition to the Python
system directories, not instead of them.
What do you get from:
import sys
print '\n'.join(sys.path)
?
When you say that you can tell the Mac Python installer not to set
PYTHONPATH, do you know if does something else instead?
Is "python" the actual executable, or is it a front-end script?
I'm wondering whether python is being invoked with the -S switch,
which suppresses the automatic "import site" (which causes
site-packages to be added to sys.path, along with any subdirectories
referenced by any site-packages/*.pth files).
--
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
On Jul 27, 2008, at 4:01 PM, Glynn Clements wrote:
Michael Barton wrote:
Any idea why the following PYTHONPATH in my .profile works fine for
GRASS finding packages like MatPlotLib and a version with the site-
packages entry last does not?
PYTHONPATH="/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/site-packages:/Library/Frameworks/Python.framework/
Versions/
2.5/lib/python25.zip:/Library/Frameworks/Python.framework/Versions/
2.5/
lib/python2.5:/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/plat-darwin:/Library/Frameworks/Python.framework/Versions/
2.5/lib/python2.5/plat-mac:/Library/Frameworks/Python.framework/
Versions/2.5/lib/python2.5/plat-mac/lib-scriptpackages:/Library/
Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk:/
Library/
Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-
dynload:"$PYTHONPATH
Why do you have all of your Python system directories in PYTHONPATH?
Those should already be in sys.path.
FWIW, on Gentoo, the only directory which is added to PYTHONPATH by
the OS configuration is /usr/lib/portage/pym ("portage" is Gentoo's
package manager, and it's written mainly in Python).
I suggest completely unsetting PYTHONPATH, and seeing what problems
(if any) that causes.
Interesting. This was something the Mac Python installation puts in,
though I can tell it not to do so. If I unset this, Python works fine
from a terminal and importing in the Python interpreter works fine too.
BUT, there are problems in GRASS because Init.sh now sets $PYTHONPATH
to $GISBASE/etc. This is fine for grass.py, but it causes problems
accessing anything else in site-packages. Here is the result of
running one of the MatPlotLib demo scripts.
GRASS 7.0.svn (Spearfish60_test):~ > histogram_mpldemo.py
Traceback (most recent call last):
File "/Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts/
histogram_mpldemo.py", line 94, in
import matplotlib
ImportError: No module named matplotlib
It's looking for matplotlib in $GISBASE/etc now.
Michael
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PYTHONPATH question
Michael Barton wrote:
> Any idea why the following PYTHONPATH in my .profile works fine for
> GRASS finding packages like MatPlotLib and a version with the site-
> packages entry last does not?
>
> PYTHONPATH="/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/site-packages:/Library/Frameworks/Python.framework/Versions/
> 2.5/lib/python25.zip:/Library/Frameworks/Python.framework/Versions/2.5/
> lib/python2.5:/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/plat-darwin:/Library/Frameworks/Python.framework/Versions/
> 2.5/lib/python2.5/plat-mac:/Library/Frameworks/Python.framework/
> Versions/2.5/lib/python2.5/plat-mac/lib-scriptpackages:/Library/
> Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk:/Library/
> Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-
> dynload:"$PYTHONPATH
Why do you have all of your Python system directories in PYTHONPATH?
Those should already be in sys.path.
FWIW, on Gentoo, the only directory which is added to PYTHONPATH by
the OS configuration is /usr/lib/portage/pym ("portage" is Gentoo's
package manager, and it's written mainly in Python).
I suggest completely unsetting PYTHONPATH, and seeing what problems
(if any) that causes.
> I had to modify this from the one that the Mac Python installation
> sets to put site-packages first. The Python interpreter has no problem
> with the path either way. Does something in the grass Python parser
> stop reading this path if it hits non-existent directories?
No.
--
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
