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. 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). > 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. >>> 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?". 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. Nick Matsakis _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
