I have several python apps (some wxPython, some plain text-mode
stuff) that I distribute internally for installation on Win32
machines. They're bundled/installed using py2exe and inno
setup.

I followed what I think is the normal procedure of installing
each app in its own directory under /Program
Files/<vendor>/<app>.

The problem is that the apps only run if they're started with
the install directory as the current working directory.
Otherwise they can't find the .dll's they use from the install
directory.

Is there some way to temporarily add the app's install
directory to the search path for .dll's?

--
Grant Edwards grante Yow! .. I think I'd
at better go back to my DESK
visi.com and toy with a few common
MISAPPREHENSIONS...

"Grant Edwards" <grante@visi.com> schrieb im Newsbeitrag
news:11ev0tcg9n2ndd@corp.supernews.com...
|I have several python apps (some wxPython, some plain text-mode
| stuff) that I distribute internally for installation on Win32
| machines. They're bundled/installed using py2exe and inno
| setup.
|
| I followed what I think is the normal procedure of installing
| each app in its own directory under /Program
| Files/<vendor>/<app>.
|
| The problem is that the apps only run if they're started with
| the install directory as the current working directory.
| Otherwise they can't find the .dll's they use from the install
| directory.

AFAIK, Windows normally *does* search the directory where the executable
module for the current process lives in for dlls. What sort of dlls are
given you trouble?

--

Vincent Wehren




|
| Is there some way to temporarily add the app's install
| directory to the search path for .dll's?
|
| --
| Grant Edwards grante Yow! .. I think I'd
| at better go back to my
DESK
| visi.com and toy with a few
common
| MISAPPREHENSIONS...

Vincent, I'm not sure I completely understand your question but this
link may be the answer nonetheless:
http://www.jrsoftware.org/isfaq.php#workingdir

And here is how I make sure I'm always using the right directory in my scripts:

Put this code at the top:
import sys
curdir=os.path.dirname(sys.argv[0])
#print curdir
Then I use curdir to build all of the paths in my app:
For example let's get a list of files in a folder:
lstresumes=os.listdir(os.path.join(curdir,resume_f older_path)) #get
list of resumes


Below is optional but helps me keep a python module in the exe's main
directory and be able to edit it. Otherwise the main module reads
from py2exe's lib file which seems harder to change:
sys.path.insert(0,curdir) #read usersettings.py from main dir, not library


Let me know if that helps (I may be answering the question I had
yesterday and not yours though ;-)

-Greg


On 8/2/05, vincent wehren <vincent@visualtrans.de> wrote:[color=blue]
>
> "Grant Edwards" <grante@visi.com> schrieb im Newsbeitrag
> news:11ev0tcg9n2ndd@corp.supernews.com...
> |I have several python apps (some wxPython, some plain text-mode
> | stuff) that I distribute internally for installation on Win32
> | machines. They're bundled/installed using py2exe and inno
> | setup.
> |
> | I followed what I think is the normal procedure of installing
> | each app in its own directory under /Program
> | Files/<vendor>/<app>.
> |
> | The problem is that the apps only run if they're started with
> | the install directory as the current working directory.
> | Otherwise they can't find the .dll's they use from the install
> | directory.
>
> AFAIK, Windows normally *does* search the directory where the executable
> module for the current process lives in for dlls. What sort of dlls are
> given you trouble?
>
> --
>
> Vincent Wehren
>
>
>
>
> |
> | Is there some way to temporarily add the app's install
> | directory to the search path for .dll's?
> |
> | --
> | Grant Edwards grante Yow! .. I think I'd
> | at better go back to my
> DESK
> | visi.com and toy with a few
> common
> | MISAPPREHENSIONS...
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
> [/color]


--
Gregory Piñero
CEO and Founder
Blended Technologies
(www.blendedtechnologies.com)

On 8/2/05, Gregory Piñero <gregpinero@gmail.com> wrote:[color=blue]
> Vincent, I'm not sure I completely understand your question but this
> link may be the answer nonetheless:
> http://www.jrsoftware.org/isfaq.php#workingdir[/color]

I meant to say Grant, ... , Vincent wasn't the one with the question. Sorry.

On 2005-08-02, vincent wehren <vincent@visualtrans.de> wrote:[color=blue]
>
> "Grant Edwards" <grante@visi.com> schrieb im Newsbeitrag
> news:11ev0tcg9n2ndd@corp.supernews.com...
>|I have several python apps (some wxPython, some plain text-mode
>| stuff) that I distribute internally for installation on Win32
>| machines. They're bundled/installed using py2exe and inno
>| setup.
>|
>| I followed what I think is the normal procedure of installing
>| each app in its own directory under /Program
>| Files/<vendor>/<app>.
>|
>| The problem is that the apps only run if they're started with
>| the install directory as the current working directory.
>| Otherwise they can't find the .dll's they use from the install
>| directory.
>
> AFAIK, Windows normally *does* search the directory where the executable
> module for the current process lives in for dlls. What sort of dlls are
> given you trouble?[/color]

One's a "driver" for a CAN bus USB widget. The other failure
that springs to mind is that gnuplot-py couldn't find something
(could have been an .exe) that was in the app directory.

--
Grant Edwards grante Yow! HUGH BEAUMONT died
at in 1982!!
visi.com

"Gregory Piñero" <gregpinero@gmail.com> schrieb im Newsbeitrag
news:mailman.2632.1123005673.10512.python-list@python.org...

|And here is how I make sure I'm always using the right directory in my
scripts:
|
|Put this code at the top:
|import sys
|curdir=os.path.dirname(sys.argv[0])
|#print curdir
|Then I use curdir to build all of the paths in my app:
|For example let's get a list of files in a folder:
|lstresumes=os.listdir(os.path.join(curdir,resume_ folder_path)) #get
|list of resumes

