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

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.

Paul.

More information about the Python-Dev mailing list