Mac Installer

Robin et al,

As we know, there is an issue with the Mac installer under Mavericks (OS-X 10.9) – it doesn’t satisfy the newest security settings. I’m not running Mavericks, but have helped a couple people out, and it seems lowering the security setting allows it to work.

But the error message you get is cryptic and just plain wrong, so this is going to be confusing of folks over and over again. There has a beena bit of discussion on the python-mac list, and Ned Deily wrote:

“”"

Taking a quick look at the dmg contents, it seems somewhat different

from other bundle-format pkgs I’ve looked at. My guess is that

Installer.app changed for 10.8 and is less tolerant of old packaging

formats. Installer.app certainly still does support older bundle-format

packages (as opposed to the 10.5+ “flat” packages which are capable of

being signed), even in 10.9. The current python.org installers, for

example, are still in the old format. So the wxPython package should be

fixable. If support for installing on OS X 10.4 or earlier is not

needed, the better solution would be to migrate to more recent packaging

tools.

“”"

Perhaps we can help do that – what are you using to build the mpkg now?

Also – any interest it doing a wheel build? that is theoretically the way to go in the future – and a allowing people to “pip install wxpython” would be pretty nice.

-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

a partial answer to my own question -- this looks like it would be a useful
place to start:

-Chris

···

On Mon, Dec 30, 2013 at 8:50 AM, Chris Barker <chris.barker@noaa.gov> wrote:

Perhaps we can help do that -- what are you using to build the mpkg now?

--

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

FWIW, the Mac installer format is deprecated in its entirety, and no longer ships with Xcode. So while it is possible to find it on the Mac Developer web site and download it still, the writing is on the wall for the Mac installer. (They want everyone publishing via the app store now.)

There is a nasty hack you can do, though it might require a long shower afterwards. :wink: You create a little application whose sole purpose is to start the installer, and then you codesign that app. (Using Python + py2app to build the app does work for this, so long as you use the command line codesign tool on it afterwards.) It’s a quick fix that will probably take a lot less time than re-writing the installer, though I wonder how long before Apple decides they want to close that gap. My suggestion on this topic would be to not spend much time on the Mac installer (maybe do this hack and that’s it if you want a solution ASAP), and just focus any time spent on installation work into pip / easy_install support instead.

Best,

Kevin

···

Perhaps we can help do that – what are you using to build the mpkg now?

a partial answer to my own question – this looks like it would be a useful place to start:

http://stackoverflow.com/questions/11487596/making-os-x-installer-packages-like-a-pro-xcode4-developer-id-mountain-lion-re

-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

Chris Barker wrote:

Robin et al,

As we know, there is an issue with the Mac installer under Mavericks
(OS-X 10.9) -- it doesn't satisfy the newest security settings. I'm not
running Mavericks, but have helped a couple people out, and it seems
lowering the security setting allows it to work.

But the error message you get is cryptic and just plain wrong, so this
is going to be confusing of folks over and over again. There has a beena
bit of discussion on the python-mac list, and Ned Deily wrote:

"""
Taking a quick look at the dmg contents, it seems somewhat different
from other bundle-format pkgs I've looked at. My guess is that
Installer.app changed for 10.8 and is less tolerant of old packaging
formats. Installer.app certainly still does support older bundle-format
packages (as opposed to the 10.5+ "flat" packages which are capable of
being signed), even in 10.9. The current python.org <http://python.org>
installers, for
example, are still in the old format. So the wxPython package should be
fixable. If support for installing on OS X 10.4 or earlier is not
needed, the better solution would be to migrate to more recent packaging
tools.
"""

Perhaps we can help do that -- what are you using to build the mpkg now?

Also -- any interest it doing a wheel build? that is theoretically the
way to go in the future -- and a allowing people to "pip install
wxpython" would be pretty nice.

The wxPython installer hasn't been seriously modified in a *very* long time. I think it is basically the same as what we used for the OSX 10.2 installers! If there ever was a dinosaur in wxPython, this is it.

