[Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)

Paul Moore p.f.moore at gmail.com
Tue Oct 20 22:49:42 CEST 2009

2009/10/20 Chris Withers <chris at simplistix.co.uk>:
> I wouldn't have a problem if integrating with the windows package manager
> was an optional extra, but I think it's one of many types of package
> management that need to be worried about, so might be easier to get the
> others working and let anyone who wants anything beyond a pure-python
> packaging system that works across platforms, regardless of whether binary
> extensions are needed, do the work themselves...

There are many (I believe) Windows users for whom bdist_wininst is
just what they want. For those people, where's the incentive to switch
in what you propose? You're not providing the features they currently
have, and frankly "do the work yourself" is no answer (not everyone
can, often for entirely legitimate reasons).

If such users could ignore the new offering, that would be fine - but
they can't, if projects stop providing bdist_wininst installers.
That's what's happening with eggs already, and yes, it *is* a pain.
And I'm in a position where I *can* build my own bdist_wininst
installer - but often, I'll just not bother using a package. So
packages lose users - does this matter? Who can tell?

In my view, the number one priority is to have a single distribution
format. I really don't care what it is. But *one*. bdist_wininst used
to be that on Windows, and for all its limitations it was a huge
benefit. Eggs messed that up, essentially because they didn't provide
all the features of bdist_wininst (uninstallers...) so they didn't
replace bdist_wininst, they sat alongside. Now you're proposing to
make the same mistake again.

Can I repeat that in big letters? The key is a SINGLE DISTRIBUTION FORMAT.

If you can persuade everyone to accept a format which ignores clearly
stated user requirements, go for it. But if you can't, you're making
the problem worse rather than helping. My money's on a solution that
acknowledges and addresses user requirements instead.


More information about the Python-Dev mailing list