[squeak-dev] Re: The Trunk: Collections-ar.307.mcz
keith_hodges at yahoo.co.uk
Mon Feb 15 05:36:29 UTC 2010
> My question stands, who decides what is big enough to be candidate
> to be
> separately packaged? If they were 13 methods but 2 classes they will
> integrated packaged in squeak trunk? What about a class with 400
> methods? This is subjective?
this is something I have been working on for the Cuis - InstallSeries
project. While "InstallSeries" installs packages/updates/changesets
aka slices, the converse "System-Packaging" project allows you to
define a small slice, and export it as source, like so.
Launching from the initial script, and accessors for command line
self write: 'updates1-System-Support/0001/StartupManager-(launch)'
using: [ :pkg |
pkg stampComment: self myComment.
pkg requiresClass: StartupManager interface: #( ).
pkg systemProtocol: 'system-startup-launch'.
This particular slice definition currently covers 8 methods.
It exports the code from my working Sooty2.1 image (Cuis2.1 + lp:~/
keithy/cuis/stable-kph), from where I commit it to the shared
repository for others to load via the "InstallSeries" mechanism.
I am in the process of working out the finer details of how this all
works in a non MC world. So far I am able to replicate many of the use
cases that would previously have used a substantial chunk of the
functionality of Installer, MC1, Sake/Packages or Metacello, Gofer,
ChangeSorter, MC2(?) All this for just 5 core classes give or take.
For example, I can organise for a complex image to be built from Magma
Seaside3.0, Pier and Beach packages, with a load order taking in to
account dependencies. I can share this "branch" for you to load
exactly into your base image whatever it may be, merging in any of
your own patches you may wish to add for your context. At any point I
can re-export all of the source code for my branch to commit back up
to a shared repo as a one liner.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev