Re: [Chicken-users] Eggology

[Will M Farr]

For an interesting perspective on this issue (which could probably be  
incorporated by minor changes in the egg system), you guys might have  
a look at PLT's PLaneT server.  You can find a design paper at

http://scheme2006.cs.uchicago.edu/04-matthews.pdf

and, of course, the PLaneT repository at

http://planet.plt-scheme.org/

I think it's quite a nice system, and it's solved a lot of the  
problems discussed in this thread already, so it's probably worth  
stealing from....

Will

On Aug 23, 2007, at 3:13 PM, Peter Keller wrote:

> Hello,
>
> On Thu, Aug 23, 2007 at 02:00:07AM +0200, felix winkelmann wrote:
> > tool -> srfi-37, args-doc
> > args-doc -> srfi-37, srfi-95
> > srfi-95 -> array-lib
> > array-lib -> srfi-42, miscmacros, misc-extn
> > srfi-42 -> syntax-case
> >
> > This is insane.
>
> It might be insane, but I don't know how you are going to get around
> it. What you have here is what amounts to a linking problem. Of  
> course if
> people change function signatures out from under you, things will  
> break. :)
>
> If you want to comprehend it, then I think a few things are needed:
>
> 1. Each egg gets a specific revision number which is sortable  
> amongst others.
> 2. You could query the egg repository with these questions:
> 	What is the full dependancy graph from this egg on down to the  
> leaves?
>         What is the dependancy graph from this egg to all roots?
>         Who is specifying hard version dependencies?
> 3. When you declare an egg, you give it a revision number.
> 4. When an egg requires other eggs, it either requires a specific
>         revision, or the "latest" available revision--the default.
> 5. When you install an egg, you can either get the "latest"  
> revision or
> 	some other revision. Since all actual codes specify what revisions  
> they
>         actually want, you only get what you need.
>
> The only problem arises when you have two eggs wanting different  
> revisions
> of the same dependant egg. Only a clever namespace&module thingy is
> going to fix that. One can look to Java for a reasonable  
> implementation.
> Sadly, though, this simply WILL happen, and sooner than one would  
> like.
>
> But, my real point is that you can only truly figure this stuff out if
> versions and dependancies becomes a real first class object in the  
> eggs
> themselves and in the repository. Then tools can be written to just do
> all of this stuff for you, much like a linker, and automatically  
> generated
> web pages could document the dependancy trees so people know what  
> is easy
> to replace, or what will be harder to replace depending upon its  
> context.
>
> > From my understanding, much of this stuff already exists.
>
> -pete
>
>
>
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/chicken-users