Folks,
Just getting started using OGR and Python for a variety of geospatial tasks. I'm working outside of OSGEO4w, and have installed GDAL w/ Python Bindings as well as Python v. 2.7.8 on my machine.
That said, I can run python and import gdal from a command-line interface but am unable to import the module when I use the IDLE environment. It returns an error telling me that the module doesn't exist. My install must be sound given that it works in the cmd prompt, so what's the deal?
This is all new to me, I'd appreciate any help or advice ya'll can impart; all previous questions I've read were concerned w/ merely installing (which I've done successfully) and getting Python to recognize the module from the command prompt, which it does.
Cheers,
Mike
Mike,
You can open IDLE with your python installation from the cmd line through:
>>>from idlelib import PyShell
>>>PyShell.main()
This should open IDLE from your current python, and you should be able then to import gdal and ogr from there.
Alternatively, you should have a windows batch file here
C:\YOURPYTHONPATH\Lib\idlelib\idle.bat
Running this should achieve the same.
Martin
Consider creating the following batch where PyInst references the Python installation folder from which IDLE is launched (i.e. idle.bat) and QgisInst references the folder containing "bin\o4w_env.bat":
#echo off
set PyInst=C:\Python27
set QgisInst="C:\Program Files\QGIS Brighton"
call %QgisInst%\bin\o4w_env.bat
set PYTHONPATH=%PyInst%\DLLs;%PyInst%\Lib;%PyInst%\Lib\lib-tk
set TCL_LIBRARY=%PyInst%\tcl\tcl8.5
python %PyInst%\Lib\idlelib\idle.pyw
Related
I am attempting to run pyDEA. The main_gui approach does not work from wha appears to be the
ValueError: cannot use LOCALE flag with a str pattern
issue with the latest version of Python (I am running Python 3.8.5, Anaconda on MacOS).
Has anyone run it directly in a script? If so, do they have any sample code to show what they needed to import and call to run the DEA analysis?
I am using the VS code interactive window and using some python packages that make use of other programs. In the interactive window I am e.g. getting error messages like:
OSError: No command "mcflirt" found on host login2.nan.kcl.ac.uk. Please check that the corresponding package is installed.
If I was just running this from the command line I would simply ensure that I loaded the package which contains 'mcflirt' into the shell before starting the python interpreter and the interpreter would then be able to find it. Is anyone aware of how to tell the interactive window to load the package (e.g. loading the mcflirt containing package by module load fsl)before starting the python interpreter?
One way to access system modules is to use the python 'init' file e.g.:
sys.path.insert(0,'/software/system/modules/4.5.1/init')
import python as mod
mod.module('unload', 'fsl')
mod.module('load', 'fsl/6.0.4')
mod.module('load', 'ants/2.3.5')
I want to delete a given virtual machine installed on VirtualBox (itself installed on Windows XP). When I run the command from CMD the deletion rus as I expect. But when I run this code:
import subprocess
myVM="windowsxp_1"
status = subprocess.call(["VBoxManage", "unregistervm", myVM, "--delete"])
The deletion is performed. However, unlike in the first case, the name of the VM is still listed on the VirtualBox interface. Why and how can I resolve this problem ?
Here are 2 pictures explaining what I said:
Deletection is successful:
But the name of the VM is still listed on the VirtualBox:The result is the same when I use :
import os
os.system("VBoxManage unregistervm vmNameToDelete --delete")
I can't reproduce this problem using Python run from the command line. It appears your IDE may be affecting things. Try running your Python script from the command line to see it works there.
I'm not sure why running the script under your IDE that would cause it not to work. Maybe you've got two versions of VirtualBox installed on your machine and your IDE is using a different PATH and ends up using a different VBoxManage.
I am using Python 3.3 (2.7 is also installed) and a compatible version of pygame. Recently I have been trying to switch from IDLE to Notepad++
I am using a saved shortcut in Notepad++
C:\Python33\python.bat "$(CURRENT_DIRECTORY)" "$(FILE_NAME)"
which runs the batch file:
#echo off
cd %1
%2
if not errorlevel 1 goto quit
echo.
echo.
pause
:quit
When I run C:\Python33\Foldername\imp_prob.py
import pygame
in IDLE it works fine, in Notepad++ using that shortcut it gives an ImportError: No module named pygame
My questions are:
Why is the NP++ method not producing the same result?
How can I change the shortcut or batch file to make it run stuff that IDLE can run?
What method can I use to ensure that I can import a module regardless of which directory I am running the program from?
edit: a working alternative was in the answers to How do you run a python script from within notepad++?
I had some issues with the code they provided, but replacing "python" with the full path to my python33 install solved that.
I still don't understand why pygame wouldn't import when using my run shortcut. I also don't understand why NppExec works when Run doesn't.
It sounds like you would need to set your systemvariables. Idle does not require these steps. You entered the full path to the python.exe in np++ to execute the python program, but the path to the modules etc. is still unknown.
Add the paths, and try again.
System Properties -> Advanced -> Environment Variables, in the bottom window look for a "Path" variable, Edit and append the following the existing entries (do not delete anything in there!)
;C:\Python33;C:\Python33\DLLs;C:\Python33\Lib
for Python 3.3, if you have installed it into its default directory.
To see if everything worked, open the console anywhere (shift+rightclick -> Open Command Window Here) and just type "python". The python console should open, telling you that you use python 3.3. You then also do not need to tell np++ the full python path, but instead can just use "python" again.
although I have been using python a long time very easily in a Linux environment, I have tremendous trouble to even install it correctly in a windows environment. I hope this is a question to be asked here, as it is not directly a programming question.
Especially, I have the following problems:
When on the command line, python is not a recognized command. Do I have to set the Windows path manually myself? If so, how to do that?
When starting a python script, should this be done with python.exe or pythonw.exe? What is the difference?
I also tried to install ipython several times, it never got installed (even after following the starting ipythonenter link description here thread.
When starting a script with python.exe, a window pops up and closes immediately. I saw some hints in putting in a readline command, which is of no help if there is a syntax error in the script. So how to be able to keep the window open, or how to run the command on the cmd.exe?
Thank you for any help on these items.
Alex
1) Look here: www.computerhope.com/issues/ch000549.htm
2) It has already been answered, always try to use search before asking question:
pythonw.exe or python.exe?
4) When using cmd.exe just navigate to your script folder using dir for changing directories and C:,D:,etc. for changing drives. Then run script by typing just the script name. When installed correctly, Python automatically launches .py scripts with python, so you don't have to write 'python' before script name. When run in cmd, window will stay open. If you want it to stay open even when launching script with double-click, use function waiting for user input, see here How to keep a Python script output window open?
You might want to use Python3.3, there is a new launcher for Python scripts in it. By that, you can start Python scripts with py <scriptname> which has the benefit of being installed in your path (C:\Windows\system32) and you can use a shebang to tell whether the script is for Python2 or Python3.
Also
In addition to the launcher, the Windows installer now includes an
option to add the newly installed Python to the system PATH
(contributed by Brian Curtin in issue 3561).