PyInstaller

wxPython Users
1

Hello,

As promised, I tried the latest PyInstaller from subversion. I followed the instructions carefully. Using pyinstaller from trunk works better, but still not good. I can successfully make a binary that runs on my system, but it won't run on my wife's Mandriva system.

The file seems to have a lot of hard-coded paths in it, which of course doesn't work on my wife's computer. I'll file a report with the PyInstaller guys, as suggested by Werner.

Next I'll try cxx_Freeze again.

Cheers,
Daniel.

2

Daniel Carrera wrote:

As promised, I tried the latest PyInstaller from subversion. I followed the instructions carefully. Using pyinstaller from trunk works better, but still not good. I can successfully make a binary that runs on my system, but it won't run on my wife's Mandriva system.

This is really a Linux issue: how many libraries are you going to include with your executable? I haven't kept up on it, but I don't think a "Linux Standard Base" really exists. The commercial apps I've seen include the entire C lib, and still only work on a subset of systems.

Probably why most folks distribute rpms, .debs. etc. instead.

(I'm not distributing for Linux now, so I don't have any real suggestions)

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

3

Christopher Barker wrote:

Daniel Carrera wrote:

As promised, I tried the latest PyInstaller from subversion. I followed the instructions carefully. Using pyinstaller from trunk works better, but still not good. I can successfully make a binary that runs on my system, but it won't run on my wife's Mandriva system.

This is really a Linux issue: how many libraries are you going to include with your executable? I haven't kept up on it, but I don't think a "Linux Standard Base" really exists. The commercial apps I've seen include the entire C lib, and still only work on a subset of systems.

This is *not* a Linux issue. PyInstaller is hard-coding paths in my HOME DIRECTORY. Seriously, do you expect someone to have the path "/home/daniel/Projects/" on their computer? Is that a Linux problem? So if I make a Windows app and I hard-code the path C:\Users\Steve and it doesn't work on your computer that would be a Windows problem?

About C libs: I have a hard time believing that a lot of Linux systems don't have the C lib in a standard directory. The C libs is something you can pretty much rely on even from one Unix system to another.

Btw, for several days now I have been able to compile a C++ version of the program statically and have it work on my wife's computer.

Probably why most folks distribute rpms, .debs. etc. instead.

Do you think that distributing RPMs and DEBs would get around the system not having C libs in a standard directory? Think about that for a minute.

(I'm not distributing for Linux now, so I don't have any real suggestions)

My current inclination is to forget about Python and do the work in C++. At least that one seems to work.

Daniel.

4

Daniel Carrera wrote:

This is *not* a Linux issue. PyInstaller is hard-coding paths in my HOME DIRECTORY.

you're right, that's just plain broken. You hadn't specified what paths had been hard-coded. I assumed that PyInstaller wasn't that stupid. I wonder if has a mode similar to py2app's "alias" mode -- where it does point to stuff on your system, and is not expected to work anywhere else.

But that is all a PyInstaller question.

About C libs: I have a hard time believing that a lot of Linux systems don't have the C lib in a standard directory.

they sure do -- but not all the same versions.

Distributing binaries for Linux is notoriously a pain -- though it sounds like you've hit something more fundamentally wrong with PyInstaller, or how you are using it.

It sounds like you know what you are doing, but just in case, is whatever it linked to in your home dir something that it might have expected to be in a standard system location?

Btw, for several days now I have been able to compile a C++ version of the program statically and have it work on my wife's computer.

well, FWIW, I've often had trouble statically linking on Linux -- gcc likes to prefer dynamic linking. I also had a colleague who pent days getting a wx C++ app to link statically on Windows -- so you got lucky there (or really know what you're doing).

And you've been extraordinarily unlucky with wxPython, pyInstaller, etc. It seems most people get these things working fine on teh first, easy test app -- then struggle with this or that complex package.

I know I've never had a problem eith py2exe or py2app on teh simple apps.

Probably why most folks distribute rpms, .debs. etc. instead.

Do you think that distributing RPMs and DEBs would get around the system not having C libs in a standard directory? Think about that for a minute.

of course not, but they do have dependency tracking, and are usually built for specific systems.

My current inclination is to forget about Python and do the work in C++. At least that one seems to work.

Whatever works for you, but don't confuse "easy to do the first easy thing" with "more productive in the long run"

Once you get PyInstaller or whatever working, you're done with that -- you'll be banging your head against C++ forever.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

5

Christopher Barker wrote:

About C libs: I have a hard time believing that a lot of Linux systems don't have the C lib in a standard directory.

they sure do -- but not all the same versions.

Ok, I see what you mean. I'm not sure what can be done about that. There is good reason for some people to want older library versions and there is good reason for other people to want newer library versions.

