Hi there,
I've been doing some more thinking about external version indexes (like
Grok's versions.cfg on a URL, and like KGS) and why they won't solve all
our problems. I have a new way to express it, so let me try it out on
you all.
What KGS solves is that it allows the ongoing development and testing of
an integrated Zope 3. That is, there's a Zope 3 'trunk' of versions
that keeps being updated as there are bugfix releases. I'm not sure what
happens as soon as someone wants to make a new feature release of any
package. Presumably they end up in KGS too. After all, we won't have a
single Zope 3.4 and then a single Zope 3.5 for which we can create a new
KGS. We intend to let packages move at different feature-release speeds,
and we can't have a KGS for each package.
Another problem KGS can solve is to add some release hygiene to the
cheeseshop: do not remove old releases or overwrite them.
What KGS doesn't have is history. When I release an application or
framework and I used KGS to make sure that all my versions were correct,
it will work on the day of release. As soon as enough bugfix (or
feature) releases make it to KGS, something will inevitably break. We've
seen innocuous changes breaking code a lot of times, so we can't pretend
that never happens. It *will* happen.
This breaks a fundamental assumption for releases. When I release
something, I expect it to work tomorrow, next month, and next year.
With code, we know that history, and branches, and so on, are important.
We use Subversion. With KGS we only have an ongoing trunk.
With Grok, we use an external versions list. We can use this to solve
the above problem. We basically take snapshots of what is in KGS. This
allows us to maintain some history, though it isn't ideal either, as
it's quite a bit of overhead.
If I build an application or framework on top of Grok, I will need to
maintain yet another external list for the extra packages of this
application, fixing those versions. We could probably even use the
extends feature of buildout to have this list point at Grok's list so we
have to repeat ourselves less should we want to build something on top
of *that* application or framework again.
So, while annoying, that is somewhat manageable. Now imagine I want to
use a completely separate Python library with my Grok application. This
python library has dependencies itself again. This means I will need to
know about versions of those dependencies as well, and fix them into my
application's list.
There are some fundamental problems with external lists or indexes:
* we need to know about the dependency of dependencies, even if we never
use them directly. Information hiding is broken.
* a single list will never do it. We intend to have many different
applications that may depend on different versions of packages. Grok may
need a newer zope.publication than your application does. A Grok
extension may need an even newer version than Grok does. We'll be baking
endless amounts of lists this way.
If this information is inside the packages itself, the history will be
automatically maintained with Subversion and existing releases. History
therefore works: if I install Grok 0.11, I would get all dependencies of
Grok 0.11 automatically without having to worry about external indexes.
Information hiding works: if I use foo 1.3 and foo 1.3 knows it needs
bar 1.7, it'll simply get that and I don't have to know about it. I
don't even need to worry about the *existence* of bar.
People have been saying that since Linux distributions use external
indexes, we should too, as we are dealing with the same problem as Linux
distributions. While the problem is similar, I think the nature of
development makes our problems, and therefore our solutions, quite
different from the way distributions do it.
How are we different?
We have many, many different small distributions (package +
dependencies) that can be combined. We have such a small distribution
for each application. We have such a small distribution for each
extension. Not just that. We have such a small distribution for each
*release* of an application. We have such a small distribution for each
*release* of an extension.
I therefore still believe that version dependency information should
move out of external indexes and into packages.
See also my earlier discussion of these problems and possible solutions:
http://faassen.n--tree.net/blog/view/weblog/2007/09/26/0
Regards,
Martijn
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