However, I haven't had much interest in updating it because I plan on doing away with it entirely for Phoenix. Currently Phoenix is able to be totally self-contained and relocatable on all 3 main platforms, in other words the wxWidgets shared libs are able to be included in the same bundle as the wxPython extension modules. This means that we no longer need to install bits and pieces all over the place and that wxPython no longer needs to be able to find the wx libs at a certain place in the file-system. So Phoenix will only be released as source (a setuptools compatible tarball), binary eggs, and eventually the wheel packages will probably be added too.

···

--
Robin Dunn
Software Craftsman

The wxPython installer hasn't been seriously modified in a *very* long time. I think it is basically the same as what we used for the OSX 10.2 installers! If there ever was a dinosaur in wxPython, this is it.

Well, that explains it.

However, I haven't had much interest in updating it because I plan on doing away with it entirely for Phoenix. Currently Phoenix is able to be totally self-contained and relocatable on all 3 main platforms, in other words the wxWidgets shared libs are able to be included in the same bundle as the wxPython extension modules. This means that we no longer need to install bits and pieces all over the place and that wxPython no longer needs to be able to find the wx libs at a certain place in the file-system.

This does sound much better.

So Phoenix will only be released as source (a setuptools compatible tarball), binary eggs, and eventually the wheel packages will probably be added too.

I'd skip the binary eggs and go straight to wheels...

But it may be a while before Phoenix is the go-to version. How
adaptable to the old builds is the new packaging?

- Chris

···

On Dec 30, 2013, at 11:22 AM, Robin Dunn <robin@alldunn.com> wrote:

Chris Barker - NOAA Federal wrote:

So Phoenix will only be released as source (a setuptools compatible tarball), binary eggs, and eventually the wheel packages will probably be added too.

I'd skip the binary eggs and go straight to wheels...

It turns out that "eventually" in this case was about 5 minutes plus testing time. :slight_smile:

http://trac.wxwidgets.org/changeset/75496/wxPython/Phoenix

But it may be a while before Phoenix is the go-to version. How
adaptable to the old builds is the new packaging?

I'm not sure. I haven't really looked at the new Installer formats, build tools, etc. at all. What is being used now are some 3rd party scripts that were available before Apple made Installer official and started providing tools for it. Those scripts are used to build the app bundles for the demo, etc. and also for building the Installer package. IIRC the main thing that should be changed is the format used for the installer's internal archive, and probably also setting things up to be able to digitally sign the package.

···

On Dec 30, 2013, at 11:22 AM, Robin Dunn<robin@alldunn.com> wrote:

--
Robin Dunn
Software Craftsman

I'd skip the binary eggs and go straight to wheels...

It turns out that "eventually" in this case was about 5 minutes plus
testing time. :slight_smile:

wxTrac has been migrated to GitHub Issues - wxWidgets

cool! I expected you'd done the had work already.

But it may be a while before Phoenix is the go-to version. How

adaptable to the old builds is the new packaging?

I'm not sure. I haven't really looked at the new Installer formats, build
tools, etc. at all.

Poorly worded question -- what I meant was:

How hard would it be to build classic the way you are building Phoenix,
which would then lend itself to wheels and conda, and who knows what?

-Chris

···

On Mon, Dec 30, 2013 at 6:28 PM, Robin Dunn <robin@alldunn.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

Chris Barker wrote:

On Mon, Dec 30, 2013 at 6:28 PM, Robin Dunn <robin@alldunn.com

        But it may be a while before Phoenix is the go-to version. How
        adaptable to the old builds is the new packaging?

    I'm not sure. I haven't really looked at the new Installer formats,
    build tools, etc. at all.

Poorly worded question -- what I meant was:

How hard would it be to build classic the way you are building Phoenix,
which would then lend itself to wheels and conda, and who knows what?

It should be doable, but probably not easily.

···

--
Robin Dunn
Software Craftsman

Darn -- but maybe I'll take a poke at it at some point....

-Chris

···

On Tue, Dec 31, 2013 at 11:53 AM, Robin Dunn <robin@alldunn.com> wrote:

How hard would it be to build classic the way you are building Phoenix,
which would then lend itself to wheels and conda, and who knows what?

It should be doable, but probably not easily.

--

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