[squeak-dev] Sake/Packages declared open!
stephane ducasse
stephane.ducasse at free.fr
Tue Apr 22 19:38:21 UTC 2008
thanks I will have a look
I'm still writing on installer for sbe volume two.
But I took a break to finish the seaside book :)
Stef
On Apr 21, 2008, at 10:16 PM, Keith Hodges wrote:
> 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
> PackagesAllVersions does.
>
>> 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 something.
>>
> 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
> definition"
> (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 load.
>>>
>>> 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 work.
>>
>> 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 with PackagesSqueak310-kph-14".
> 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?
>
> Keith
>>
>>
>
>
>
>
More information about the Squeak-dev
mailing list
|