No, I'm proposing this only for installers, and that only as halfway measure for all those relatively simple packages that you can't install only for lacking the proper service.
This is definitely NOT a proposed replacement to having configuration package types that encapsulate things like dependencies (though the idea of a reflective service that uses SM itself might be useful in other contexts too).
I personally don't think we should model dependencies directly. If Goran's view of configurations is "I assert that the RB 1.2 works with PackageInfo 3.4", then my proposal is the agnostic "Loading PackageInfo 3.4 and then RB 1.2 and then ... is good".
This could obviously be used to make sure both dependencies and proper scaffolding is installed before any specific package.
This handles any depth dependencies in one configuration, and also allows composition of configurations to make packaging modular.
Does this seem reasonable?
Daniel
Julian Fitzell julian@beta4.com wrote:
Daniel,
Are you suggesting this only for installers or for all dependencies? I'd hate to have to manually install the dependencies for a package. You might easily have a few levels of depth in your dependencies.
Julian
Daniel Vainsencher 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.
I think a good enough solution is -
- The services architecture will not cause installation of anything,
but it will help expose any packages to all services already installed in the image. 2. One of those services might use SqueakMap categories to find appropriate installers, and offer that option (example later).
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.
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.
Daniel Vainsencher
goran.hultgren@bluefish.se wrote:
Julian Fitzell julian@beta4.com wrote:
goran.hultgren@bluefish.se wrote:
Julian Fitzell julian@beta4.com wrote: [SNIP]
I didn't say SqueakMap depended on SARInstaller. I meant that packages that are packaged as SARs depend on SARInstaller. So when you try to install a SAR package and don't have SARInstaller, it will get installed first since it is a dependency.
Duh. Ok, sorry - didn't read careful enough. Yes, this would be neat. But... hmmm. Interesting. It wouldn't work at all with the current architecture - nor the one I am aiming for in 1.1. Hmmmm.
I'm curious why it doesn't work with what you're planning. Isn't it just a simple matter of giving the package a dependency on the installer? Presumably all the dependencies are installed prior to the package itsself?
I'm guessing I'm missing something obvious.
Well, there are two issues at play here:
- The service architecture for finding the "actions" that you can do
with a package. Today each subclass of SMInstaller is queried if it would like to handle package x and the first one that says yes gets to supply "download" and/or "install". So if you don't have the installer already installed - how does it raise its hand and say "Yes, I can handle this package!". The future architecture that I have started fiddling with collects services from registered "package handler objects" instead - the services can be anything and there may be services from multiple handlers. Anyway, the problem is still the same.
- When thinking more this is actually not a normal dependency. In the
planned SM 1.1+ people will register "package configurations" with the dependencies for *using* package x. Not the dependencies for *installing* it. I think these two things are different - for example - the installer can easily be uninstalled after it has done its work - a "normal" dependency can't be.
So, what do we do? Well, after thinking about 20 seconds I am not sure I would like to use "normal" dependencies for this. And it does feel like overkill to introduce some other dependency structure just to handle installation. I think perhaps we should be a bit more strict when it comes to "Package type" - perhaps making it mandatory. And given this we could perhaps map to at least a default installer package. I am not sure..
I need to get a new revision of SM out - if you have any bright ideas regarding the above I am listening.
regards, Gsran
-- julian@beta4.com Beta4 Productions (http://www.beta4.com)
Daniel Vainsencher wrote:
No, I'm proposing this only for installers, and that only as halfway measure for all those relatively simple packages that you can't install only for lacking the proper service.
This is definitely NOT a proposed replacement to having configuration package types that encapsulate things like dependencies (though the idea of a reflective service that uses SM itself might be useful in other contexts too).
I personally don't think we should model dependencies directly. If Goran's view of configurations is "I assert that the RB 1.2 works with PackageInfo 3.4", then my proposal is the agnostic "Loading PackageInfo 3.4 and then RB 1.2 and then ... is good".
This could obviously be used to make sure both dependencies and proper scaffolding is installed before any specific package.
This handles any depth dependencies in one configuration, and also allows composition of configurations to make packaging modular.
Does this seem reasonable?
Yes, I had somewhat forgotten that we were thinking of configurations and not of individual dependencies. It seemed reasonable when Goran explained it to me at OOPSLA and still does... just that I'd forgotten :)
I was pretty sure you were only talking about installers, but I wanted to make sure.
Goran, configurations are associated with package *versions* I assume? So I can say in a configuration for Seaside, for example, that Seaside works with Comanche 5.0 and then any valid configuration for Comanche 5.0 would meet that requirement?
Julian
Julian Fitzell julian@beta4.com wrote: [SNIP]
Does this seem reasonable?
Yes, I had somewhat forgotten that we were thinking of configurations and not of individual dependencies. It seemed reasonable when Goran explained it to me at OOPSLA and still does... just that I'd forgotten :)
:-) Need to write that down somewhere permanent.
I was pretty sure you were only talking about installers, but I wanted to make sure.
Goran, configurations are associated with package *versions* I assume?
Exactly. I call them "package releases". There is a new class called SMPackageRelease in SM 1.1.
So I can say in a configuration for Seaside, for example, that Seaside works with Comanche 5.0 and then any valid configuration for Comanche 5.0 would meet that requirement?
In the SM 1.1+ that I envision the answer is yes, at least if you mean "in a configuration for Seaside version x". Package configurations are per "package release".
Big sidenote:
SM1.1 which I am working HARD on (I started refactoring a LOT to make it simpler etc) will introduce most importantly SMPackageRelease. It will also introduce 2 more things that you can register on SM making it a grand total of 3 (or 4 counting SMPackageRelease but they are part of an SMPackage):
1. SMPackage (formerly known as SMCard, holds an OrderedCollection of SMPackageRelease) 2. SMResource (Similar to the current SMCard in that it knows its current version but no releases. A resource is meant to capture anything that is NOT a package - it is typically a downloadable "something".). 3. SMPerson (one of the few things that isn't an SMReource. :-)
Now - where are the "package configurations" I have been talking about? Aha! They aren't there! :-) I instead put down the foot and said - "No, SqueakMap ends HERE." and created SMResource instead.
So my upcoming model for dealing with dependencies through "package configurations" will be a layer *on top* of SqueakMap and the "package configurations" will be registered in SM as SMResources that are then linked (using SMLink - a new thing) to the SMPackageRelease they refer to.
One very nice property of this is that we don't build a model for dependencies into SM. If someone else can implement something cooler than my model then the playfield will still be open.
regards, Göran
squeak-dev@lists.squeakfoundation.org