I like the idea in general...here is a list of items I'd like to see 
addressed (these are largely based on my experience in splitting 
Comanche into separate packages and managing the packaging, publishing 
and loading of those packages)...the Comanche packaging tools already 
support several of these items...I think that the challenges that I 
faced with packaging Comanche makes for a really good set of 
requirements (for a development, packaging, and publishing system)...I 
think we would end up with a really nice set of tools and frameworks if 
we could make a goal of re-packaging Comanche using the new MC 
features.  Here's the list of things that I think need to (eventually) 
be addressed:

- make the load process a matter of building a load configuration and 
loading it

- allow *named* package dependencies to be specified, along with default 
fulfillments (that identify a specific package and version)...the 
default fulfillments can be overridden by a load configuration and the 
defaults can be used to create a load configuration

- allow packages to be "published" to a separate directory from the 
development versions and allow a "version name" to be specified...the 
version name would be distinct from the internal Monticello version 
numbering and would be used when identifying packages to load or 
dependecies...use a convention like "PackageName-1.0.sar" where "1.0" is 
the "version name" (not the internal MC version number)...a URL like 
sqpkg://PackageName:1.0 would sepcify a specific package and version.

- have some kind of directory the load tools can use for locating 
published packages...this is probably a future version of 
SqueakMap...rather than hold a path to a specific file, SM could have a 
path to the publishing directory of a package...within that directory 
would be all of the published versions of that package...an operation 
like: 'sqpkg://PackageName:1.0' asUrl load   ...would consult SM to find 
the publish directory, then look for a file named PackageName-1.0.sar in 
that directory

- allow optional packages to be specified...a loader can present a user 
with a prompt to ask if they also want to load the optional packages (if 
any)...I use this feature in KomServices to optionally load a 
StarBrowser UI for KomServices

- allow loose files to be bundled in a SAR and installed by a loader 
(distributions that include VM plugins really need this...as do any 
packages that require externally stored files)

- allow loose change sets for pre-loading to be attached to a package, 
bundled in the SAR, and installed during loading (I find this feature 
useful for maintaining the purity of a package that may require certain 
bug fixes in the base system...those bug fixes (which should eventually 
be incorporated in the base system) would be put into a preload change 
set)...with Comanche, any fixes to the base system (such as Socket) that 
I need, I put in a separate change set instead of including them in the 
package...that way, when they get fixed in the base system, I just 
remove the items from the change set and the package itself isn't 
cluttered with those things

- enable packages to segregate SUnit testing related items (ie. support 
a test category naming convention like "PackageName-Tests")...in the 
SAR, separate these items into their own files...a loader could then 
choose whether or not to load these items (the loader could also 
automatically run the tests after the load is completed).  This is one 
thing that the Kom packaging tools currently does and I really like it.

- multi package SARs are good if done correctly...specifically, allow 
multiple packages to reside in one SAR, but make sure that they remain 
independent, and are independently loadable...for example, if a 
prerequisite like sqpkg://StarBrowser:1.0 was specified by a load 
configuration (perhaps built from a default fulfillment), then the 
loader should look for that package first in the SAR, then online (the 
loader could also allow one to specify a search path)

- I don't necessarily agree with Goran that it's important to keep 
meta-info external to a package...I think the argument is that you won't 
have to get the whole package just to find out a list of requirements, 
etc...1) I don't think these packages are going to be all that big, 2) 
we can always replicate that information outside the packages in the 
future if we need to (matter of fact, it might be as simple as 
replicating the instances and subclasses of PackageInfo)...but its 
something that we can wait until we know more about what information 
needs to be replicated...I guess I see it as a sort of performance 
optimization that you really shouldn't spend much time on until more 
usage experience is obtained

- Stephen

Avi Bryant wrote:

>Just a half-formed late night thought:
>
>We'd like Monticello to support a number of different formats - for
>Smalltalk source code, this could include .st, .mc, .sif, .pst,
>Rosetta, and maybe others.  For other kinds of packages (and I don't see
>any reason why there couldn't be other kinds), there would be an entirely
>different set of possible formats.
>
>However, the contents of each of those formats maps to what Monticello
>calls a "Snapshot" - the collection of definitions being versioned,
>without any particular ancestry or packaging metadata attached to them.
>But what we generally want to be passing around are Versions, which
>contain a Snapshot plus all the necessary extra bits of info.
>
>We'd fuzzily been thinking that each format would have some semi-natural
>way of including this metadata - annotations for SIF, maybe a preamble
>comment for .st, and so on.  But this is pretty adhoc and doesn't feel
>quite right.
>
>What about taking a page from Ned's book and making the format be a ZIP
>file?  You could have special paths monticello/package,
>monticello/version_info which contained the metadata, and
>monticello/snapshot which explained (as a SAR-like install script,
>perhaps) how to recreate the Snapshot from whatever other members (like
>"source.sif", say) were in the ZIP.
>
>They could in fact be SAR files, whose install script checked for the
>presence of Monticello.  If it was there, they wouldn't directly install
>anything but instead would pop up the Version window from which you can
>load, merge, etc.  If there was no Monticello they would load themselves
>into the image as best they could.
>
>How does this sit with people?
>
>Avi
>
>
>  
>


-- 
- Stephen
_________
Do you need:
  Web/Domain/Application Hosting?
  Mailing List Services?
  IMAP/POP3/Web Email Accounts?
  Instant Messaging Accounts hosted on your domain?

Email me for information.