Hi!
I sent this email to Avi, Ned and Chris Muller as a response to Chris wonderings but then I thought I could post it here too. If you are interested in dependencies this might be interesting to read. It is about my plans for SM1.1 and beyond.
regards, Göran
-----
Hi Chris and all!
Chris Muller afunkyobject@yahoo.com wrote:
--- Ned Konz ned@bike-nomad.com wrote:
Note that the prerequisite handling in SARs is only temporary, until SqueakMap gets dependency handling.
Hmm.. I'm a bit confused by this. It seems to me that dependency definitions would be something more at the Package level. Thinking out loud - Packages
It typically is in for example RPM or deb. But that is not my current plan. :-) Well, "not really" anyway. As you will see below default information could redundantly be included in the SAR, but it should still be available separately.
have additional resources, readme's, change histories and dependencies.
Yes.
SqueakMap, on the other hand, is a cataloging system. It knows *where* packages are, *who* maintains them and, for my convenience, obtains the stream, local or network, necessary for SarInstaller to do the installation work.
Right.
So if prerequisite handling is removed from PackageInfo's and SAR utilities, then does that mean the only packages that'll be able to have prerequisites are ones cataloged in SqueakMap?
Eh, no. It could be included inside. But in order to have an engine be able to reason about dependencies without having to download the packages themselves this information should *also* be available separately. An URL will be sufficient.
Please educate me..
Ok. :-) Unfortunately I haven't written down my plan for the upcoming SM in a detailed manner - so it is not "your fault" not knowing about this. :-) I really should do this. Perhaps I will find some time for that later this week. Anyway, here goes:
In regard to dependencies (there are other things coming in SM1.1 too, but that is of less importance here) I am in SM1.1 adding these mechanisms:
1. Package releases. In SM1.1 you will first register a package much like you do today, but much of the information will instead be entered for a PackageRelease that the Package owns. So the url, the version info, the version name etc etc will be attributes of PackageRelease instead of Package. This is just simply necessary for us to be able to handle dependencies since they must be between specific releases of packages and not just the packages.
2. Links. All things that can be registered on SM1.1 will have a "link list" to other things registered at SM. This way a Package can link to another Package typically just to give guidance or whatever. But it is also a crucial capability for handling dependencies - see below.
2. Resource. This is a new beast in SM1.1. It is simply a digital resource given by a URL that is not a Package or a PackageRelease. So Resource will be the "kitchen sink" type that we can use for whatever we like. This way we can create new kinds of "additional info" and attach them (by using Links) to Packages or PackageReleases.
Ok. This is actually the only ground work I aim for in SM1.1. But hey, you say. Where are the dependencies? Aha! SM doesn't really know about them! BUT... we will be able to create dependency information and "attach" that information to the PackageReleases using the Link/Resource mechanism described above.
Given this here is my plan for dependencies that I discussed at length at OOPSLA with Roel Wuyts, Ned Konz, Doug Way and many more - especially Daniel Vainsencher on email:
On SM anyone can register a "Package Configuration" as a Resource. This is simply a list of specific PackageReleases of other prereq packages that a given PackageRelease of package X works with. This resource is then associated with the PackageRelease in question. Typically the maintainer of package X would register at least one such "working configuration".
Note that the dependency information is NOT inside the package. There is nothing stopping the package maintainer of having the same "default" configuration inside the SAR of course in order to make the SAR file a bit more "self sufficient".
But the main point here is that the maintainer of package X is not the ONLY one that can register package configurations for package X. If I find out that, hey - Magma works just as well together with package Y version 1.13 as a replacement for package Z 3.4 then I can register that configuration as a viable alternative.
Note that the registrant is visible so perhaps nobody trusts me in regards to Magma, in that case they would pick Chris suggested configuration instead.
Anyway - now the field is open. We can now construct a simple textual format (I would simply use Smalltalk) for these "Package Configurations" and then someone can build a really cool dependency resolution engine to answer the question - "Ok, I want the newest Seaside, Magm, YAXO and SIXX that work nicely together."
It would then build a dependency graph and do all sorts of smart reasoning and hopefully come up with a nice list of Package Releases including all non conflicting prerequisite packages.
The cool part of this plan is that we have maximum flexibility, SM doesn't really know anything about dependencies (as it should not), different models for describing dependencies and different resolution engines could be tested and of course - the change in known dependencies does NOT force a new package release!
By the way - the SM1.1 servers should be able to "mirror" the resources registered simply by downloading the URLs given to the server.
I hope this helped a bit.
regards, Göran
PS. Perhaps I should post this somewhere...
squeakfoundation@lists.squeakfoundation.org