Philipp von Weitershausen wrote:
[snip]
So you're telling me that in order to define my own KGS (which anybody
should do for a serious project), I'll have to start deploying my own
index. For each project?
I think Grok should be using KGS by simply taking snapshots of it
sometimes and then building an own list of absolutely fixed versions
from it.
There are a lot of problems not solved yet concerning fixing versions in
any solution I've seen so far. Grok can fix a single list right now, but
what if we release megrok.genshi which relies on a particular version of
Genshi? If you are using that in your application, you'll have to add it
and all its dependencies to buildout.cfg manually, *or* megrok.genshi
will have to release its own versions.cfg somewhere on some website that
we then also ask people to extend. Anyway, all this requires quite a bit
of overhead and typing.
If we relied on KGS, we could release a fixed version of megrok.genshi,
but what to do when it needs an update? We don't want to force all users
to update - this needs to be under the application developer's control.
KGS is good for integration tests and developing against, but I don't
see it as a good solution for releasing against.
I'm still convinced the real solution involves storing fixed version
number requirements where they belong: in the packages themselves (with
an 'or' story in setup.py). This isn't perfect either, as the packages
may disappear from the cheeseshop, so a separate index like KGS would be
desirable in combination with this approach.
I want a solution where someone can say: "I want to rely on foo 0.7",
and then it'll get that and a fixed version of all its dependencies
(unless it's explicitly overridden). I want people to be able to say
this with a minimal amount of work (no need to set up and maintain your
own index) and no risk at all that later on suddenly you'll be getting
different versions. Not even bugfixes.
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 )
