[Distutils] Buildout or distribute raise unnecessary version conflict?

Benji York benji at benjiyork.com
Fri Dec 17 17:54:14 CET 2010

On Fri, Dec 17, 2010 at 11:15 AM, Alan Franzoni <mailing at franzoni.eu> wrote:
> On Fri, Dec 17, 2010 at 5:01 PM, Benji York <benji at benjiyork.com> wrote:
>> Fancier version resolution would be nice, however a library-like package
>> (as opposed to an app) that requires one and only one version of a
>> dependency is being antisocial.
> Of course a version range is preferred, but whether it's a library or
> an app, if I depend on a certain version might be a matter of
> functionality. I think I've found many python packages and libraries
> that don't work anymore simply because an upstream dep has changed.
> I mean, if don't get a version conflict but then the app or lib does
> not work, it's not a great win, don't you think so?

Agreed.  The opposite is a problem as well: one dependency requires an
older version and another needing a newer one conflict even though the
newer version would have worked just fine.

Unfortunately, the only practical thing to do at the moment is for
library authors to set a minimum version when they know their package
absolutely will not work with older versions and do their best with
testing/documenting other version requirements.

Library users then have to manage their versions as best they see fit.
Some, like me, are maniacal about maintaining strict control on
versions (zc.buildout's "allow-picked-versions = false" is for these
people).  Others don't like having to manage all that and are happy to
let their dependency versions "float" -- of course they then have the
go-away-and-come-back-six-months-later-and-your-app-is-broken problem
you mentioned earlier.

Until something changes, it's a "choose your poison" situation.
Benji York

More information about the Distutils-SIG mailing list