[Grok-dev] Re: AW: Re: Grok 0.11 released!

[Martijn Faassen]

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