[squeak-dev] Sake/Packages declared open!

> Dear All,
>
> Sake/Packages is now at a point where it is a useful resource for the
> community to contribute to. To help this along I have set the
> squeaksource.com commit emails to go to
> [hidden email]  Discussion as to what should go
> where and whether or not specific configurations work or not can be
> directed there also. I believe that the Sake/Packages package
> definitions will be a useful resource for all of the Squeak communities.
>
> Please join me in in this knowledge gathering exercise, please bring
> what you know about what loads where and feel free to fill in the
> package definitions. Its very easy, I updated all of
> Seaside/Scriptaculous in 3.7 through to 3.10 in about 10 mins.
>
> To load Sake/Packages into a LevelPlayingField (LPF) image:
>
> Installer install: 'Packages'.
>
> If you want to maintain all of the published versions of your package
> you may prefer to load.
>
> Installer install: 'PackageAllVersions'.
>
> If you are using squeak 3.10 the following hierarchy of classes will load.
>
> 1. Packages - Abstract Base Class
>
> 2. PackagesAllVersions - Non-specific package definitions that load the
> latest version, if that version is likely (but not 100% guarenteed) to
> work in all versions. You don't have to wait for your package to be
> perfect, to put a generic definition in here, enabling your users to try
> it out in their favourite squeak version, and provide you with feedback.
>
> 3. PackagesSqueak310beta - Non-specific package definitions that load
> the very latest version, specific to 3.10. Again it is expected to work,
> but the author may not have actually tested your configuration.
>
> 4. PackagesSqueak310U - The specific exact published version in
> Universes that is supposed to have been tested in that image version.
>
> 5. PackagesSqueak310 - The specific exact version that 'you'/'we' have
> found 'actually' works, overriding the universes definition.
>
> Make it easy for Authors and Users.
> ==========================
>
> Benefits for Authors - You do not have to constantly update your
> published packages all the time, you can publish a "load latest" script
> in the generic (2. 3.) levels of the hierarchy.
>
> Benefits for Users
> =============
> Quality
>
> The community can clearly identify and publish what works where, and
> this provides a shared collective whiteboard in which active
> collaboration can take place. In addition, if a specific version in a
> specific image needs a patch to work, then it can actually be included
> in the load script for that package. Thus for the first time patches can
> be included in published packages, and released for testing, without the
> bottleneck of waiting for the Package author to get around to fixing the
> problem for your squeak-fork. Those who submit patches will actually see
> their work get used immediately.
>
> Automation
>
> All installation scripts should run without interaction, for automated
> installation. See 'Seaside' for an example.
>
> 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.
>
> Flexibility
>
> Have your own package definitions for your own squeak fork, subclass to
> specialize/override etc etc.
>
> I declare Sake/Packages for squeak open!
>
> enjoy
>
> Keith
>
> ===
>
> btw... LevelPlayingField is currently broken in 3.8.1 and I dont have
> time to fix it, the SqueakMap update process chokes it.
> to do: Sake/Packages-SqueakMap the same scheme for
>
> p.s. In case anyone wonders... the packages mailing list has not been
> used for ~ 3 years. I emailed the packages mailing over a year ago and
> discussed its use for this purpose with anyone who cared.
>
>
>
>
>

> Dear All,
>
> Sake/Packages is now at a point where it is a useful resource for the
> community to contribute to. To help this along I have set the
> squeaksource.com commit emails to go to
> [hidden email]  Discussion as to what should go
> where and whether or not specific configurations work or not can be
> directed there also. I believe that the Sake/Packages package
> definitions will be a useful resource for all of the Squeak communities.
>
> Please join me in in this knowledge gathering exercise, please bring
> what you know about what loads where and feel free to fill in the
> package definitions. Its very easy, I updated all of
> Seaside/Scriptaculous in 3.7 through to 3.10 in about 10 mins.
>

