Ned Konz <ned at bike-nomad.com> wrote:
> On Friday 18 October 2002 01:53 pm, Avi Bryant wrote:
> > Yeah, I was trying to avoid putting do-its into the fileout; that's
> > one thing that's nice about having the class, it doesn't require
> > any special-casing.
> >
> > Hmm.  Well, does anyone else have an opinion?
> 
> Just a couple of stupid questions as I'm trying to use DVS for 
> connectors:
> 
> * What has to go in the PackageInfo subclass? I see that externalName 
> provides the default fileOut name. Is there anything there that is 
> usefully overridden?
The most important use found for it so far is to change the rules that
dictate what a module is by changing the testing methods. This can be
used to cheat the naming conventions (sometime the naming convention
makes the names too long. I can't find the messages about this, maybe it
was that mentioned the problem?).
 
> * Where do I put my change set's prolog? I have to rename classes, 
> convert instances, etc. before any loading happens.
I haven't had to do that yet - Avi?
 
> * where do I put the CS postscript? I make flaps, etc. when the 
> project is loaded.
Well, it is probably better to try not to have imperative code in
prologs/postscripts, because that's exactly what makes package
impossible to unload - which someone is likely to try to change someday
soon (except for the doits, it's quite possible, and I have some
ideas...). At least some such code can live in the class side initialize
method of your classes. Could this serve in this case?
 
> * How do I abort loading if there is a missing pre-requisite 
> identified in the prolog, wherever it gets put?
Right now there is no real handling of dependencies in any of the
package tools, but this will probably change. You might want to cheat in
the meantime, and work with a mock configuration -
1. Create a SqueakMap package that's an st file that itself has no
definitions, but only a script loading a list of applications in order
(loading only what's missing). This is your configuration package.
2. Create you other SM cards for the packages that include the code.
Note in their description that they have prerequisites, and should be
loaded through the configuration package.
3. In SqueakMap, you put packages in version categories (Squeak3.2) to
indicate compatibility. Put only give only the configuration package in
such a category, and people using the miniloader will by default see
only it.

Extending a snippet Goran sent a short while ago, this is a sketch for
your configuration .st package

sm _ SMSqueakMap default loadUpdates.
{'ConnectorFixes'. 'ConnectorsModel'. 'ConnectorsMorphs'.
'ConnectorsIntegration'} do: [:packageName |
 (SMInstaller forPackage: (sm cardWithNameBeginning: packageName) 
			directory: FileDirectory default) install 

> Thanks,
> -- 
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE

Daniel Vainsencher