Yet Another Dependency Proposal: Packages and PackageVersions, that is it

goran.krampe at bluefish.se goran.krampe at bluefish.se
Wed Nov 19 12:08:02 UTC 2003


Markus Gaelli <gaelli at emergent.de> wrote:
> Hi Gö(!)ran,
> 
> (finally I got that right ;-)

Thanks! :)

[SNIP]
> >> If that works, fine, you can just store that as a new version.
> >
> > Store "what"? A map or something?
> No maps. Just a new PackageVersion. See example below.
> >
> > In my model you would instead do either:
> > - Store new package configurations for selected package releases.
> > - Store a load script consisting simply of the package releases you 
> > know
> > have loaded.
> >
> >> Here again that boring SmaCC-Development example to illustrate
> >> some possible usage:
> >>
> >> Package(SmaCC-Development) >> versions
> >> 	-> #(
> >> 		PackageVersion(SmaCC-Development 1.2)
> >> 		PackageVersion(SmaCC-Development 1.1))
> >>
> >> PackageVersion(SmaCC-Development 1.2) >> prerequisiteVersions
> >> 	-> #(
> >> 		PackageVersion(SmaCC-Runtime 1.1)
> >> 		PackageVersion(RB 1.7623) ...)
> >>
> >> Package(SmaCC-Development) >> untestedLatestPrerequisiteVersions
> >> 	-> #(
> >> 		PackageVersion(SmaCC-Runtime 1.1)
> >> 		PackageVersion(RB 2.0) ...)
> >>
> >> Note that you could try to automatically load the newest/best(?)
> >> versions of
> >> a Package based on this (computed) untestedLatestPrerequisiteVersions
> >> (RB 2.0 instead of RB 1.7623):
> >>
> >> Package(SmaCC-Development) >> loadWithUntestedLatestPrerequisites
> >> 	-> loads #(
> >> 		PackageVersion(SmaCC-Development 1.2)
> >> 		PackageVersion(SmaCC-Runtime 1.1)
> >> 		PackageVersion(RB 2.0))
> >
> > This sounds like my "package configurations" but you have limited then
> > to only two.
> Which two? Now I don't understand. Maybe I should have said explicitly 
> that
> PackageVersions can act as "ConfigMaps", so we wouldn't need ConfigMaps.

I meant the (1) "prerequisiteVersions" and (2)
"untestedLatestPrerequisiteVersions" but now I see you wrote "computed"
about the last one. I assume you compute that list by taking the latest
release, looking in there - and then picking the latest release of each
of the package releases listed.

Can't really see the big "point" with that part. I mean, the dependency
resolution engine can calculate such proposals on the fly.

> Say if Torsten Bergmann is creating a Developer-Package, he just says on
> which versions of RB, LookEnhancements... this would work. And versions 
> this
> "Developer-Package". No need for configmaps.

And what if I discover it works with other releases too? Can I then make
yet another release of Torstens package? And is that a fork? And what
happens to all other package releases that depends on Torstens release,
they suddenly points to an old release - thus you get "cascading
changes" which will simply create a big soup of releases that are only
meant to "adjust" the dependency information.

> >> A PackageVersion can include code but does not have to do so,
> >> as its prerequisiteVersions can.
> >> Have I overlooked much? Is this far away from Gorans ideas?
> >
> > I think it is close - with the exception that you have limited the
> > numbers of configs to two,
> again, unclear to me...

Well, anyway - I take back that it is "close". :) You want to put
dependencies inside the package so that changing them inevitable leads
to a new release. I don't. You also want to only record one single list
of prereqs instead of allowing for multiple such "lists". I don't.

So the models are quite different.

> >  and that you still want them to be a part of
> > the package release.
> Indeed.
> > Note that in my plan they are more like
> > "attachments" to the package release - so attaching one does not force
> > the package release to be released again. This is IMHO important. The
> > package release should IMHO - and isn't that actually obvious? :-) -
> > ONLY be released anew if the CODE of the package has changed. Isn't 
> > that
> > what a release MEANS? :-) Making releases that are exactly like the
> > previous ones seems so very wrong to me.
> I think of releases as of breedable eggs.
> So I can release an egg, either because I laid a new kind of
> egg in the pine or because I found out that a certain egg is also
> breedable in oaks and not only on pines. For me it seems CLEAR :-)
> that the environment of the egg is as important as the egg itself.

Importance has nothing to do with it IMHO. When I release something it
is CODE that I release. :)
I don't want to be forced to do releases just because I need to adjust
the knowledge about the dependencies. Simple as that.

I also want others to be able to help me adjust that knowledge, but I
don't want others to be able to do releases (unless I have given
co-maintainership of course).

> Gack, gack and best regards,
> 
> Markus

regards, Göran



More information about the Squeak-dev mailing list