Daniel Vainsencher <danielv at netvision.net.il> wrote:
> I think I see what you mean. Let's see if I do:
> There's a conflict between expecting the services architecture to
> provide you with the correct installer for each package automatically,
> and between using any external dependency mechanism to represent this
> dependency.

Right.

> I think a good enough solution is - 
> 1. The services architecture will not cause installation of anything,
> but it will help expose any packages to all services already installed
> in the image.

Yes, also seems "logical" somehow to the user I think.

> 2. One of those services might use SqueakMap categories to find
> appropriate installers, and offer that option (example later).

Yes, seems like a nice way of doing that.

> Example:
> I want to install the RB package. It has the category PackageType\SAR.
> All the SM services I have installed come forth and decide that they
> cannot install SARs, because none of them is SARInstaller. However, one
> of them is the Meta Installer (tm), and it detects that there's a
> package in SM that has the category PackageService\Installer\SAR (which
> happens to be called SARInstaller), and so offers to "install
> SARInstaller" on the menu. After the user chooses that, he now has
> SARInstaller, and will be able to install the RB.

I think I like this. In short when you publish a "PackageService" you
need to associate the service with the "PackageTypes" that the service
can apply to.

And given that we can propose to the user to "fetch more services" that
can be applied.

And later when we start fiddling with package configurations etc this
mapping can hopefully be used to help that "dependency engine" finding
proper ways to install packages too.

In fact - this association through PackageType is looser than a
dependency and that is how it should be I think.

> This takes care of the light weight scenario, where it should be
> straight forward for the user to install simple single packages, and
> would solve our current problem. 
> 
> Another scenario is the image configuration scenario, and I see nothing
> wrong in it loading first some installers, and then the needed packages.

Exactly, when we are talking "load scripts" anything goes.

regards, Göran

PS. Don't hold your breath for this. It will be in 1.1 at the earliest.
BUT... I am repackaging SM 1.05 today/tomorrow so that PackageInfo, DVS,
SARInstaller etc are included by default when installing SqueakMap.