Hannes Hirzel <hannes.hirzel.squeaklist at bluewin.ch> wrote:
> ducasse wrote:
> 
> > My impression is that the scripts are in another dimension
> > because why wouldn't possible to say
> > 
> >     (PackageStef giveConfigNamed: 'stef3.3') load.
> > 
> >  From the conceptual point of view you want package (with dependencies 
> > express in configmaps)
> > to have better flexibility but why would you need load scripts. After 
> > you will use package that are empty
> > and just define a configMaps and you will get group of packages.
> > 
> > My feeling is that load scripts are mechanisms.
>                                        ^^^^^^^^^^
>                                        important remark
> 
> Yes from a user point of view I'd like do deal with a package as an 
> object. I just want to load it in specific version.
> 
> I do not want to think Unix-like (shell scripts etc.).
> 
> The package should know what it needs.

No, :-) I don't agree. A very important aspect is that the packages
should NOT know what they need.
Because they may be wrong. Or put another way, the author of a package
has his/her idea of what the package needs - but I may know of
alternatives. There may be several configurations for using say
HttpView. I know a few, but you may know of even more.

> Not an external script.

Agreed - not an external *script*. But an external *object* - the
package configuration. I am *not* saying that load scripts are the
pillar of the planned dependency scheme - I am just explaining what they
*can* be used for, and the fact that the classification "static" vs
"dynamic" is interesting.

> Of course there could be packages which basically do nothing besides 
> loading other packages.
> 
> On the other side implementation wise (and from the point of feasability 
> in terms of acceptance within the Squeak community) the way Göran is 
> persuing might be the best for the foreseable future.

Just a final remark, which I wrote in the other post - load scripts are
available as a side consequence of the .st format being supported for
packages. We have them people. But we should NOT use them for the
dependency scheme.
 
> In any case: A great thank you for all of you for woking on these 
> portant things.
> 
> Even a suboptimal solution, but one which deals with version numbers and 
> works reliably is a big step forward.

The upcoming first release of SM2 (2.0) at least has releases/versions
and thus can be used together with load scripts and will make life a bit
easier. One step at a time.

> Hannes

regards, Göran