468,115 Members | 2,021 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,115 developers. It's quick & easy.

py2exe 0.5.0 and data_files

Hello,

I am trying to understand how py2exe 0.5.0 deals with data files.
My application tries to access certain data files via sys.path[0]
(e.g. the file 'menus.def' which lies in the same path as the
python script (or the .exe which py2exe produces, respectively)
is accessed via os.path.join(sys.path[0],'menus.def').

Now I have the data files which I need in the data_files list given
as an argument to the setup method, and py2exe does copy them to
the dist subdirectory all right. However, sys.path[0] is not the
path where the program resides, but the path + 'library.zip'.

Is there an elegant way to proceed? Of course, I could remove the
'library.zip' to find the actual path, but that somehow does not
look like the 'right thing'. I would prefer a solution which works
for the genuine Python script (not packaged by py2exe) as well as
for the .exe.

Thanks in advance for any comments,

Ulrich
Jul 18 '05 #1
5 2775
Try the following...

ex_name = 'myprogram.exe'

if sys.path[0][-len(ex_name):] == ex_name:
path = os.path.split(sys.path[0])
else:
path = os.path.split(__file__)

I don't know if the above works correctly when the script is not a part
of an executable, but is imported with zipimport.

- Josiah
Jul 18 '05 #2
Josiah Carlson <jc******@nospam.uci.edu> writes:
Try the following [...]


Thanks for your suggestion. I see that I can get around this
problem by analyzing sys.path[0] and proceeding case by case.
However, my understanding is that it should not be necessary
for the application to "know" that it will be packaged by
py2exe later. In other words, why does py2exe "change"
sys.path[0]? Or, if this change is justified (and it may well
be), maybe my application shpuld not use sys.path[0] but a
different way to find out the path where it resides?

In addition, since this change in the behavior of py2exe forces
me to change the Python application which I want to package
itself, I am asking myself whether there are other changes that
have to be made but which are not as obvious as this one.

(All this is not meant as criticism towards py2exe; it is a
great program. But I would like to improve my understanding
of its behavior, and of what is the right thing to do in my
application.)

Ulrich
Jul 18 '05 #3
> Thanks for your suggestion. I see that I can get around this
problem by analyzing sys.path[0] and proceeding case by case.
However, my understanding is that it should not be necessary
for the application to "know" that it will be packaged by
py2exe later. In other words, why does py2exe "change"
sys.path[0]? Or, if this change is justified (and it may well
be), maybe my application shpuld not use sys.path[0] but a
different way to find out the path where it resides?
sys.path[0] has different meanings depending on the context. These are
the two cases I've come across. While there could be more,

In addition, since this change in the behavior of py2exe forces
me to change the Python application which I want to package
itself, I am asking myself whether there are other changes that
have to be made but which are not as obvious as this one.
It is possible, but doubtful. I use this same method for PyPE
(http://pype.sf.net), and aside from people using paths with unicode
characters in them, I've had few (if any) issues with source vs.
executable compatibility. There is one outstanding issue, but the bug
reports haven't specified what are the conditions of the 'error', only
that a certain set of related features don't work.

(All this is not meant as criticism towards py2exe; it is a
great program. But I would like to improve my understanding
of its behavior, and of what is the right thing to do in my
application.)


Special case the finding of the running path, and work from there.

- Josiah
Jul 18 '05 #4
Ulrich Goertz <u@g0ertz.de> writes:
Hello,

I am trying to understand how py2exe 0.5.0 deals with data files.
My application tries to access certain data files via sys.path[0]
(e.g. the file 'menus.def' which lies in the same path as the
python script (or the .exe which py2exe produces, respectively)
is accessed via os.path.join(sys.path[0],'menus.def').

Now I have the data files which I need in the data_files list given
as an argument to the setup method, and py2exe does copy them to
the dist subdirectory all right. However, sys.path[0] is not the
path where the program resides, but the path + 'library.zip'.

Is there an elegant way to proceed? Of course, I could remove the
'library.zip' to find the actual path, but that somehow does not
look like the 'right thing'. I would prefer a solution which works
for the genuine Python script (not packaged by py2exe) as well as
for the .exe.


There is a sample 'hello.py' in the py2exe\samples\simple subdirectory,
which lets you explore the differences between the normal Python script,
and the executable. I don't have time now - more later.

Thomas
Jul 18 '05 #5
Thomas Heller <th*****@python.net> writes:
Ulrich Goertz <u@g0ertz.de> writes:
Now I have the data files which I need in the data_files list given
as an argument to the setup method, and py2exe does copy them to
the dist subdirectory all right. However, sys.path[0] is not the
path where the program resides, but the path + 'library.zip'.
There is a sample 'hello.py' in the py2exe\samples\simple subdirectory,
which lets you explore the differences between the normal Python script,
and the executable. I don't have time now - more later.


Thanks for the pointer! I had briefly looked at the setup.py script in
samples/simple before, but not at hello.py itself ...

Thanks for writing py2exe, and kind regards,

Ulrich
Jul 18 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Bryan | last post: by
4 posts views Thread by Werner Merkl | last post: by
8 posts views Thread by PipedreamerGrey | last post: by
4 posts views Thread by bwaha | last post: by
reply views Thread by devnew | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.