<snipped>

Greg,

If you need something that works both on a frozen app as well as an
(unfrozen) python
script, you'd be better off using something like:

def getAppPrefix():
"""Return the location the app is running from
"""
isFrozen = False
try:
isFrozen = sys.frozen
except AttributeError:
pass
if isFrozen:
appPrefix = os.path.split(sys.executable)[0]
else:
appPrefix = os.path.split(os.path.abspath(sys.argv[0]))[0]
return appPrefix

Now you can use the return value of getAppPrefix() everywhere you need to
calculate paths relative to your app, regardless if it involves a regular
script or py2exe'ified one.

Regards,

--

Vincent Wehren

"Grant Edwards" <grante@visi.com> schrieb im Newsbeitrag
news:11evdoj8c4brd1b@corp.supernews.com...
| On 2005-08-02, vincent wehren <vincent@visualtrans.de> wrote:
| >
| > "Grant Edwards" <grante@visi.com> schrieb im Newsbeitrag
| > news:11ev0tcg9n2ndd@corp.supernews.com...
| >|I have several python apps (some wxPython, some plain text-mode
| >| stuff) that I distribute internally for installation on Win32
| >| machines. They're bundled/installed using py2exe and inno
| >| setup.
| >|
| >| I followed what I think is the normal procedure of installing
| >| each app in its own directory under /Program
| >| Files/<vendor>/<app>.
| >|
| >| The problem is that the apps only run if they're started with
| >| the install directory as the current working directory.
| >| Otherwise they can't find the .dll's they use from the install
| >| directory.
| >
| > AFAIK, Windows normally *does* search the directory where the executable
| > module for the current process lives in for dlls. What sort of dlls are
| > given you trouble?
|
| One's a "driver" for a CAN bus USB widget. The other failure
| that springs to mind is that gnuplot-py couldn't find something
| (could have been an .exe) that was in the app directory.

Grant,

If you are building paths in you code that are relative to your app, please
see my reply to Greg's post. If not, you may as a workaround want to try to
add the frozen application's directory to the system path environment
variable. Windows will look for dlls there, too.

To get the app's actual location, you will need something like the
getAppPrefix() function as per my reply to Greg's reply. The getAppPrefix()
function will also hold when the user adds your frozen app to his/her system
path and call the app from any location from the command line - sys.argv[0]
just won't do the trick in such a setting.


HTH,

--

Vincent Wehren










|
| --
| Grant Edwards grante Yow! HUGH BEAUMONT
died
| at in 1982!!
| visi.com

> If you need something that works both on a frozen app as well as an[color=blue]
> (unfrozen) python
> script, you'd be better off using something like:
>
> def getAppPrefix():
> """Return the location the app is running from
> """
> isFrozen = False
> try:
> isFrozen = sys.frozen
> except AttributeError:
> pass
> if isFrozen:
> appPrefix = os.path.split(sys.executable)[0]
> else:
> appPrefix = os.path.split(os.path.abspath(sys.argv[0]))[0]
> return appPrefix
> [/color]

Vincent,

This sounds interesting. A few questions for you:
Why don't I see sys.frozen in interpreter?
Does it only appear when it is frozen?
What do you mean by frozen, how does python know?
What does sys.executable do?

Thanks,

Greg

On 2005-08-02, vincent wehren <vincent@visualtrans.de> wrote:
[color=blue]
> If you are building paths in you code that are relative to
> your app,[/color]

I'm not using any paths. I use cytpes to load a .dll, and I
don't really know what gnuplot-py is doing, but I think it's
executing a .exe file and talking to it via a pipe or something.
[color=blue]
> please see my reply to Greg's post. If not, you may
> as a workaround want to try to add the frozen application's
> directory to the system path environment variable. Windows
> will look for dlls there, too.[/color]

That's probably the right answer.
[color=blue]
> To get the app's actual location, you will need something like
> the getAppPrefix() function as per my reply to Greg's reply.
> The getAppPrefix() function will also hold when the user adds
> your frozen app to his/her system path and call the app from
> any location from the command line - sys.argv[0] just won't do
> the trick in such a setting.[/color]

I'll give that a try.

--
Grant Edwards grante Yow! .. I think I'd
at better go back to my DESK
visi.com and toy with a few common
MISAPPREHENSIONS...

"Gregory Piñero" <gregpinero@gmail.com> schrieb im Newsbeitrag
news:mailman.2635.1123008925.10512.python-list@python.org...[color=blue]
> If you need something that works both on a frozen app as well as an
> (unfrozen) python
> script, you'd be better off using something like:
>[color=green]
>> def getAppPrefix():
>> """Return the location the app is running from
>> """
>> isFrozen = False
>> try:
>> isFrozen = sys.frozen
>> except AttributeError:
>> pass
>> if isFrozen:
>> appPrefix = os.path.split(sys.executable)[0]
>> else:
>> appPrefix = os.path.split(os.path.abspath(sys.argv[0]))[0]
>> return appPrefix
>>[/color]
>
>Vincent,
>
>This sounds interesting. A few questions for you:
>Why don't I see sys.frozen in interpreter?
>Does it only appear when it is frozen?[/color]

Yes. The sys.frozen attribute is added by py2exe.
[color=blue]
>What do you mean by frozen, how does python know?[/color]

Python doesn't know - it is just told so ;)
[color=blue]
>What does sys.executable do?[/color]

sys.executable gives you the path of the executing binary. Normally, this
will be something like
"c:\\python24\\python.exe" - since the interpreter is the executing binary.
Once you have frozen your python application, it will return the path to
your app.


--

Vincent
[color=blue]
>
>Thanks,
>
>Greg[/color]