[Distutils] specifying dependencies
chris at simplistix.co.uk
Fri Oct 10 17:13:39 CEST 2008
Ian Bicking wrote:
> Chris Withers wrote:
>> Ian Bicking wrote:
>>> Say I have a package that represents an application. We'll call it
>>> FooBlog. I release version 1.0. It uses the Turplango web framework
>>> (1.5 at the time of release) and the Storchalmy ORM (0.4), and
>>> Turplango uses HardJSON (1.2.1).
>>> I want my version 1.0 to keep working. So, I figure I'll add the
>> I would have suggested:
> Then when Turplango 1.6 comes out it'll break my code.
I'm assuming that you, as a consumer of Turplango, understand the
versioning structure of Turplango. Based on the above, my model assumed
that <2.0 would be api-compatible with 1.x. If that's not the case,
adjust the dependencies as necessary.
>> Not could, should, in fact must. Relying on a dependency provided by
>> library you're using is suicide.
>> Again, I'd suggest:
>> HardJSON >=1.2.1,<1.3
> What does 1.3 mean? You imply there is a disciplined use of a
> versioning pattern,
I think for each usable library, there *is* a versioning pattern. If
it's extremely unstable, that *should* push users away from the library.
> and that every release is a guarantee that the
> versioning has been properly declared.
This comes under stability. Shit software is shit software whether its
because it contains tonnes of bugs or because it doesn't specify its
> There isn't a common
> understanding of versions,
...within a project, there generally is, which is all that's required here.
> and it's common that conflicts are released
Well, if people have drummed into them how important accurate version
dependencies are, then this won't happen...
>>> But then a small bug fix, HardJSON 1.2.2 comes out, that fixes a
>>> security bug. Turplango releases version 1.5.1 that requires
>>> HardJSON>=1.2.2. I now have have to update FooBlog to require both
>>> Turplango==1.5.1 and HardJSON==1.2.2.
>> Not if you'd followed my advice above.
> OK, change that to "a small bug fix comes out as HardJSON 1.3", and the
> same problems follow. I don't know what the nature of future releases
> will be.
See previous comments on the versioning structure used by a library.
>>> Later on, I decide that Turplango 1.6 fixes some important bugs, and
>>> I want to try it with my app. I can install Turplango 1.6, but I
>>> can't start my app because I'll get a version conflict.
>> Not if you'd followed my advice above.
> Now you've introduced an entirely different requirement -- for some
> reason I am supposed to have known that HardJSON 1.3 would break my
> code, but only Turplango 2.0 would cause a conflict. And Turplango 1.6
You're trying to make something out of nothing here. If the version
dependencies are specified in setup.py or some kind of KGS they still
have to be specified correctly. If they are not, you're screwed...
>>> But if I've made other hard requirements of packages like HardJSON,
>>> I'll have to update all those too.
>> Yes, that's true, and why I recommeded what I did. That said, if
>> you're paranoid enough to specify the exact versions (there's nothing
>> wrong with this ;-) ) then it should be no surprise that you need to
>> edit them...
> It's not surprising, it's just very annoying.
Well then, only use libraries which properly specify their version
dependencies and fix those that don't and you have no problem or annoyance.
>> Or likely sources of known conflicts, such as major version increases,
>> which is why I suggested what I did above...
> You presume you can predict likely sources of known conflicts in
> software that doesn't exist yet. This is simply not true.
Indeed, but I'm damned sure I can tell you what version ranges of
*existing* software should be api compatible.
>> Right, which is why consistency is version numbering for backwards
>> incompatible changes is important.
> There is no single concept of what backward compatibility even is.
There doesn't have to be one single concept, just that each library has
to have its own understanding of this so that consumers of that library
can express their requirements properly.
> You can off something that fixes my specific example, using knowledge
> that would not be available to you at the time when you were using the
> code. That doesn't really prove anything -- I could also come up with
> conflicts that would break any example you could provide. There's no
> version change so minor that it can't break anything, and there's no
> version change so major that you should end up with a cascading set of
> updates that only change dependency information just to accommodate it.
Well, if you want to be this negative about it, then you can lock down
versions. No-ones stopping you and current tools such as buildout
Personally, I just don't thinl it should be necessary...
Simplistix - Content Management, Zope & Python Consulting
More information about the Distutils-SIG