[Pharo-project] Fwd: Sake, Packages, and deployment code

Stéphane Ducasse stephane.ducasse at inria.fr
Wed Nov 12 02:20:49 EST 2008

Begin forwarded message:

> From: Keith Hodges <keith_hodges at yahoo.co.uk>
> Date: November 11, 2008 11:11:47 PM CEST
> To: Damien Pollet <damien.pollet at gmail.com>
> Cc: Stéphane Ducasse <stephane.ducasse at inria.fr>, Tudor Girba <girba at iam.unibe.ch 
> >, Damien Cassou <damien.cassou at 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 at 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

More information about the Pharo-dev mailing list