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
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
