[Distutils] specifying dependencies

[Ian Bicking]

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 
>> dependencies:
>>
>>   Turplango==1.5
>>   Storchalmy==0.4
> 
> Why?
> 
> I would have suggested:
> 
> Turplango>=1.5,<2.0
> Storchalmy==>=0.4,<0.5

Then when Turplango 1.6 comes out it'll break my code.

>> Then HardJSON 2.0 is released, and Turplango only required 
>> HardJSON>=1.2, so new installations start installing HardJSON 2.0.  
>> But my app happens not to be compatible with that library, and so it's 
>> broken.
> 
>  >  OK... so, I could add HardJSON==1.2.1 in my requirements.
> 
> 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, and that every release is a guarantee that the 
versioning has been properly declared.  There isn't a common 
understanding of versions, and it's common that conflicts are released 
unintentionally.

>> 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.

>> 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 
wouldn't

>> So to even experiment with a new version of the app, I have to check 
>> out FooBlog, update setup.py, reinstall (setup.py develop) the 
>> package, and then I can start using it.  
> 
> Right, you're developing FooBlog by changing the software it uses, so it 
> seems natural enough to have to edit FooBlog code. You don't have to 
> check those edits into your SCM ;-)
> 
>> 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.

>> more than 3 libraries involved.  I now think it is best to only use 
>> version requirements to express known conflicts. 
> 
> 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.

>> For future versions of packages you can't really know if they will 
>> cause conflicts until they are released.
> 
> 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.

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.


-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org