It sounds like you know what you are doing, but just in case, is whatever it linked to in your home dir something that it might have expected to be in a standard system location?

Let's see... Hmm... it hard-coded the location of pyinstaller itself. specifically:

/home/daniel/Projects/Monda/Wordlibro/Python/pyinstaller/iu.py

That suggests that I'm using it wrong. I tried to follow the instructions to the letter. Maybe I'm supposed to install it on my system, but there is no "setup.py" and no "INSTALL.txt" so it doesn't look like I'm supposed to install it.

Btw, for several days now I have been able to compile a C++ version of the program statically and have it work on my wife's computer.

well, FWIW, I've often had trouble statically linking on Linux -- gcc likes to prefer dynamic linking. I also had a colleague who pent days getting a wx C++ app to link statically on Windows -- so you got lucky there (or really know what you're doing).

Must be luck. I know very little C++, considering that I've only been using it for a few days. I knew C already, but I hadn't touched C in 10 years. I did get help from the wxWidgets mailing list. The told me I had to compile wxWidgets itself statically, and then it worked. Simple, but it might have taken me a week to figure that out myself.

And you've been extraordinarily unlucky with wxPython, pyInstaller, etc. It seems most people get these things working fine on teh first, easy test app -- then struggle with this or that complex package.

I know I've never had a problem eith py2exe or py2app on teh simple apps.

Maybe these apps are not designed with Linux in mind. Or maybe they assume something that may not apply to a new Python user. Note that I haven't tried py2exe or py2app because I'm working on Linux first.

My current inclination is to forget about Python and do the work in C++. At least that one seems to work.

Whatever works for you, but don't confuse "easy to do the first easy thing" with "more productive in the long run"

Once you get PyInstaller or whatever working, you're done with that -- you'll be banging your head against C++ forever.

That's a good point. I shouldn't dismiss Python yet. PyInstaller might be a big issue, but if it is fixed, it is fixed forever.

Daniel.

6

No, in that case you would simply distribute the Python modules of your application and any other resources it needs (scripts, images, docs, etc.) and rely on the system provided libraries (including wxPython) for everything else. Your Deb or RPM would have dependencies defined for the other things you need so those packages would be installed automatically when your package is installed, if they are not already installed. *THAT* is the Linux way.

What Chris was referring to about the c runtime lib and etc. is how some commercial developers manage distributing their stuff to Linux when they refuse to open their source. They tend to bundle everything in static linked executables, including things that are normally system libs, so they don't have to worry about being compatible with different versions of those libs on different distros. Sometimes this works ok, but for it to really work across a wide set of distros you usually need to do your build on a really old version of RedHat or something, and then static link to everything that is not the C runtime lib. Of course static linking to GTK is usually a bad idea (and violates the license too) but to be binary compatible with as many distros as possible that may be needed.

···

On 1/19/10 1:18 PM, Daniel Carrera wrote:

Probably why most folks distribute rpms, .debs. etc. instead.

Do you think that distributing RPMs and DEBs would get around the system
not having C libs in a standard directory? Think about that for a minute.

--
Robin Dunn
Software Craftsman

7

Robin Dunn wrote:

···

On 1/19/10 1:18 PM, Daniel Carrera wrote:

Probably why most folks distribute rpms, .debs. etc. instead.

Do you think that distributing RPMs and DEBs would get around the system
not having C libs in a standard directory? Think about that for a minute.

No, in that case you would simply distribute the Python modules of your application and any other resources it needs (scripts, images, docs, etc.) and rely on the system provided libraries (including wxPython) for everything else. Your Deb or RPM would have dependencies defined for the other things you need so those packages would be installed automatically when your package is installed, if they are not already installed. *THAT* is the Linux way.

And satisfying the dependencies is pretty easy on Linux - the package manager will prompt for the necessary downloads. Python's pretty much a standard on modern Linux, and wx is fairly small too.
What I do though, is for third-party (small) Python modules that I use is to include them in my source code -- that way, my users won't have to download things like ConfigObj, BeautifulSoup and a few others.

--
Steven Sproat, BSc
http://www.basicrpg.com/

8

Daniel Carrera wrote:

This is *not* a Linux issue. PyInstaller is hard-coding paths in my HOME DIRECTORY. Seriously, do you expect someone to have the path "/home/daniel/Projects/" on their computer? Is that a Linux problem? So if I make a Windows app and I hard-code the path C:\Users\Steve and it doesn't work on your computer that would be a Windows problem?

This really is something you should take to the PyInstaller group. Either you're the first one to run into it, in which case Giovanni should know about it so he can fix it, or it's something in your spec file, in which case you'll learn.

···

--
Don Dwiggins
Advanced Publishing Technology