[Pythonmac-SIG] best way to install packages?

[Bob Ippolito]

On Feb 3, 2006, at 9:59 AM, Christopher Barker wrote:

> Andrew Jaffe wrote:
>> Anyway, is there a 'best' way to install python packages on a
>> mac nowadays? It seems that there at least three possibilities:
>>
>>    - plain old setup.py install
>>    - bdist_mpkg
>>    - eggs (in which case I realize I'm not sure I know exactly  
>> *how* to
>> do this)
>
> The "Best" way to install packages is to use whatever form you get. If
> you get an egg, use easy-install, if you get a mpkg, point and  
> click it,
> if you the source, use setup.py.

easy_install will also download, compile, and install (as an egg)  
many source distributions for you, whether or not it's an egg.  If  
the package happens to use setuptools, it'll also find download,  
compile, and install any dependencies it needs.

This of course isn't so easy for a very select few packages (Twisted  
and Zope.Interface in my experience so far), and it's not as useful  
for packages that are not yet registered on Cheese Shop (PyPI)

> I'm not just being glib here. I wonder if you, in fact, are asking a
> larger question, which it would be nice to discuss here:
>
> What is the best way to distribute packages? Now you have to consider
> the three options above:
>
> 1) Just distribute the source with a setup.py

You're always doing this anyway, whether or not you use setuptools or  
if you provide binary packages of some kind (egg, mpkg, etc.).

> 2) Use bdist_mpkg to build a mpkg

This makes sense if you have to install other junk that doesn't live  
in site-packages (other than scripts), like examples, documentation,  
etc.  For packages that have big dependency graphs, bdist_mpkg can be  
a chore because you have to instruct your users to install a bunch of  
other junk first (e.g. pygame users should also be downloading and  
installing four or five other packages).

> 3) Build an egg.
>
> The reason I make this distinction is that if you are getting just the
> source from a package maintainer, there is little reason to go though
> the trouble of making mpkgs or eggs, if you only want to install it on
> your own machine. slight modification to that:

Building eggs and uploading them to Cheese Shop is absolutely  
trivial.  Do it.

> The is no reason to make a mpkg.
>
> You might want to make an egg, so that you can get the versioning
> control eggs give you (and some other features, but versioning control
> is the big one) However, if it's just for your purposes, and the  
> package
> maintainer hasn't set up setup.py to build and egg, it's probably not
> worth it.

Is this hard?

python -c "import setuptools; execfile('setup.py')" bdist_egg

> That being said, I would love it if EVERYONE that downloads and  
> builds a
> source package on their Mac would contribute a binary package to the
> community. Mac users like binary packages!
>
> I suggest the following for making a package that can be distributed:
>
> - Make an egg.
> - If you can't figure out how to make an egg, use bdist_mpkg
> - I think Bob is working on making py2app support eggs with  
> bdist_mpkg,
> so that may get easy.

The next version(s) of py2app, bdist_mpkg, etc. are going to be  
separate software packages.  setuptools makes this reasonable to do.   
I'm not going to release any updates to any of that suite until they  
are usable with eggs.

> However, keep in mind that when you make a binary package, it will  
> only
> work (reliably) with the version of Python that you build it with. I
> think the versions we should support are:
>
> Bob's "official unofficial" 2.4.1 framework build for 10.3 (this will
> run on 10.4 also)
>
> 2.4.1 framework build for 10.4

Note that ActivePython 2.4.2 is equivalent to the 2.4.1 framework  
build for 10.3.  The only difference is that ActivePython doesn't  
ship with a working bsddb or readline (bzip2 and curses may also be  
broken with older builds of ActivePython 2.4.2).

There will soon be a Python 2.4.2 (really more like 2.4.3, since it  
has many significant patches) build for Mac OS X that is fat (i386  
ppc).  Ronald and I are working out the issues with that.  It is very  
difficult to have two different Python 2.4 installations at the same  
time though, but Ronald says he has some patches that allow the 10.4  
build to run on 10.3.9, so maybe that's Good Enough to be the one and  
only distro to support.

> There's something to be said for supporting Apple's pythons but I  
> think
> that's lower priority.

Don't bother, especially not if you care about i386.  Python 2.3 is  
on its way out, and Mac OS X 10.5 is on its way in.. I'd expect that  
Mac OS X 10.5 will include Python 2.4.3 (or 2.4.2+all of our  
universal build patches) anyway.

Supporting Apple's Python is a losing battle because you lose both  
backwards and forwards compatibility.  Backwards compatibility is  
gone or at least prohibitively difficult because they're always going  
to build with the latest MACOSX_DEPLOYMENT_TARGET and forwards  
compatibility is fragile at best because they can change the Python  
minor (minor as in 2.X) version at any major OS upgrade and break  
anything that you have done.  They also have a habit of doing a  
crummy job of testing it and they never upgrade except during major  
OS upgrades.

> And these packages should be put up on pythonmac.org
>
> One other note:
>
> The Framework builds put the "bin" directory inside the Framework.
> That's where scripts get installed by default. What that means is that
> in order to use them, the user needs to add that directory to their
> PATH. This isn't a big deal, but it reminds me too much of the old DOS
> days, where you needed to add something to your PATH for every darn
> piece of software you installed. I much prefer the *nix standard of
> having a few locations where executables get installed, and I's  
> like to
> see the default scripts directory be /use/local/bin.
>
> Should this be the standard? How could we accomplish that? Or  
> should we
> just tell people to add the Framework bin directory to their PATH.

Personally I have a ~/.pydistutils.cfg that looks like this:

[install]
install_lib = ~/Library/Python/$py_version_short/site-packages
install_scripts = ~/bin/py$py_version_short

and of course ~/bin/py2.4 is in my PATH.

Some people might prefer an install_scripts = /usr/local/bin -- but  
then they'll need sudo to install stuff.  bdist_mpkg chooses /usr/ 
local/bin as the default, since the "sudo" is provided easily by  
Installer.app's authorization facility.

-bob