> 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.

Yes bundle groups that so that I can give you one bundle and you get
everything. A bundle is a group of packages.

> 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.

It seems to me that you want to have a lot of variation points
and we will see in practice if we need that.

I have the impression that there too much concepts there.

	
>> 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.

Yes you will have to version the map.

>
> 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.

Yes I know but I was sincerly lost in all the emails.
So now this was the time to see what came out of this flurry of emails.

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.

Thanks for your answers.

Stef