Re: [Pyobjc-dev] buildapplication strawman

[Jack J. <Jac...@cw...>]

On Tuesday, Nov 19, 2002, at 15:15 Europe/Amsterdam, Just van Rossum 
wrote:
>>> - 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?

Yes, it's added to the resources. Ah, I now see your "The .lproj or 
individual nibs
should then be listed as a resource" sentence. So you want the user to 
pass the main nib
twice, once as a file and once as a name. Hmm, yes, with nibs in 
.lprojs I can see the
point. Ok, fine with me, but you should probably add a check that the 
main nib actually
exists.

>>> - 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.

But don't forget that there are many "very simple things". About 100% 
of the
scripts ported over from unix, for instance. But as I said: if you're 
writing the
code you decide how to do it.

>> 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.]

Could be done dynamically:
     bindir = os.path.split(argv[0])[0]
     if os.path.exists(os.path.join(bindir, "python")):
         We are a self-contained application, set PYTHONHOME and use 
this python
     else:
         We are an applet. Set PYTHONPATH and use /usr/bin/python

>> 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 :-(.

Don't worry about this for the moment. BuildApplication doesn't work 
for framework python right now, so there's nothing you can break. I 
have some ideas on how to do this, but there's lots of time before 
2.3b1.

>> 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.

There's definitely something to be said for this. [think.... think...]
Ok, make it so.
>
> 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.

But unfortunately the __rawmain__ trick is needed for one of the most 
useful
applications of an applet: taking a standard unix Python script and 
turning it into
a droplet.

This is the one use of applets I can see end-users (as opposed to 
developers) making.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -