In SM 1.05 I introduced a class called SMScriptEngine for this very
purpose, here is the class comment:

SMScriptEngine is used in load scripts so that SqueakMap can have some
control over how the load scripts behave, allow limited user "interface
independent" interaction etc.

This class is not yet implemented :-) - today you will simply need to
access the map directly. 
Here is an example preamble (as in ChangeSets and SAR files) that only
installs one package:

SMSqueakMap default doLoadScript: [:scriptEngine |
	scriptEngine map installPackageNamed: 'SqueakMap Browser'
]

-----

Three reasons this would be good:

1. SqueakMap can "disable" such embedded "load scripts" by simply not
running the block.
2. The scriptEngine can expose a small highlevel package API making the
scripts simple and understandable.
3. The scriptEngine can expose a simple API for interaction with the
user (confirm:, inform: etc) making it both scriptable and able to
function with a different UI (headless or whatever).

Note though that I haven't implemented anything at all in this class
yet. So if Ned, Stephen or anyone would like to fill it with a few
things then be my guest.

regards, Göran

PS. I am still nervous over SAR turning into a .rpm/.deb engine thus
embedding all the package logic/dependencies inside the packages and
making SqueakMap unable to do anything useful. But I have already warned
about this so will shut up about it.