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@colorstudy.com : http://blog.ianbicking.org