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
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users