Hi!

ducasse <ducasse at iam.unibe.ch> wrote:
> hi goran
> 
> I was waiting more than one hour in a doctor room this morning so I 
> could not
> stop my mind to think. I would like to understand how script works with 
> package.

Sure.

> You said that the package itself does not have dependencies to other 
> packages but that a
> script knows that. So my question is how do I know that when I load a 
> package I should run a script?

No, this is not really what I meant.

The packages themselves do not know the dependencies - that is correct.
But the load scripts are not meant to deal with that.

Load scripts are either dynamic or static.

A static load script always produce the same result. It is typically an
ordered series of "SM commands" to install specific package releases. I
guess it is similar to a "bundle", but the packages aren't "in" it, only
referenced. And it is a script, so it can execute arbitrary Smalltalk
code.

A dynamic load script can do whatever it likes - ask the user stuff,
give him/her choices etc. Such scripts are like "image building scripts"
- and they can produce different results each time. So if you are
constructing a distro, you should typically not rely on dynamic scripts.
Dynamic scripts are more interesting for end users - like wizards. :)

But finally - the thing that deals with dependencies are the "package
configurations". A package config is simply a Set of prerequisite
package releases. Similar to a load script, but they aren't "scripts"
that can be run - instead they are declarative in nature. Simply a Set.
 
> Every times I will publish a package I will have to produce a 
> configuration map (script) else other people will not
> be able to use my code or have to guess the dependency.

Yes. A package configuration is needed. I have toyed with the idea of
allowing to have a "default" package config embedded in the package -
but I don't really want that. Remember, this is just a UI/tool issue.
When publishing a new release I can always put the UI for the package
config right in there - it doesn't have to feel like an "extra awkward
step". But I want these things to be separate in the model.

> So how this is different that having the package knowing what it should 
> load.
> Do you plan to have one config map per package?

That is exactly the difference. There can be multiple package
configurations associated with a package. AND even more importantly -
the package configs are *associated* with the package but *owned* by the
person registering them. This means that *I* can publish a working
config for *your* package.

Another BIG advantage of having the dependencies outside the package
releases is that if I need to change the dependencies - I *do not* need
to publish a new release.

regards, Göran

PS. All this has been posted by me/discussed way back on the list.
Multiple times even. :) So searching the archives will show you more
examples, motivations etc.