[Pharo-project] Gofer vs Installer

keith keith_hodges at yahoo.co.uk
Sun Sep 20 19:39:17 EDT 2009


On 19 Sep 2009, at 22:06, Stéphane Ducasse wrote:

>>>
>>>
>>>> goals?
>>>
>>> Perform MC actions (load, update, merge, revert, commit, diff,
>>> recompile) on a set of packages.
>>
>> So, not like Installer that can load packages from everywhere, Gofer
>> will concentrate on MC? What about ScriptLoader?
>
> ScriptLoader will certainly use gofer to install packages instead of
> installer
>

I always thought that you guys didnt actually understand installer.

Installer is intended to fulfill a strategic role, it has a role  
"Installing things", and it is extensible, so that anyone else who  
wants to "Install things" can contribute to it and extend it. So when  
a user wants to Install things, there is a logical place to go, that  
is called "Installer" for installing things.

If you want to create an additional tool for "installing things" then  
why not consider how this tool may provide facilities for installer.  
Otherwise this indicates that the whole design concept and envisioned  
role of Installer has been overlooked.

There is nothing wrong with ScriptLoader per se, but to be consistent  
with the vision for Installer it would be provided as an extension to  
Installer, thus...

Installer scriptloader doWhateverYouWantHere.

Installer was created to be the first and only dependency for kernel  
images of any kind, that you can use to load additional things.

You guys come along and use ScriptLoader for roughly this purpose,  
thus explicitly ignoring, and implicitly undermining this goal from  
the outset. Furthermore none of your scripts in script loader appear  
to take advantage of the second installer feature.

which is...

Installer is supposed to enable scripts to be written and executed  
piecemeal, i.e. bit by bit, in a workspace, or for debugging. i.e.  
Installer scripts do not , and should not use temporaries.

i.e. this style of code is NOT suitable for this purpose.

| repo |

	repo := Installer squeaksource project: 'This'.

	repo install: 'That'.

A better code example which has no method temporaries is shown below

Installer squeaksource project: 'This'; install: 'That'.
Installer monticello http: 'www.myrepo.com'; rememberAs: #mine.
Installer mine project: 'This'; install: 'That'.

Installer is supposed to provide a uniform API as a front end for all  
code loading tools

so if this new gofer thing comes along, its API (implemented on  
InstallerGofer perhaps) could be published as

Installer gofer project: 'This'; addPackage: 'That'; addPackage:  
'TheOther'; install.

or

Installer gofer project: 'This'; addPackage: 'That'; addPackage:  
'TheOther'; merge.

I think that it would be a shame if the gofer tool whatever it is,  
doesn't come with an Installer api, then it would not be contributing  
to the Installer story, it would be competing with it, in the same  
strategic space.

Given the fragmentation that is continuing to occur in the speak  
community, I think that this is tragic, that we end up with so many re- 
inventions of the wheel, yet none of them actually fulfills the role  
that, if you sit down and think about it for a few minutes, we  
actually need

I.e. the original invention of Installer was expressly so that EVERY  
base image published would at least have Installer loaded (or  
loadable) and users could build from there, using whatever tools, and  
a consistent API.
Installer helps this along in some situations since it knows how to  
load the source from an MC package in the event that MC is not  
actually loaded, and this helps with bootstapping Monticello etc.

If everyone uses, or has the option of using the same tools for  
building images, in every release, then this facilitates exchange of  
packages among forks, and helps those of us who are not at liberty to  
jump ship on a whim, and it helps those who do want to jump ship on a  
whim.

I was asking you for months to think along these lines and make such  
strategic choices based upon contributing to things that the squeak  
communities have in common or might want to use in common...

The vision for Installer was to be a base for building derived images  
in all release images in all forks.
The vision for MC1.5 was to be a set of tools that actually worked to  
load code in all images in all forks.
The vision for LevelPlayingField is to provide bootstrapping for  
difficult code to load in all images in all forks.
The vision for Sake/Packages was to be a universal set of package  
definitions and dependencies that show what works where in ALL images,  
in ALL Forks.
The vision for SUnit-improved was to be a universal means for defining  
SUnit and SSpec tests for ALL images so that it is possible to  
indicate what works where, in ALL forks, so that packages of tests can  
be maintained in common for ALL forks.

So, may I appeal to you, please contribute to and use installer,  
rather than compete with it, and perhaps reconsider your approach to  
the other ideas listed above.

Keith

p.s. I am considering, recruiting members for an independant "guild"  
of package developers, whose role would be to promote interoperability  
between squeak forks, so that packages can be developed once and  
deployed anywhere. I think this is needed because now we have no core  
image developers in either squeak or pharo, that look at  
interoperability.







More information about the Pharo-dev mailing list