Ask Your Question

Revision history [back]

click to hide/show revision 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

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

Adding PSSE modules python search path

You can modify the python search path by adding a .pth file to the site-packages directory? Like so: directory which looks like:

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: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.

Adding PSSBIN to the system PATH

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'

Intelligently Finding PSSE Install

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.

Why all this work?

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.

click to hide/show revision 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.

Adding PSSE modules python search 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.

Adding PSSBIN to the system PATH

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'

Intelligently Finding PSSE Install

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.

Why all this work?

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.

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.

Adding PSSE modules python search 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.

Adding PSSBIN to the system PATH

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.

Automagically Adding PSSBIN to the system PATH

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'

Intelligently Finding PSSE Install

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.

Why all this work?

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.

click to hide/show revision 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.

Adding PSSE modules python search 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.

Adding PSSBIN to the system PATH

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.

Automagically Adding PSSBIN to the system PATH

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'

Intelligently Finding PSSE Install

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.

Alternate: Using .bat file to setup environment

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.

Why all this work?

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.