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