I have a Win7 system with other python installations that reside on C:/ which also contain wxpython and there are windows environmental variables for those folders (path & pythonpath).
Now when I start KiCAD and open a pcb an error comes up that tells me that:
Anybody knows a workaround for this?
This happens in R5798 and R6097.
If I try to open the scripting console KiCAD just crashes.
I have other machines without the python heritage of this particular system and I don’t get this error there, the scripting console loads just fine. I naturally don’t want to screw up my python installation by making KiCAD work as I need the setup as it is… already installed the latest wxpython to my python environment, but no success.
Is there anything I can do to the environment variables that would help?
Or put some sort of script into the KiCAD folder to tell it to look somewhere else instead of using the ‘global’ environment variables?
Thanks!
That is odd. I have an existing C:\Python27 installation also but since the KiCad Python is constructing its own environment (dependent entirely on stuff inside c:\Program Files\KiCad) there is no conflict like you are having. See my thread: PCBNEW: Using Python scripting under Windows
How are you installing your KiCad?
I installed my KiCad using the kicad-product-r6086.a6c94e2-x86_64.exe installer. Perhaps if you are using the i686 version, you can try the x86_64 version? What happens if you run c:\Program Files\KiCad\bin\python.exe and inspect the environment from the resulting interactive interpreter?
It definitely seems to me that the paths and environments for KiCad on Windows are in flux at the moment.
Just looked at the installed program overview and there is python 2.6 and 2.7 in there… some libraries, 2 WingIDE installations and 2 wxpython installations 2.8.11 and 3.0.2 and 2 panda3D installs - probably not going to help my case.
Might need to clean that up…
I installed with the ***-x86_64.exe. But just over each other… I think I started with that 2013-stable thing a year back until I found the more recent versions and now that repo with the latest ‘product’ versions compiled for windows.
The interactive interpreter tell’s me this:
C:\Program Files\KiCad\lib\python2.7>python.exe
Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32
Type “help”, “copyright”, “credits” or “license” for more information.
import sys
sys.path
[’’, ‘C:\Python27’, ‘C:\Python27\DLLs’, ‘C:\Python27\lib’, ‘C:\Python27\lib\plat-win’, ‘C:\Python27\lib\lib-tk’, ‘C:\Python27\lib\site-packages’, ‘C:\Python27\lib\site-packages\PIL’, ‘C:\Python27\lib\site-packages\win32’, ‘C:\Python27\lib\site-packages\win32\lib’, ‘C:\Python27\lib\site-packages\Pythonwin’, ‘E:\Data_Code\Python’, ‘C:\Panda3D-1.8.0\python\python27.zip’, ‘C:\Panda3D-1.8.0\python\DLLs’, ‘C:\Panda3D-1.8.0\python\lib’, ‘C:\Panda3D-1.8.0\python\lib\plat-win’, ‘C:\Panda3D-1.8.0\python\lib\lib-tk’, ‘C:\Panda3D-1.8.0\python’, ‘C:\Panda3D-1.8.0’, ‘C:\Panda3D-1.8.0\bin’, ‘C:\Panda3D-1.8.0\python\lib\site-packages’]
This means it’s actually picking up those global path’s huh?
The way you ran ‘python.exe’ is not what I meant. You are still running the python.exe that is in your c:\Python27 which will pickup its environment from the prompt that you are using. You need to run specifically:
c:\Program Files\KiCad\bin\python.exe
Notice that it is only 19kB. This is actually just a wrapper that is going to run the python interpreter that is embedded in the pcbnew executable and its associated DLLs.
Hm, OK, sorry… the output changed slightly… panda3D is gone and replaced by a lot of KiCAD folders… but the first in line are still the ones from the global variable it seems?
Python 2.7.10 (default, Jul 8 2015, 15:10:39)
[GCC 5.1.0] on win32
Type “help”, “copyright”, “credits” or “license” for more information.
import sys
sys.path
[’’, ‘C:\Python27’, ‘C:\Python27\DLLs’, ‘C:\Python27\lib’, ‘C:\Python27\lib\plat-win’, ‘C:\Python27\lib\lib-tk’, ‘C:\Python27\lib\site-packages’, ‘C:\Python27\lib\site-packages\PIL’, ‘C:\Python27\lib\site-packages\win32’, ‘C:\Python27\lib\site-packages\win32\lib’, ‘C:\Python27\lib\site-packages\Pythonwin’, E:\Data_Code\Python’, ‘C:\Program Files\KiCad\lib\python27.zip’, ‘C:\Program Files\KiCad\lib\python2.7’, ‘C:\Program Files\KiCad\lib\python2.7\plat-win32’, ‘C:\Program Files\KiCad\lib\python2.7\lib-tk’, ‘C:\Program Files\KiCad\lib\python2.7\lib-old’, ‘C:\Program Files\KiCad\lib\python2.7\lib-dynload’, ‘C:\building\msys32\mingw64’, ‘C:\Program Files\KiCad’]
That looks more like it but yes still odd, at least we are seeing the actual path that your KiCad python is trying to use. It is definitely messed up though, because the KiCad paths are being appended after your global paths which is wrong because a path search will hit your global paths first (i.e. they are getting precedence).
Two questions come to mind:
(1) Do you have the following files in your KiCad installation?
AFAIK, they are what is setting up a proper python load path.
(2) I’ve always done a complete uninstall of previous KiCad versions before installing a new version. Perhaps you have old python files mixed in with your recent installation?
Both questions can be answered with yes - those files exists in those directories.
Just checked the site.py file and it seems to work with sys.path… it’s not ignoring what is in there, it checks for doublets what I can read in the commentaries. But this sort of coding is a bit over my head, would take me a while to find the point where exactly the global path is loaded or where I could throw a spanner in (not that it would be useful, as I don’t have a clue how to get this into a .pyc and don’t have all of it explode in my face… sad
I’ll have to investigate if my setup of PATH & PYTHONPATH actually is legit and supposed to work like that. I mean, for the install I got there should be similar procedures for getting a sys.path together and it seems to be working somewhat as there are additional panda3d folders in there, that aren’t in the one I created in windows.
Just can’t remember for what and why I did that…
Hmm. I’m at a loss then. One thing I can tell you is that I have no PYTHONPATH defined on my computer. I’ve always tried to avoid using it and opted for more task-specific ways to set the module load path.
You could try temporarily renaming your PYTHONPATH variable and (from a completely new prompt) startup the KiCad Python again to see if sys.path has changed.
I just re-read https://docs.python.org/2/using/windows.html and I must have done this years back as I’m usually starting scripts all over the place and there might had been some trouble without those variables and the first thing that worked stayed in place I guess.
I’m in the middle of some work and can’t reboot, otherwise I’d had cleaned those global variables for a test and looked what happens then when I do my usual stuff and how KiCAD behaves then, but alas this has to wait for another day. I’ll try not to forget this and post an update in due course.
Had time to look into this… PYTHONPATH is indeed responsible for this behavior. I removed it for the time being, rebooted and now KiCAD starts without this error.
Hopefully, by the time I need it to make something else work I remember this
