[Pythonmac-SIG] Appscript Installer 1.1a1

[Bob Ippolito]

On Jun 3, 2005, at 12:12 PM, Nick Matsakis wrote:

>
> On Thu, 2 Jun 2005, Bob Ippolito wrote:
>
>
>> An installer, as built by bdist_mpkg, won't install anything unless
>> Python is where it expects it to be.  Thus, it's not possible to
>> install into a framework that doesn't exist.
>
> Here's the experience that I was hoping for: User installs appscript
> binary installer once, and it works with built-in pythons on 10.3,  
> 10.4,
> and 10.3 upgraded to 10.4.  I was also thinking it might be nice if  
> Python
> 2.4.1 could be installed after appscript and it would "just work"  
> without
> any additional effort.
>
> It seems that the "right" way to do this would be to use Apple's
> TokenDefinitions to install relative to some python framework.  If you
> installed in the framework's site-packages, you would automatically  
> wind
> up in /Library/Python with the built-in frameworks due to the  
> symlinks and
> you could install into other framework builds as well.  However, if  
> you
> did it this way, then upgrading from 10.3 to 10.4 would break the  
> install
> because the site-packages destination changed.

That's why we have the TigerPython23Compat package, which puts a .pth  
file in the 10.4 path such that it will also look in the 10.3 path.   
Problem solved.

> I think this illustrates the fundamental problem with installing into
> existing frameworks---Appscript is not part of the python framework  
> and by
> installing in there you open yourself up to breakage when the  
> framework
> changes. This is true for both the built-in pythons and the ready- 
> built
> python 2.4.  From the Mac user's perspective appscript is basically a
> "plug in", a software resource that he doesn't deal with directly  
> but is
> necessary to run other software (such as scripts and workflows that  
> depend
> on it).  I think the mac way of dealing with plugins is to not  
> require an
> installer at all, but rather create a bundle with the software and  
> drag it
> into some Library folder (Library being the canonical place for  
> resources
> the user doesn't need to deal with directly).

Python extensions/packages don't and can't currently do things the  
Mac way, trying to shoehorn it into the Mac way before it's ready  
just causes unnecessary hassle for the developer and the user.  You  
should just do it the way that everyone else does things, consistency  
is good.

There are three situations you should be concerned with:
1. Python 2.3.0 on Mac OS X 10.3
2. Python 2.3.5 on Mac OS X 10.4
3. Python 2.4.x on either

1 and 2 can be dealt with by a single package, built on Mac OS X 10.3  
with bdist_mpkg installed for Python 2.3.0, so long as the user also  
has the TigerPython23Compat .pth file installed (which you can safely  
include in the package if you feel the need).  This package will  
almost certainly break on 10.5 and there's nothing you can do about  
that (since Python 2.3 will probably no longer ship).

3 can be dealt with by a single package, built on Mac OS X 10.3 with  
bdist_mpkg installed for Python 2.4.1.  This package will be forwards  
compatible to future micro-releases of Python 2.4 on any version of  
Mac OS X >= 10.3.

I can effectively guarantee that any Python 2.3.x packages are going  
to break on Mac OS X 10.5, so if you care about forwards  
compatibility then target the Python 2.4.x.  Since its third party,  
it will continue to work regardless of changes to the vendor Python.   
As you've noticed, vendor Python changes can break vendor Python  
packages.  That's just how it works, don't try and solve that  
problem, only Apple can do that (and I doubt they will).

>> Maybe I'm missing something.  Are you saying that you have an
>> installer that attempts to install an extension that's "compatible
>> with either Python 2.3 or Python 2.4"?
>>
>
> Well, yes, but not how you mean in.  I was hoping to install 2.3  
> and 2.4
> compatible binaries into /Library/Python/2.x/site-packages.  This is
> simple and more future-proof than the alternatives, as I see it.

Don't.  Keep 2.3 and 2.4 separate.

>>>> If you build the installer with py2app's bdist_mpkg, you don't
>>>> care about these details, because it does the right thing.
>>>>
>
>
>>> What do you mean?
>>>
>
>
>> <http://www.google.com/search?q=bdist_mpkg>
>>
>
> I know but bdist_mkpg is, you pointed me at it the last time we had  
> this
> discussion. I've choosen not to use it; While underwhelming,  
> PackageMaker
> is sufficient for my needs and I've found the difficult part of  
> building
> the installer isn't making the package but knowing what the "right  
> thing"
> is.  That was what I was asking about when I said  "what do you  
> mean?".

Choosing not to use it at all is the wrong decision.  The right thing  
is the behavior that bdist_mpkg has (effectively a serialized  
distutils install command), so you might as well just use it.  It's  
easier than building it by hand anyway.  If you still want to use  
Installer to build a package that installs other stuff too, go ahead,  
just build a mpkg that references what you've built with bdist_mpkg.

> For the purposes of this installer, it's easy enough to make it work.
> The reason I'm asking these questions is because I'm not what the  
> story is
> for third-party python additions on the Mac.  It appears that  
> bdist_mkpg
> is the closest thing we've got, but I can't find any documentation  
> on it.

Easy enough to do wrong, too.  As far as documentation goes,  
bdist_mpkg has documentation on the first google hit!

-bob