> where and whether or not specific configurations work or not can be
> directed there also. I believe that the Sake/Packages package definitions
> will be a useful resource for all of the Squeak communities.
>
> Please join me in in this knowledge gathering exercise, please bring what
> you know about what loads where and feel free to fill in the package
> definitions. Its very easy, I updated all of Seaside/Scriptaculous in 3.7
> through to 3.10 in about 10 mins.
>
> To load Sake/Packages into a LevelPlayingField (LPF) image:
>
> Installer install: 'Packages'.
>
> If you want to maintain all of the published versions of your package you
> may prefer to load.
>
> Installer install: 'PackageAllVersions'.

>
> If you are using squeak 3.10 the following hierarchy of classes will load.
>
> 1. Packages - Abstract Base Class
>
> 2. PackagesAllVersions - Non-specific package definitions that load the
> latest version, if that version is likely (but not 100% guarenteed) to
> work in all versions. You don't have to wait for your package to be
> perfect, to put a generic definition in here, enabling your users to try
> it out in their favourite squeak version, and provide you with feedback.
>
> 3. PackagesSqueak310beta - Non-specific package definitions that load the
> very latest version, specific to 3.10. Again it is expected to work, but
> the author may not have actually tested your configuration.
>
> 4. PackagesSqueak310U - The specific exact published version in Universes
> that is supposed to have been tested in that image version.
>
> 5. PackagesSqueak310 - The specific exact version that 'you'/'we' have
> found 'actually' works, overriding the universes definition.

> Hi Keith,
> "Keith Hodges" <[hidden email]> wrote in message
> news:[hidden email]...
>> Dear All,
>>
>> Sake/Packages is now at a point where it is a useful resource for the
>> community to contribute to. To help this along I have set the
>> squeaksource.com commit emails to go to
>> [hidden email]  Discussion as to what should go
>
> .com ? did you mean .org ?

>> where and whether or not specific configurations work or not can be
>> directed there also. I believe that the Sake/Packages package
>> definitions will be a useful resource for all of the Squeak communities.
>>
>> Please join me in in this knowledge gathering exercise, please bring
>> what you know about what loads where and feel free to fill in the
>> package definitions. Its very easy, I updated all of
>> Seaside/Scriptaculous in 3.7 through to 3.10 in about 10 mins.
>>
>> To load Sake/Packages into a LevelPlayingField (LPF) image:
>>
>> Installer install: 'Packages'.
>>
>> If you want to maintain all of the published versions of your package
>> you may prefer to load.
>>
>> Installer install: 'PackageAllVersions'.
>
> I think you meant to write...
>    Installer install: 'PackagesAllVersions'
> (s was missing from end of Packages)
>

>>
>> If you are using squeak 3.10 the following hierarchy of classes will
>> load.
>>
>> 1. Packages - Abstract Base Class
>>
>> 2. PackagesAllVersions - Non-specific package definitions that load
>> the latest version, if that version is likely (but not 100%
>> guarenteed) to work in all versions. You don't have to wait for your
>> package to be perfect, to put a generic definition in here, enabling
>> your users to try it out in their favourite squeak version, and
>> provide you with feedback.
>>
>> 3. PackagesSqueak310beta - Non-specific package definitions that load
>> the very latest version, specific to 3.10. Again it is expected to
>> work, but the author may not have actually tested your configuration.
>>
>> 4. PackagesSqueak310U - The specific exact published version in
>> Universes that is supposed to have been tested in that image version.
>>
>> 5. PackagesSqueak310 - The specific exact version that 'you'/'we'
>> have found 'actually' works, overriding the universes definition.
>
> I can see that I have this hierarchy of classes. Let's try loading
> something that I know about.
> I am using developer image sq3.10-7159dev08.04.1 , and I can see that
> PackagesSqueak310U has a method #FreeTypePlus, so let's try loading that.
>> From the class comment(s) , I work out that I need to evaluate this...
>    (Packages universe load: 'FreeTypePlus') run

