Begin forwarded message:
From: "Damien Pollet" <damien.pollet@gmail.com> Date: November 11, 2008 10:35:49 PM CEST To: "Keith Hodges" <keith_hodges@yahoo.co.uk> Cc: "Stéphane Ducasse" <stephane.ducasse@inria.fr> Subject: Re: Sake, Packages, and deployment code
On Tue, Nov 11, 2008 at 2:13 AM, Keith Hodges <keith_hodges@yahoo.co.uk
wrote:
IMHO the root class should be packaged separately from its subclasses,
Also, part of the code is there to make the task-declaration DSL⦠it would be nice if the DSL layer was documented as such and separated from the implementation code. I guess SakeMeta separates it a bit already⦠maybe it would help me if I knew the implementation of rake, but I don't :)
tasks are generally named task* , in "bob" build methods are named build*.
ok. I'm not advocating for a particular prefix (maybe a short one like pkg is best indeed).
However I dont see the problem with not having "task" in this context. I would prefer pkg* or package* , but I felt it looked untidy.
Well, for one, it would be symmetrical with SUnit's test* methods. Then, I think it's better to keep the convention that capitalized names are for globals; think of analysis tools. Also, this is a whole family of methods that are supposed to respect a few rules, so it's better if they are easily identifiable; we can imagine that some day, Slime will be extended with Sake-specific checks.
As for utility methods, they are all defined in the root class Packages, but I don't see why there couldn't be a need for some more in a subclass, especially if you want to implement a kind of lazy graph construction like in PRDistribution.
From what I understand you are simply suggesting that "sub- universes" be defined and available as SomeProject-Setup. That sounds fair enough, and is part of the original idea.
Actually I'm not convinced that the central Universe approach really works for the squeak community, since it's so divided. Application developers have a precise knowledge of the dependancies of their own packages. They could document the fine-grained dependancies in their Foo-Setup (i.e. for Seaside, encode http://code.google.com/p/seaside/wiki/LoadOrder). Then, if someone wants to provide a universe-like larger-grained set of dependancies, they can do so in a separate place, reusing dependancies from multiple independently developed projects.
Will it catch on though... I expect that if I ever get to release 3.11 it will include LPF and sake-packages as standard (with the option to remove them)
Well, as far as I am concerned, if the big modular packages like Seaside/Magritte/Pier+addons/Moose adopt it, I consider it's caught on :) More than the features of sake over rake, I think it's whether it enables the community to progress in a smoother way that will determine success. For instance, I think SourceTalk and Bob should be linked or even integrated someday, so that getting automatic builds for a new project is near-instant.
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet