[Distutils] specifying dependencies

[Chris Withers]

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

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

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

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

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

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

Myself, I stick pretty rigidly to:

x.y.z:

z = no api change

y = new apis added

x = old apis changed or removed

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk