Re: [Pyobjc-dev] buildapplication strawman

[Just v. R. <ju...@le...>]

Oooh, lots of stuff...

Jack Jansen wrote:

[ Mac/script/buildappbundle.py ]
> It's only been there for a week or two, so I doubt anyone gets upset.
> But: do keep the commandline interface working (or, if you move the
> functionality to Lib, keep the driver main program in the scripts
> folder), as I use it when building MacPython-OSX 2.2 (the MacPython
> that will sit on /usr/bin/python).
> 
> And note that the tool has nothing python-specific, really. I use it
> with my OpenGL C and C++ applications too. I build these with
> Makefiles (they run on both Linux and OSX), and for OSX the last
> build step is buildappbundle, which stuffs the executable into a .app
> bundle (on Linux this step is skipped).

Ah, I see. This means I'll have to rework my working version as it's fairly
Python-specific now :-(

> > - I would not let people specify a nib by path, but by name,
> > defaulting to "MainMenu". The .lproj or individual nibs should then
> > be listed as a resource.
> 
> Why? If there is a good reason to disallow full pathnames: fine with
> me, but I don't immediately see why this would be so.

But you don't do anything with the pathname but get the base name, strip the
extension and use it as the NSMainNibFile Info.plist key, right? Why not just
write "MainMenu" and be done with it?

> > - I think it's good if it (by default) would build the app in a
> > build/ subdir, like distutils and PB.
> 
> I've been working to the analogy of BuildApplet, but I'm not
> particularly married to that.

BuildApplet is great for very simple things, and worked fine on OS9 where
everything you needed could live in <scriptname>.rsrc. But I don't think this
approach is all that useful for .app bundles but for the simplest of scripts.
Then again: BuildApplet-like functionality could easily be built on top of this.

> > - Change it to use the os.execve() trick.
> 
> Definitely, but as an option.

Ok, I'll have to work on that.

> The only thing I'm not sure about is
> whether the execve code should be in-line in a string (as in your
> version) or external on sys.path (as buildtools.py currently does).

My working code currently needs to munge the wrapper even more: I need to
specify the Python executable in case it's copied to Contents/Resources/. 
It's a tiny amount of code and works for me just fine as a triple-quoted string.
[Reading this back: I need to do even more if we need to set PYTHONHOME
conditionally.]

> > - Add modulefinder support, like we discussed by telepathy... The
> > full version would also copy the Python executable to
> > Contents/Resources/. Not sure what to do about a Framework python,
> > though. Not sure I even care about that anymore: it only seems to
> > make thing harder here. What do you think?
> 
> I think the framework python is still my preferred option, and I hope
> we can get Apple to adopt it at some point in the future. but for the
> time being I want to keep both working.

Ok, but I'll need your help then... The code will have to become a _lot_ more
complicated if I need to support Framework Python: instead of just throwing the
python executable and all needed modules (.py[c] & .so) into Contents/Resources/
I'll have to copy a _subset_ of Python.framework to the bundle. And somehow we
need to tell the main executable to look for the Framework in the bundle (or has
this become more transparent now?). Things are so fantastically simple with a
unix install that I'm not really all that sure what Python.framework was
supposed to buy us in the first place :-(.

> As to modulefinder support: I think we need to think architecture 
> first. We now have a number of modules and scripts that do things that 
> are vaguely similar conceptually, but very different in implementation:
> - buildtools can build MacPython-OS9 applets.
> - buildtools can build MacPython-OSX applets.
> - buildtools can help with building MacPython-OS9 applications.
> - BuildApplication uses buildtools and selected bits of freeze to build 
> applications for MacPython-OS9.
> - buildappbundle can build general .app bundles.
> - your tool can build .app bundles specific for Python applets.

Hm, I would _love_ to just leave that old cruft alone, and start from scratch
with something maintainable. The old stuff works, I would rather not let the old
stuff be a burden to get the new stuff going.

The stuff I would _especially_ like to avoid is the Mac-specific main, with
__main__/__rawmain__ magic. I want to use the vanilla unix main, or rather the
vanilla unix _executable_. Trivial with the execve template.

[ ... ]

> > - A strip binaries option. Hm, evil? Could save a huge amount of
> > disk space, though.
> 
> Good idea. But: is "strip" available if you don't have the dev tools
> installed?

Dunno, but we can skip that option then...

> > Question: is it possible to completely override sys.path for a
> > statically built Unix Python? $PYTHONPATH merely prepends sys.path.
> > Would be nice to completely control it for a standalone app bundle.
> 
> You could create lib/python2.2 and lib/python2.2/lib-dynload under
> Resources, and then set PYTHONHOME to Resources.

Ah, PYTHONHOME of course.

> Hmm, this could be an interesting way to distinguish applets and
> fully self-contained applications: if there is a lib/python2.2 and
> lib/python2.2/lib-dynload then we set PYTHONHOME. We could then copy
> /usr/bin/python to the MacOS directory too, and use that to run the 
> standalone application.

Not sure if I follow you...

> For static python this is good enough. For framework python more
> magic is needed.

Operative words: "more magic". Do we _really_ want to go there?

Just