[Pharo-project] [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource

Keith Hodges keith_hodges at yahoo.co.uk
Thu Mar 19 22:06:47 EDT 2009


Damien Pollet wrote:
> On Thu, Mar 19, 2009 at 22:46, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
>   
>> I have long been frustrated that there is no place in squeaksource for
>> documenting what is in a repository, and offering feedback as to what
>> works where.
>>     
>
> Yes, and the MC tools should support that IMHO.
>   
It was one of the first ideas I was going to add to MC, even just to
have a simple text file explaining what is going on in a repo.

I put a lot of effort into MC to bring the forks together, and make it
maintained and able to move forward with one voice. That failed, so my
motivation for hacking MC anymore is pretty low.
> BTW I'd also add: no nice support for named/tagged branches (I mean,
> in a big project there should be released/working/devel/in-progress
> branches, or at least documented sequences of snapshots for stable
> versions, and we have
> package-developerUniversallyKnownToNotRegularlyBreakThings.biggestNumber.mcz)
>   
My brain struggles with branches. Perhaps not having them is a good idea?
>> I have started to use Sake/Packages as a kind of micro "universe" for my
>> Seaside "Client" UI & Backend Component Framework. Having seen how
>> useful this is I thought that this might be useful for pier, and of
>> course seaside and other projects.
>>     
>
> Yup, I like the idea.
Great!
>> Some have reservations about Sake/Packages because they say it is not
>> declaritive.
>>     
>
> Huh… it's a rule system, right ? The alternative I know about being
> scripts that explicitly load snapshots in sequence, I fail to see
> where sake is not declarative.
>   
Its because the rules to load: a package can be blocks executing an
arbitrary script. In normal use the #defaultAction is to process the
given "declared" url to find the package to load.
> From my discussions on the subject, problems are more about the
> perception of what level of predictability and control one would get
> by using sake. Questions like "how do I know what will get installed
> if I pull this one"
(Package named: 'SomePackage) what explore.

This could be improved to ask Installer exactly what it will install,
perhaps -

(Package named: 'SomePackage) whatUsingDryRun explore.

Also with DeltaStreams integration with Installer, we might have the
ability to load into a "Delta/SystemEditor" rather than actually in to
the image.
>  or "how do I install this, but with this
> particular version of that", and so on. Maybe it's a problem of
>   
Interesting point. I cant think of how to do that. Unless you use sake
to generate a script or a task data scructure, and then you manually
edit it.

How about merging two dependency trees like so:

(Packages current named: 'Seaside) using: (Packages beta named: 'Pier)
> polishing the DSL, of documentation, maybe of tools, I'm not sure;
> that could be investigated a bit more.
>   
Can never get enough Documentation!
> For me it's clear that automatic dependancy management is the way to
> go, though the squeak/pharo community does not have resources or
> organization like debian's, so I think we need a more decentralized
> and agile way of managing dependancies, detecting and resolving
> incoherencies, etc.
>   
Bob might be able to do something like that in the future. He is sitting
there monitoring a number of repositories, he could periodically process
contributions and derive dependencies because he has some knowledge of
the big picture.

Keith






More information about the Pharo-dev mailing list