[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: coming back to packaging multiple versions of libraries



On Thu, Jan 6, 2011 at 12:39 PM, Barry Warsaw <barry@python.org> wrote:
> These are not necessarily mutually exclusive. ;) #3 and #4 are both worth
> pursuing in any case, but kind of outside the domain of either upstream
> (except were the stdlib is concerned) or debian-python.  Still, as a Python
> programmer, if you find gratuitous API breaks in packages you care about, it's
> worth a bug report.
>
> (I'm still not quite sure why Robert doesn't just get the wadllib developers
> to fix their API breakage?)

wadllib was an example. I'm aware of -very- few libraries that never
change things; what constitutes an API break is vaguely defined; the
functional definition we need here is 'when consuming code is broken
by upgrading the dependency' : that definition is much wider than
'something we advertised is no longer supported' which many upstream
follow.

> I really hate having the version numbers in the module names, and actually in
> package names too, but the latter tend to disappear after transitional
> periods.  Names like urllib2 live forever unfortunately.  I don't have any
> great ideas about how to improve that though.

having the language support N versions of urllib installed at once
seems to work very well for C, C++, C#, Java and other languages.
Perhaps Python should just do that.

> I agree with Piotr, I think trying to do this in a hidden way is fraught with
> problems and lots of unanswered questions.  I will mention that for years
> Mailman shipped with its own version of the email package because it needed an
> exact API that might have been different than the default one, depending on
> the version of Python you were using.  So a specific application that cares
> deeply about its library versions I think has no better choice than to do
> something like that, which is essentially your #2.  There can be more
> principled ways of doing that, e.g. with buildout or virtualenv, but it boils
> down to the same thing.  There's just no good distro-way of doing that
> though.

I'm not trying to do this in a hidden way though? Why do you think
that that is the case?

-Rob


Reply to: