[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