On Fri, Dec 17, 2010 at 11:15 AM, Alan Franzoni <[email protected]> wrote: > On Fri, Dec 17, 2010 at 5:01 PM, Benji York <[email protected]> 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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
