Ian Bicking wrote:
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.
I'm assuming that you, as a consumer of Turplango, understand the
versioning structure of Turplango. Based on the above, my model assumed
that <2.0 would be api-compatible with 1.x. If that's not the case,
adjust the dependencies as necessary.
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,
I think for each usable library, there *is* a versioning pattern. If
it's extremely unstable, that *should* push users away from the library.
and that every release is a guarantee that the
versioning has been properly declared.
This comes under stability. Shit software is shit software whether its
because it contains tonnes of bugs or because it doesn't specify its
dependencies properly.
There isn't a common
understanding of versions,
...within a project, there generally is, which is all that's required here.
and it's common that conflicts are released
unintentionally.
Well, if people have drummed into them how important accurate version
dependencies are, then this won't happen...
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.
See previous comments on the versioning structure used by a library.
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
You're trying to make something out of nothing here. If the version
dependencies are specified in setup.py or some kind of KGS they still
have to be specified correctly. If they are not, you're screwed...
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.
Well then, only use libraries which properly specify their version
dependencies and fix those that don't and you have no problem or annoyance.
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.
Indeed, but I'm damned sure I can tell you what version ranges of
*existing* software should be api compatible.
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.
There doesn't have to be one single concept, just that each library has
to have its own understanding of this so that consumers of that library
can express their requirements properly.
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.
Well, if you want to be this negative about it, then you can lock down
versions. No-ones stopping you and current tools such as buildout
support this.
Personally, I just don't thinl it should be necessary...
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
