[Pythonmac-SIG] Why Do I Explicitly Need MacPython

[Bob Ippolito]

On 10/3/06, Christopher Barker <Chris.Barker at noaa.gov> wrote:
> Charles Hartman wrote:
> > Bob Ippolito said:
> >> Users currently need some familiarity with Terminal in order to get
> >> anything done with Python anyway.
>
> > But hasn't there been real progress toward making that not true? And
> >  isn't that a good thing? Can't Python be an OSX programming
> > enrivonment rather than (as well as) a Darwin one?
>
> Exactly. Heck, for lots of packages:
>
> $ sudo python setup.py install
>
> works fine too, but I still think it's worth building mpkgs of those.

The big difference is that easy_install goes ahead and downloads the
latest version for you in the same step. No download and unpacking.
You can even point it at the URL of a tarball and it will do this for
you...

> It seems to me that that the community on this list has shared the goal
> of making Python on OS-X as easy to use and "mac-like" as possible.
> That's why we have the repository of binary packages on pythonmac.org.
>
> So far, it appears the easiest way to make a package easy to install for
> a mac user is to make a *.mpgk of it. In fact, I've advocated for years
> that the best way to make python accessible on all platforms if to have
> packages in a "native" format -- that means rpms on rpm based linux
> systems, MS installers for windows, and mpkgs for the Mac.

No argument about this currently being the easiest way.

The problem with native packages is that there is no good way to make
a database with dependencies and have packages automatically get
installed. This prevents Python developers from making or using small
libraries, instead they want to throw everything in one package so
that the dependency tree is very small. That is bad for Python.
setuptools + Cheese Shop fixes this problem.

> However, Apple has not provided us with a full-featured package
> management system. So we are faced with either kludging around its
> limitations, or using something else as the default way to distribute
> packages for OS-X. Right now, setuptools is really the only other option.

Even if they did we'd still be going the setuptools route, but perhaps
easy_install would use the package management system in the process.

> In fact, at this point, there is at least one important package that
> isn't available as a *.mpkg (Py2App). People need to install the Python
> package, then go find an easy-install script somewhere, install it, then
> use it to install py2app. This really isn't a huge deal, but it is too
> much for the "casual mac user" -- it took me a little poking around to
> figure out, which is way too much for anyone that is new to python and
> the whole command line thing.
>
> Shouldn't there at least be a package for easy-install itself?

Probably, but it's not totally trivial to build a correct one, so I
don't. I don't have the need or time to look into it. You only have to
install it once, then you can "easy_install -U setuptools" to upgrade
whenever necessary.

> Ronald Oussoren wrote:
> > I'm rather happy with setuptools, there are some cosmetic problems
> > (like the header-file thingy), but the core seems pretty well thought
> > out.
>
> > This features is apparently also on the list for the 0.7 release (but
> > not yet implemented).
>
> Which reinforces that setuptools is a good option to pursue.
>
> > I'm -0 on this. Easy-install is very convenient and I wish it were part
> > of Python 2.5 but it isn't. MacPython is at this point in time "just"
> > the official binary distribution of the python.org tree.
> >
> > Growing it beyond that (that is include third party libraries and tools)
> > could be useful, but even then I'd be more inclined towards adding
> > useful GUI tools than libraries.
>
> Which is what I'm talking about. I don't agree that "MacPython is at
> this point in time "just" the official binary distribution of the
> python.org tree". I've certainly got the impression that the goal is to
> make Python work smoothly and "natively" on the Mac. I suppose the only
> real additions are the pythonw (now called python) front end and a
> little tweaking of shell start-up scripts, but those are important.

MacPython is exactly what's in the Python svn tree and nothing more
(beyond dependencies). That's all Ronald is saying. There is 0 lines
of code that doesn't live at svn.python.org.

> Maybe installing setuptools by default is the thin end of the wedge, but
> I think it's critical that we do have a standard and easy way for people
> to install packages.
>
> setuptools is still a bit of a mystery to me, but I'm still confused as
> to why it is more than trivial to make a small gui that will:
>
> Pop up a dialog when you click on a *.egg, with a message like:
>
> Would you like to install the python package: blah-blah-blah:
> [install] [cancel]
>
> if [install] is clicked, it would ask for the admin password, then
> install the package.
>
> If dependencies are required, it would pop up another dialog:
>
> The following other packages are required to install this one. Would you
> like these to be auto-downloaded for you, or would you like to download
> and install them by hand?
> [auto-download] [I'll do it]
>
> Thats it. I think setuptools provides that functionality at this point.
> Am I wrong?

setuptools provides this functionality, but the starting point is
typically the name of a package not an egg file. So the GUI app would
also have to provide a Cheese Shop browser.

> Key is that there is a default way to download an egg, click on it,
> select all the defaults in a series of dialogs, and get your package
> installed.

The series of dialogs is what makes the GUI difficult. easy_install is
not currently built in a way that makes all of those hooks available.
It doesn't have dialogs at the console level at all, just output.

You'd either have to duplicate or rewrite a large chunk of what
easy_install does to get it to do GUI stuff. It's just too much work
for too little gain at this point, especially when setuptools is a
moving target. You'd really have to care a whole hell of a lot and be
willing to put a lot of effort and coordination into the task. I
definitely don't, because I wouldn't use it even if it existed. Using
easy_install from the console is always going to be faster and easier
for anyone who is at all comfortable with typing "sudo easy_install
SomePackage" and pressing return.

-bob