Begin forwarded message:
From: Keith Hodges <keith_hodges@yahoo.co.uk> Date: November 11, 2008 11:11:47 PM CEST To: Damien Pollet <damien.pollet@gmail.com> Cc: Stéphane Ducasse <stephane.ducasse@inria.fr>, Tudor Girba <girba@iam.unibe.ch
, Damien Cassou <damien.cassou@gmail.com> Subject: Re: Sake, Packages, and deployment code
Damien Pollet wrote:
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.
that's a good idea.
I guess SakeMeta separates it a bit already⦠maybe it would help me if I knew the implementation of rake, but I don't :)
rakes implementation code is visible online (somewhere)
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.
Ok I am thinking about it.
SSpec doesnt follow that convention, but uses method category 'specs'. So in SUnit-improved it has a more flexible approach in order to accomodate SSpec and not to have to follow this convention, it allows you to define toDo* bug* , method categories, flagged methods, pragmas or whatever else you choose.
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.
I have never looked at PRDistribution. Lukas and folks changed something which has broken all my pier deployments and so I am stuck with an older version of pier until I can find some spare time to fix it.
I still keep trying to persuade Lukas to put the configuration for pier in the PRFrame, since that is the context in which it is displayed when I embed pier in another app.
Right now I am betting that PRDistribution is an incompatible alternative to my PRFrames, which is a shame.
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.
Neither am I. I would like "universes" to die off. The reason being the overly controlled closed nature of the master database, and the dependency upon some specific server. The UI is a bit rubbish too.
But what I am convinced of is that if you put the control of the dependencies, purely in the hands of the developers, then it will get out of date, when the developers get too busy, and hold on to too much control.
The ethos behind Sake/Packages is that it is the package USERS have the power to determine what works in what context. Developers often don't test their packages in all contexts, but users may do.
It is a space in which the collective knowledge of what works where is collated by the community.
Both the Users "universes" and the developers SetUp packages can be used to get the best of both worlds.
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 :)
VW port anyone?
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
Just need to add MC2 support to, Installer.
For a fastest loading experience, try MC1.6!
I also have a plan which might work for binary loading for both MC1 and 2.
Keith