> That works. It's loading... I get an error when it tries to load the
> dependent package 'FFI', but I expected that.
> I have a patch on mantis to get FFI to load, so let's edit the entry
> for FFI to load that patch first....
>    self load: [
> (Installer mantis)
>  bug: 6952
>  fix:
> 'ClassBuilder-nameinEnvironmentsubclassOftypeinstanceVariableNamesclassVariableNamespoolDictionariescategoryunsafe.st'.
>
>     Installer
> installUrl:'http://map.squeak.org/accountbyid/cf58c358-46ee-465e-b6db-2740e9b32a53/files/InstallFFI3.st'.
>
>    ].
>
> and try again.... It gets further, and fails after loading
> FreeTypePlus when trying to load the fonts from the OS.
> I know what this is, the initialize methods are run in a different
> order with MC1.5.
>
> After a couple of hours trial and error, I have a new class,
> PackagesSqueak310 subclass: #PackagesSqueak310dev0804, which allows
> FreeTypePlus and FFI to load into sq3.10-7159dev08.04.1.

> Having committed the modified Packages-Squeak310 to
> http://www.squeaksource.com/Packages , I note that subsequent
> invocations of...
>    Installer install: 'PackagesAllVersions'
> cause my new class to be loaded. So it is installing the most recent
> version of Packages-Squeak310 ?
>
> I can now evaluate...
>    (PackagesSqueak310dev0804 load: 'FreeTypePlus') run.
> and FreeTypePlus & FFI get loaded.

> I'm not suggesting for one moment that any of this is a substitute for
> fixing underlying bugs/problems in packages and installers; but it
> seems to be a very useful tool for documenting those problems and
> providing workarounds.
>
> Now, I wonder, did I do the right thing in creating the
> PackagesSqueak310dev0804 class?
> Is it a good name?
> Were you expecting people to do this kind of thing for specific
> versions of particular forks/distributions?
> Was I right to add my class to Packages-Squeak310, or should I have
> created a separate package?

> Hi Keith,
> "Keith Hodges" <[hidden email]> wrote in message
> news:[hidden email]...
>> Dear All,
>>
>> Sake/Packages is now at a point where it is a useful resource for the
>> community to contribute to. To help this along I have set the
>> squeaksource.com commit emails to go to
>> [hidden email]  Discussion as to what should go
>
> .com ? did you mean .org ?

>> where and whether or not specific configurations work or not can be
>> directed there also. I believe that the Sake/Packages package
>> definitions will be a useful resource for all of the Squeak communities.
>>
>> Please join me in in this knowledge gathering exercise, please bring
>> what you know about what loads where and feel free to fill in the
>> package definitions. Its very easy, I updated all of
>> Seaside/Scriptaculous in 3.7 through to 3.10 in about 10 mins.
>>
>> To load Sake/Packages into a LevelPlayingField (LPF) image:
>>
>> Installer install: 'Packages'.
>>
>> If you want to maintain all of the published versions of your package
>> you may prefer to load.
>>
>> Installer install: 'PackageAllVersions'.
>
> I think you meant to write...
>    Installer install: 'PackagesAllVersions'
> (s was missing from end of Packages)
>

>>
>> If you are using squeak 3.10 the following hierarchy of classes will
>> load.
>>
>> 1. Packages - Abstract Base Class
>>
>> 2. PackagesAllVersions - Non-specific package definitions that load
>> the latest version, if that version is likely (but not 100%
>> guarenteed) to work in all versions. You don't have to wait for your
>> package to be perfect, to put a generic definition in here, enabling
>> your users to try it out in their favourite squeak version, and
>> provide you with feedback.
>>
>> 3. PackagesSqueak310beta - Non-specific package definitions that load
>> the very latest version, specific to 3.10. Again it is expected to
>> work, but the author may not have actually tested your configuration.
>>
>> 4. PackagesSqueak310U - The specific exact published version in
>> Universes that is supposed to have been tested in that image version.
>>
>> 5. PackagesSqueak310 - The specific exact version that 'you'/'we'
>> have found 'actually' works, overriding the universes definition.
>
> I can see that I have this hierarchy of classes. Let's try loading
> something that I know about.
> I am using developer image sq3.10-7159dev08.04.1 , and I can see that
> PackagesSqueak310U has a method #FreeTypePlus, so let's try loading that.
>> From the class comment(s) , I work out that I need to evaluate this...
>    (Packages universe load: 'FreeTypePlus') run

