On Thu, Mar 19, 2009 at 22:46, Keith Hodges <keith_hodges@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. 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)
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.
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.
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" or "how do I install this, but with this particular version of that", and so on. Maybe it's a problem of polishing the DSL, of documentation, maybe of tools, I'm not sure; that could be investigated a bit more.
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. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet