First time here? We are a friendly community of Power Systems Engineers. Check out the FAQ!
1 | initial version |
The method proposed by JervisW requires a chuck of code to be pasted at the top of every script. This would also be a small inconvenience when we begin moving to PSSE33 and in the unlikely chance that someone had PSSE installed in a different path.
Why not use use $PYTHONPATH or put a link in the site-packages directory? Like so:
C:\Python25\Lib\site-packages
$ cat .\pti.pth
C:\Program Files\PTI\PSSE32\PSSBIN
Granted, I just finished installing PSSE, so take the answer with a grain of salt. I haven't test anything more than:
import psspy
2 | No.2 Revision |
The method proposed by JervisW requires a chuck of code to be pasted at the top of every script. This would also be a small inconvenience when we begin moving to PSSE33 and in the unlikely chance that someone had PSSE installed in a different path.
Why not use use $PYTHONPATH or put a link in
You can modify the python search path by adding a .pth file to
the site-packagesC:\Python25\Lib\site-packages
$ cat .\pti.pth
C:\Program Files\PTI\PSSE32\PSSBIN
Granted, I just finished installing PSSE, so take the answer with a grain of salt. I haven't test anything more than:And a quick check to make sure python can find the psspy module:
import python -m psspy
If python can't find the module you'll get a traceback.
To work properly, PSSEBIN needs to be in the system path. In my opinion, modifying the system PATH within python just feels wrong. I would prefer to add the PSSEBIN to you path manually.
Honestly, most users don't know what an environment variable is, so there's probably no harm in modifying it on the fly. Using the installed package mindset we can put the code in an init.py file in our own directory in site-packages.
C:\Python25\Lib\site-packages
$ cat .\pti\__init__.py
import os
import sys
PSSE_LOCATION = r"C:\Program Files\PTI\PSSE32\PSSBIN"
os.environ['PATH'] = os.environ['PATH'] + os.pathsep + PSSE_LOCATION
Now when we start python we have the modified path:
>>> os.environ['PATH'].split(os.pathsep)[-1]
'C:\\Program Files\\PTI\\PSSE32\\PSSBIN'
You should be able to identify the location of PSSBIN reliably through an environment variable or a windows registry entry. This would make the psse-python integration work anywhere.
However, I can't find anything useful in the environment or registry. Maybe it's buried somewhere under Documents and Settings.
I want anyone in our department to pick up the scripts I write and run them with the minimum amount of fuss. By the way, hardcoding the sys.path and PATH modification at the top of the script fits this bill perfectly (assuming the PSSE installs are the same).
I am trying to make this approach similar to what happens with setuptools when you do:
python setup.py develop
because it seems like a similar problem.
An end-result of this effort could also be an psse-python-integration egg (or similar). It could be considered a python package without any real code. Something that users can just download and install to setup their environment.
3 | example of what happens when PSSEBIN isn't in your path |
The method proposed by JervisW requires a chuck of code to be pasted at the top of every script. This would also be a small inconvenience when we begin moving to PSSE33 and in the unlikely chance that someone had PSSE installed in a different path.
You can modify the python search path by adding a .pth file to the site-packages directory which looks like:
C:\Python25\Lib\site-packages
$ cat .\pti.pth
C:\Program Files\PTI\PSSE32\PSSBIN
And a quick check to make sure python can find the psspy module:
python -m psspy
If python can't find the module you'll get a traceback.
To work properly, PSSEBIN needs to be in the system path. Otherwise you get insightful error messages when you try to load a case like:
Invalid file type. example2.sav (OpnApplFil/OPNPTI)
In my opinion, modifying the system PATH within python just feels wrong. I would prefer to add the PSSEBIN to you path manually.
Honestly, most users don't know what an environment variable is, so there's probably no harm in modifying it on the fly. Using the installed package mindset we can put the code in an init.py file in our own directory in site-packages.
C:\Python25\Lib\site-packages
$ cat .\pti\__init__.py
import os
import sys
PSSE_LOCATION = r"C:\Program Files\PTI\PSSE32\PSSBIN"
os.environ['PATH'] = os.environ['PATH'] + os.pathsep + PSSE_LOCATION
Now when we start python we have the modified path:
>>> os.environ['PATH'].split(os.pathsep)[-1]
'C:\\Program Files\\PTI\\PSSE32\\PSSBIN'
You should be able to identify the location of PSSBIN reliably through an environment variable or a windows registry entry. This would make the psse-python integration work anywhere.
However, I can't find anything useful in the environment or registry. Maybe it's buried somewhere under Documents and Settings.
I want anyone in our department to pick up the scripts I write and run them with the minimum amount of fuss. By the way, hardcoding the sys.path and PATH modification at the top of the script fits this bill perfectly (assuming the PSSE installs are the same).
I am trying to make this approach similar to what happens with setuptools when you do:
python setup.py develop
because it seems like a similar problem.
An end-result of this effort could also be an psse-python-integration egg (or similar). It could be considered a python package without any real code. Something that users can just download and install to setup their environment.
4 | No.4 Revision |
The method proposed by JervisW requires a chuck of code to be pasted at the top of every script. This would also be a small inconvenience when we begin moving to PSSE33 and in the unlikely chance that someone had PSSE installed in a different path.
You can modify the python search path by adding a .pth file to the site-packages directory which looks like:
C:\Python25\Lib\site-packages
$ cat .\pti.pth
C:\Program Files\PTI\PSSE32\PSSBIN
And a quick check to make sure python can find the psspy module:
python -m psspy
If python can't find the module you'll get a traceback.
To work properly, PSSEBIN needs to be in the system path. Otherwise you get insightful error messages when you try to load a case like:
Invalid file type. example2.sav (OpnApplFil/OPNPTI)
In my opinion, modifying the system PATH within python just feels wrong. I would prefer to add the PSSEBIN to you path manually.
TODO: This method only seems to work if you invoke python for interactively. To actually work whit will have to be modified.
PSSE docs seems to imply that adding PSSBIN to the system PATH is a good idea anyways.
Honestly, most users don't know what an environment variable is, so there's probably no harm in modifying it on the fly. Using the installed package mindset we can put the code in an init.py file in our own directory in site-packages.
C:\Python25\Lib\site-packages
$ cat .\pti\__init__.py
import os
import sys
PSSE_LOCATION = r"C:\Program Files\PTI\PSSE32\PSSBIN"
os.environ['PATH'] = os.environ['PATH'] + os.pathsep + PSSE_LOCATION
Now when we start python we have the modified path:
>>> os.environ['PATH'].split(os.pathsep)[-1]
'C:\\Program Files\\PTI\\PSSE32\\PSSBIN'
You should be able to identify the location of PSSBIN reliably through an environment variable or a windows registry entry. This would make the psse-python integration work anywhere.
However, I can't find anything useful in the environment or registry. Maybe it's buried somewhere under Documents and Settings.
I want anyone in our department to pick up the scripts I write and run them with the minimum amount of fuss. By the way, hardcoding the sys.path and PATH modification at the top of the script fits this bill perfectly (assuming the PSSE installs are the same).
I am trying to make this approach similar to what happens with setuptools when you do:
python setup.py develop
because it seems like a similar problem.
An end-result of this effort could also be an psse-python-integration egg (or similar). It could be considered a python package without any real code. Something that users can just download and install to setup their environment.
5 | batch file method of setting up environment |
The method proposed by JervisW requires a chuck of code to be pasted at the top of every script. This would also be a small inconvenience when we begin moving to PSSE33 and in the unlikely chance that someone had PSSE installed in a different path.
You can modify the python search path by adding a .pth file to the site-packages directory which looks like:
C:\Python25\Lib\site-packages
$ cat .\pti.pth
C:\Program Files\PTI\PSSE32\PSSBIN
And a quick check to make sure python can find the psspy module:
python -m psspy
If python can't find the module you'll get a traceback.
To work properly, PSSEBIN needs to be in the system path. Otherwise you get insightful error messages when you try to load a case like:
Invalid file type. example2.sav (OpnApplFil/OPNPTI)
In my opinion, modifying the system PATH within python just feels wrong. I would prefer to add the PSSEBIN to you path manually.
TODO: This method only seems to work if you invoke python for interactively. To actually work whit will have to be modified.
PSSE docs seems to imply that adding PSSBIN to the system PATH is a good idea anyways.
Honestly, most users don't know what an environment variable is, so there's probably no harm in modifying it on the fly. Using the installed package mindset we can put the code in an init.py file in our own directory in site-packages.
C:\Python25\Lib\site-packages
$ cat .\pti\__init__.py
import os
import sys
PSSE_LOCATION = r"C:\Program Files\PTI\PSSE32\PSSBIN"
os.environ['PATH'] = os.environ['PATH'] + os.pathsep + PSSE_LOCATION
Now when we start python we have the modified path:
>>> os.environ['PATH'].split(os.pathsep)[-1]
'C:\\Program Files\\PTI\\PSSE32\\PSSBIN'
You should be able to identify the location of PSSBIN reliably through an environment variable or a windows registry entry. This would make the psse-python integration work anywhere.
However, I can't find anything useful in the environment or registry. Maybe it's buried somewhere under Documents and Settings.
PSSE sets the example of using batch files to setup your PSSE environment. See Start Menu -> PSSE-32 -> PSSE-32 Command Prompt. We can follow this example and modify the PSSE-32 Command Prompt batch file like this:
@echo OFF
REM == Start Sane Python Setup ==
SET PYTHONPATH=C:\PROGRA~1\PTI\PSSE32\PSSEBIN;%PYTHONPATH%
SET PATH=C:\Python25\;%PATH%
REM == End Sane Python Setup ==
PATH=C:\PROGRA~1\PTI\PSSE32\PSSBIN;C:\PROGRA~1\PTI\PSSE32\PSSLIB;%PATH%
echo.
echo Your PATH is now set to run PSSĀ®E-32 programs!
echo.
Before any PSSE scripts are run, users have to open the special PSSE-32 command prompt. I think most of the users already do this, so it may dovetail into existing habits.
I want anyone in our department to pick up the scripts I write and run them with the minimum amount of fuss. By the way, hardcoding the sys.path and PATH modification at the top of the script fits this bill perfectly (assuming the PSSE installs are the same).
I am trying to make this approach similar to what happens with setuptools when you do:
python setup.py develop
because it seems like a similar problem.
An end-result of this effort could also be an psse-python-integration egg (or similar). It could be considered a python package without any real code. Something that users can just download and install to setup their environment.