Hi Lukas,
open builder.seaside.st and download an "Installer Script" from the advanced page. This is broken since Installer DNU #http: The generated pattern is (Installer http: 'someurl') install: 'somepackeg' but should be (Installer monticello http: 'someurl') install: 'somepackeg' This will work at least in latest Pharo. Maybe the builder could be extended to have a "Pharo" and a "Squeak" script option. Now the installer is always loaded from pbwiki at the beginning of the script. If in Pharo it would be better to use "ScriptLoader new installingInstaller" which downloads the Installer using Monicello and Squeaksource and allows to still have "Installer" as an MC package. Thx Torsten -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Torsten Bergmann wrote:
> Hi Lukas, > > open builder.seaside.st and download an "Installer Script" from the advanced page. This is broken since Installer DNU #http: > > The generated pattern is > > (Installer http: 'someurl') > install: 'somepackeg' > > but should be > > (Installer monticello http: 'someurl') > install: 'somepackeg' > > This will work at least in latest Pharo. > > Maybe the builder could be extended to have a "Pharo" and a > "Squeak" script option. Now the installer is always loaded from > pbwiki at the beginning of the script. > > the LPF.st script does it. > If in Pharo it would be better to use "ScriptLoader new installingInstaller" which downloads the Installer using Monicello > and Squeaksource and allows to still have "Installer" as an MC package. > > Thx > Torsten > If I understand correctly ScriptLoader is a collection of scripts for loading things into Pharo. Installer was explicitly designed to be the first thing that you load into an image, even a kernel image, from which you can load everything else. Installer's is intended to be a way of publishing scripts that may load into different images (this is what LevelPlayingField uses) with different variants. This is now embodied in Installer-Scripts, so we have a duplication here. Now that we have Seaside29 with its complicated dependecies, we find the seaside crew developing their own way of handling this, since they obviously feel that Universes is not the way to go for their multiple target platforms. Sake/Packages was designed to be able to define packages with dependencies (so we have more duplication here), and to able to account for variations between the potential target images in which to load, AND for users to be able to add additional target variants of their own. If you want a load script that loads into an image without Sake/Packages loaded, it would be trivial to get Sake/Packages to generate one for your particular image/target, based upon its dependency knowledge, and this is the way that Bob will probably use to build Seaside29 one click images. Keith _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |