[squeak-dev] Sake/Packages declared open!
keith_hodges at yahoo.co.uk
Mon Apr 21 20:16:40 UTC 2008
stephane ducasse wrote:
>> Installer install: 'Packages'.
>> If you want to maintain all of the published versions of your package
>> you may prefer to load.
>> Installer install: 'PackageAllVersions'.
Ok, there is a monticello package for each squeak version, so far 3.7,
3.8, 3.9, and 3.10 but the more the merrier.
As a user of a particular version of squeak, Installer install:
'Packages' only installs the one that is relevant for you.
If you are a package author and you want to see/edit every place in the
Packages/Sake system in which your package has a load task and edit
them, then you will want to load all of the packages. That what
> Keith I try to understand what you mean by the previous statement.
> It is not clear to me.
> I do not understand the following one either. It seems that I missed
Each "Package Load Task" is an instance method. A hierarchy of classes
allows general package definitions at the top and more specific
definitions at the bottom.
We start with the most generic "Package Load Tasks". Packages which will
load into any version of squeak, and they will load the latest version
whatever it may be.
From there we work towards the most specific "Package Load Tasks".
Packages which need this script to load into this particular squeak version.
In between we have the Tasks, as defined by the current Universes
system, so these are fixed from the Sake/Packages point of view. The
universes definition should work but is potentially out of date.
You choose which level of specificity you want like so...
(Packages currentBeta load: 'Pier') run. "scripts defined at this level
can be generic"
(Packages universe load: 'Pier') run. "This is a recent universes
(Packages current load: 'Pier') run. "this is the maintained definition"
The nice thing about this is that it can be adapt to your position in
the development cycle. A new package that is constantly being updated
need only be defined generically. As a package matures and more people
are interested in stability, more specific definitions can be added.
>> If you are using squeak 3.10 the following hierarchy of classes will
>> 1. Packages - Abstract Base Class
>> Deterministic Builds (potentially*)
>> All of the package definitions, for the image you are using are
>> version controlled in monticello. So you can go back to a previous
>> configuration from a previous date and load it. *The packages you are
>> loading have to be listed to nominate specific packages for this to
> I do not understand the previous sentence and its implication.
If I load a package from Universes today it might give me a completely
different result from yesterday.
So testing and publishing a fantastic image building script which uses
Installer and Universes, can be broken by someone removing a package
from the universes server.
With a Sake/Packages based installer script you can say, "This worked
They use can load this and all will work exactly as when you tested it.
IFF the script uses tasks which are specifically defined.
A generally defined task is like so:
Installer squeaksource project: 'Sake'; install: 'Sake'.
A specifically defined task is like so:
Installer squeaksource project: 'Sake'; install: 'Sake-kph.15'.
does that help?
More information about the Squeak-dev