> That works. It's loading... I get an error when it tries to load the
> dependent package 'FFI', but I expected that.
> I have a patch on mantis to get FFI to load, so let's edit the entry
> for FFI to load that patch first....
>    self load: [
> (Installer mantis)
>  bug: 6952
>  fix:
> 'ClassBuilder-nameinEnvironmentsubclassOftypeinstanceVariableNamesclassVariableNamespoolDictionariescategoryunsafe.st'.
>
>     Installer
> installUrl:'http://map.squeak.org/accountbyid/cf58c358-46ee-465e-b6db-2740e9b32a53/files/InstallFFI3.st'.
>
>    ].
>
> and try again.... It gets further, and fails after loading
> FreeTypePlus when trying to load the fonts from the OS.
> I know what this is, the initialize methods are run in a different
> order with MC1.5.
>
> After a couple of hours trial and error, I have a new class,
> PackagesSqueak310 subclass: #PackagesSqueak310dev0804, which allows
> FreeTypePlus and FFI to load into sq3.10-7159dev08.04.1.

> Having committed the modified Packages-Squeak310 to
> http://www.squeaksource.com/Packages , I note that subsequent
> invocations of...
>    Installer install: 'PackagesAllVersions'
> cause my new class to be loaded. So it is installing the most recent
> version of Packages-Squeak310 ?
>
> I can now evaluate...
>    (PackagesSqueak310dev0804 load: 'FreeTypePlus') run.
> and FreeTypePlus & FFI get loaded.

> I'm not suggesting for one moment that any of this is a substitute for
> fixing underlying bugs/problems in packages and installers; but it
> seems to be a very useful tool for documenting those problems and
> providing workarounds.
>
> Now, I wonder, did I do the right thing in creating the
> PackagesSqueak310dev0804 class?
> Is it a good name?
> Were you expecting people to do this kind of thing for specific
> versions of particular forks/distributions?
> Was I right to add my class to Packages-Squeak310, or should I have
> created a separate package?

> If you are using squeak 3.10 the following hierarchy of classes will  
> load.
>
> 1. Packages - Abstract Base Class
>
> 2. PackagesAllVersions - Non-specific package definitions that load  
> the latest version, if that version is likely (but not 100%  
> guarenteed) to work in all versions. You don't have to wait for your  
> package to be perfect, to put a generic definition in here, enabling  
> your users to try it out in their favourite squeak version, and  
> provide you with feedback.
>
> 3. PackagesSqueak310beta - Non-specific package definitions that  
> load the very latest version, specific to 3.10. Again it is expected  
> to work, but the author may not have actually tested your  
> configuration.
>
> 4. PackagesSqueak310U - The specific exact published version in  
> Universes that is supposed to have been tested in that image version.
>
> 5. PackagesSqueak310 - The specific exact version that 'you'/'we'  
> have found 'actually' works, overriding the universes definition.

> Automation
>
> All installation scripts should run without interaction, for  
> automated installation. See 'Seaside' for an example.
>
> 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.

> Flexibility
>
> Have your own package definitions for your own squeak fork, subclass  
> to specialize/override etc etc.
>
> I declare Sake/Packages for squeak open!
>
> enjoy
>
> Keith
>
> ===
>
> btw... LevelPlayingField is currently broken in 3.8.1 and I dont  
> have time to fix it, the SqueakMap update process chokes it.
> to do: Sake/Packages-SqueakMap the same scheme for
>
> p.s. In case anyone wonders... the packages mailing list has not  
> been used for ~ 3 years. I emailed the packages mailing over a year  
> ago and discussed its use for this purpose with anyone who cared.
>
>
>
>
>

>> 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.
>

> 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
>>
>>
>
>
>
>

> stephane ducasse wrote:
>
> > 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
> >
>  I think Sake will be worth a chapter or two! I wonder what animal O'Reilly
> will give it?
>

> stephane ducasse wrote:
>> 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
> I think Sake will be worth a chapter or two! I wonder what animal  
> O'Reilly will give it?
>
> Keith
>
>
>