Philipp von Weitershausen wrote:
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 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.



Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to