wxPython on Mac: Framework build?

Hello list--

I am trying to help a coworker distribute software bundles to his
collaborators for development use. Because our code has a significant
number of dependencies (some quite specific, e.g. I use features only
available in wxPython 2.8.12) we've been trying to distribute all of
them with our code. This results in a large and unwieldy package -
since the target audience is other developers the lack of elegance is
not a problem, but we're running into problems on the Mac side. My
understanding is that wxPython needs the framework build of Python to
run. However, the Python framework is not relocatable as far as I can
tell. We've dealt with this in two ways in the past:

1) build in /usr/local/some_path, and force everyone to install into
that location
2) use a grotesque shell script that calls otool and install_name_tool
(from Apple's developer tools) to relocate the Python framework and
associated libraries
3) build from source

Neither of the first two solutions is satisfactory - we used (1) for
many years, and eventually I figured out (2) but I have never been
happy about it. We are now trying to distribute a separate set of
packages for developers rather than end-users and the options are
becoming even less appealing. Has anyone figured out a way to
distribute disorganized collections of pre-compiled code
(incorporating wxPython) on Mac that are not tied to a particular
location? py2app is not an option, since the goal here is
development, not general use.

thanks,
Nat

Hi Nat,

[snip]

Has anyone figured out a way to
distribute disorganized collections of pre-compiled code
(incorporating wxPython) on Mac that are not tied to a particular
location? py2app is not an option, since the goal here is
development, not general use.

I don't think there's anything ready-made, no. :frowning: I've found virtualenv very helpful in building up a portable Python environment, but wxPython still will need to have its installer run since it needs to write to admin locations, and after that some manual hacks need to be made (wiki.wxpython.org has the details, try searching for virtualenv).

What you might be able to do is have your virtualenv in an absolute location (say, /venv/myenv), then do a custom wxWidgets build from source that installs the dylibs inside the virtualenv root, and then use the wx-config it installed there when building wxPython. This should give you a distributable environment, though if you're not using the system Python you'll still need them to install the Python you used from python.org, and will probably need the wrapper script you can find on the wiki to run GUI scripts. (If you wanted to be really clever, you could probably rename /venv/myenv/bin/python to /venv/myenv/bin/python-venv and then name the wrapper script python :slight_smile:

Regards,

Kevin

···

On Jul 2, 2012, at 5:41 PM, Nat Echols wrote:

thanks,
Nat

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

I am trying to help a coworker distribute software bundles to his
collaborators for development use. Because our code has a significant
number of dependencies (some quite specific, e.g. I use features only
available in wxPython 2.8.12) we've been trying to distribute all of
them with our code.

Is it out of the question to simply use the standard pyton.org build,
and pacakges made for it?

It could conflict with other versions of packages that folks need, but
maybe not, and it would be a whole lot easier...

3) build from source

Is this so heinous? you should be abel to build python itself as a
Framework Build, but in a non-standard location or with a non-standard
name, then build all teh packages against that, and distutils should
take care of it from there.

Kevin,

weren't you working on a system that would buld a set of packages for
you? Perhaps it could help here.

Boy -- I sure with python has a standard way to do package versioning
-- that's the source of all this mess and hacks...

But that brings up an idea -- setuptools is supposed to provide a
package versioning system -- could you use that?

thinking more now -- perhaps virtualenv is the answer -- ti would wokr
out of the box for many packages, and you could hack the few that
don't support it (wxPython, any others). It's a hack, but probably a
lot less hacking than the other options, and virtualenv is a pretty
standard tool that everyone should be familiar with these days.

Has anyone figured out a way to
distribute disorganized collections of pre-compiled code
(incorporating wxPython) on Mac that are not tied to a particular
location? py2app is not an option, since the goal here is
development, not general use.

But could you leverage py2app to build a dvelopent environment?
Essentially, it would do the otool hackry for you...

There is also bbfreeze, which used to (sort of) support the Mac, and
did have the feature of giving you a regular python interpreter in the
environment.

other options that might help:

eGenix PyRun - One file Python Runtime

  eGenix.com: Products: Python: eGenix PyRun - One file Python Runtime

and:

PortablePython:
   http://www.portablepython.com/

Windows only -- but it looks like a Mac port is what you need, so
maybe there is something to leverage there.

-Chris

···

On Mon, Jul 2, 2012 at 5:41 PM, Nat Echols <nathaniel.echols@gmail.com> wrote:

--

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

Hey Chris and all,

I am trying to help a coworker distribute software bundles to his
collaborators for development use. Because our code has a significant
number of dependencies (some quite specific, e.g. I use features only
available in wxPython 2.8.12) we've been trying to distribute all of
them with our code.

Is it out of the question to simply use the standard pyton.org build,
and pacakges made for it?

It could conflict with other versions of packages that folks need, but
maybe not, and it would be a whole lot easier...

3) build from source

Is this so heinous? you should be abel to build python itself as a
Framework Build, but in a non-standard location or with a non-standard
name, then build all teh packages against that, and distutils should
take care of it from there.

Kevin,

weren't you working on a system that would buld a set of packages for
you? Perhaps it could help here.

Yeah, gattai. gattai download | SourceForge.net

Still a work in progress, though I'm already using it for many of my own projects, and it's pretty nice for putting together a build environment (both Python and C++, or some of both) from scratch without having to manually run a ton of commands.

Boy -- I sure with python has a standard way to do package versioning
-- that's the source of all this mess and hacks...

But that brings up an idea -- setuptools is supposed to provide a
package versioning system -- could you use that?

thinking more now -- perhaps virtualenv is the answer -- ti would wokr
out of the box for many packages, and you could hack the few that
don't support it (wxPython, any others). It's a hack, but probably a
lot less hacking than the other options, and virtualenv is a pretty
standard tool that everyone should be familiar with these days.

It does work pretty well for most things. virtualenv's issue on Mac is simply that it's not bundling the Python Framework inside of it and redirecting to the Python inside Python.app. With some hacking, it might be possible to get it to do so. Most of the rest of the stuff don't need hacks at all.

Has anyone figured out a way to
distribute disorganized collections of pre-compiled code
(incorporating wxPython) on Mac that are not tied to a particular
location? py2app is not an option, since the goal here is
development, not general use.

But could you leverage py2app to build a dvelopent environment?
Essentially, it would do the otool hackry for you…

I think Phoenix has some functions for this in the build script, if it's needed it could probably be pulled out into a separate library somewhere. (gattai.tools.macChangeInstallNames? :slight_smile:

Regards,

Kevin

···

On Jul 3, 2012, at 10:29 AM, Chris Barker wrote:

On Mon, Jul 2, 2012 at 5:41 PM, Nat Echols <nathaniel.echols@gmail.com> wrote:

There is also bbfreeze, which used to (sort of) support the Mac, and
did have the feature of giving you a regular python interpreter in the
environment.

other options that might help:

eGenix PyRun - One file Python Runtime

eGenix.com: Products: Python: eGenix PyRun - One file Python Runtime

and:

PortablePython:
  http://www.portablepython.com/

Windows only -- but it looks like a Mac port is what you need, so
maybe there is something to leverage there.

-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

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en