[Python-Dev] setuptools in 2.5.

[Paul Moore]

On 4/20/06, M.-A. Lemburg <mal at egenix.com> wrote:
> I wonder why people always seem to imply that installing
> packages has never worked before there was setuptools.
>
> There's really nothing wrong with the standard distutils
> two step process:
>
> 1. download and unzip the source file
>
> 2. run "python setup.py install"

[I'm very reluctant to join in this discussion, as (a) I have no
packaging experience (being a pure "user" of other people's packages,
and (b) I have no personal need for the fancy features in setuptools.
Apologies in advance, therefore, if I misrepresent anything.]

As a Windows user, I generally have 2 problems with this process.

1. There's no uninstall.
2. There is no list of what is installed.

(Unless I manage these 2 manually, but that's always an option).

However, if I do "python setup.py bdist_wininst" all is rosy again.
The standard "Add/Remove Programs" listing becomes both my uninstaller
and my list of installed packages.

Initially, eggs were a problem for me, as they didn't conform to this
standard. This was, as I understand it, because the package layout
installed by distutils didn't include the metadata needed for the
setuptools features like version checking. So, packages which used
those features *couldn't* be distributed as bdist_wininst format.

However, Philip addressed this. The new format with a .egg-info
directory allows for egg metadata. This is automatically used in
commands like bdist_wininst under setuptools.

I'm left (I believe) with a couple of issues, though.

1. Only packages which import setuptools in their setup.py will
generate egg metadata. So, for example, PIL doesn't have egg metadata
by default.
2. Distributors will supply .egg files rather than bdist_wininst
installers (this is already happening).

(1) is an issue for packages which "require" specific versions of
other packages. For example, turbogears requires elementtree - but the
standard elementtree installer distributed by Fredrik doesn't include
egg metadata, so it "doesn't count". I either need to install the egg
as well (which doesn't go in Add/Remove Programs), or build my own
elementtree installer (not always easy, as C compilers aren't
available on every Windows box, for example).

(2) is an issue as it means I'll end up less likely to be able to get
"native" installers.

It's possible that (1) can be solved by making *all* distutils
installs create egg metadata. That may be what's meant by "integrating
setuptools functionality into distutils". If so, I'd support this.

I'm not sure how to solve (2). I have no interest in, or use for,
ez_setup. I prefer to manage my version issues manually, and I don't
like tools that automatically download stuff off the internet (no
matter how much it's an on-request only process). That's fine - it's
my choice. But if I become a minority, the demand for bdist_wininst
installers diminishes to the point that no-one produces them. And
*that's* a step backwards. A key benefit of distutils for me was that
a standard Windows binary installer format became common. I'd hate to
lose that. (And I don't feel that eggs are a comparable option -
unless a complete package management solution gets added).

Maybe a .egg -> .bdist_wininst converter is feasible. I don't know. If
so, that may be a way out.

> BTW: thanks to Greg Ward for creating distutils in the
> first place :-)

Agreed. And thanks to Philip for going the next step. But let's keep
working to ensure that in solving a new set of problems, setuptools
doesn't make things harder for people who never *had* that set of
problems...

Paul.