[Python-Dev] setuptools in 2.5. (original) (raw)

Paul Moore p.f.moore at gmail.com
Fri Apr 21 00:49:05 CEST 2006

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.

More information about the Python-Dev mailing list