Ah, I see what you envision now. I don't actually see changing the configuration package as a problem - I do trust you'll give an api to do this soon, and then code can do it for me. And as you say, it might be wise to have alternative configurations for the same package. There's no conflict - the alternatives can certainly live inside the package.
We agree the depedencies should be outside the code packages, the difference is whether to keep them in a "special place" - resources, or in packages themselves.
Simplest thing that could possibly work?
It is not what I want to have for resolving complex dependency networks. They are two different things and they are needed both IMHO.
Aha - we may be addressing different requirements. I'm addressing precisely this problem - I want packages to be modular, I want users to be able to load a package with it's prerequisites, I want maintenance of configurations to be separate from maintenance of code. Either solution does all of these (haven't changed my mind about any of these).
I'm not looking for anything more complicated, among things because I'm hoping to make a working release within days of having an SM that supports package releases, for many good reasons mentioned before.
What additional needs are you addressing? (elaborate on complex analysis...)
And I don't see many ways to go around that...
What? I didn't understand this.
I'm simply pointing out that when a code package is updated, a human will have to evaluate it to update the configuration. That's the main thing humans maintaining configuration (not code) will have to do, and that's the same between both proposals.
How that translates to changes in the metadata itself, I don't care much about - it can be mechanized, either way.
I think the models we're proposing are very similar, mine is just minimal and maybe a little crude, but I think it can take us a pretty long way.
And the two systems can definitely coexist, and probably even interoperate (you can depend on my kind of package, a vice versa).
Daniel
goran.hultgren@bluefish.se wrote:
Daniel Vainsencher danielv@netvision.net.il wrote:
goran.hultgren@bluefish.se wrote:
Daniel Vainsencher danielv@netvision.net.il wrote:
Ok, just to show what I mean. Suppose I make a package type that holds a single method that goes something like ^#((RBModel 1.09) (RBGUI 1.06) (RBTests 1.05))
Then I write a service that loads this kind of package, and does packagesList collect: [:packagePair | SMSqueakMap loadPackage: packagePair first version: packagePair second].
Or maybe something a little more complicated, but you can see where I'm going... I don't need much more support.
Ok, this looks to me like "virtual packages". A package that has no content and loads specific versions of other packages. In fact - this is a "static load script" given my previous terminology. (Static in the sense that it will always result in the same package releases being loaded)
Not exactly - note that the code interpreting the list is outside the list, in a service. The code here is just a way to store the instructions.
Sure, but what real difference does that make? It is still a list of specific releases of other packages to be installed. Or?
But this plan doesn't AFAICT make it possible to have multiple possible configurations for RB. I assume that the virtual package/load script you described above would be "RB".
Actually it does - there's nothing stopping me from concurrently also publishing another package that also specifies the RB Components, at different versions. For example - ^#((RBModel 1.1)(RBGUI latest)(RBTests latest)(RBRewriteRuleEditor latest))
Sure, I understand that you can publish several different "load scripts". But that would in fact be *different* packages. Of course you would give them names like "RB cool" and "Another RB" etc. But that wouldn't help the dependency engine at all.
Let me reiterate: I want to be able to have different working configurations for one specific package release. For example, one "certified working configuration" is that RB1.2 works if SmaCC1.1 and SUnit3.3 are in the image too. BUT... RB1.2 may also be able to work just fine with SmaCC1.2 and SUnit3.3. That is another fully valid configuration for RB1.2.
The idea here is that an engine can analyze these multiple configurations. And adding a new configuration (registering a Resource and linking it to RB1.2) does not change the version of RB.
could represent the right configuration for someone that want to play with the latest GUIs, but using a known stable model. The two can definitely coexist - each is it's own package (I don't know what you mean by virtual), and even be authored by different package maintainers.
Yes, I fully agree that this is useful for exactly the thing you describe. But that is a "load script" package. It is not what I want to have for resolving complex dependency networks. They are two different things and they are needed both IMHO.
It would also mean that you need to make a new version of RB if you want to change the dependencies for RB - so you get "cascading version changes" - package Y is released in a new version and X depend on it so must also be released in a new version etc. etc.
No, why? The only time I'll have to update depedencies, is when I have a stable configuration, and I've decided that a newer version deserves to be point to in it. And I don't see many ways to go around that...
What? I didn't understand this. Ok, let's say you have registered a "load script" called RB version 1.0 that contains information about what other package releases should be loaded - package X1.1 and Y3.4.
And then I release package X in version 1.2. You realize that, hey - RB works dandy with this newer release of X. So what do you do? Ah, you need to *change* package RB. And if you change it then you better change the version too.
In my scheme you would simply just register another configuration and link it to RB1.0 - this simply says: Hey, I just tested RB1.0 with these packages too and it still works. So the dependency engine now has two working versions of X that it can choose from without making RB1.0 go bonkers. And that is very good since package Z that I want to use together with RB1.0 may actually *demand* X version 1.2.
Well, I have been describing these things so many times now that I simply need to implement them. :-)
I mean - it was you who pushed me in this direction by saying that the dependency information should be *outside* the packages in order to be able to have them evolve independently. Those emails we exchanged has influenced my model a lot. And now you are arguing IMHO in the opposite direction. ;-)
Sidenote: I did run my model by Roel Wuyts, Doug Way, Stephen Pair and several others I can't remember right now at OOPSLA and they all liked it. This also included the draft on how the dependency engine will use this information to resolve complex situations and my concept of "stretchable dependencies".
regards, Göran
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Daniel Vainsencher danielv@netvision.net.il wrote:
Ah, I see what you envision now. I don't actually see changing the configuration package as a problem - I do trust you'll give an api to do this soon, and then code can do it for me. And as you say, it might be wise to have alternative configurations for the same package. There's no conflict - the alternatives can certainly live inside the package.
We agree the depedencies should be outside the code packages, the difference is whether to keep them in a "special place" - resources, or in packages themselves.
Well, this is not the only difference. Your model limits the number of available configurations for a certain package to 1. And no - it doesn't help that you can register more different "load scripts" - those are *other* packages. The only way to know that they are actually different configurations of *the same* package (RB in our example) is by letting a human look at the package names and guess.
And I maintain my stance that your model has the problem of "cascading versions" (well, you know what I mean).
Simplest thing that could possibly work?
I agree that "load scripts" (which we already have) and the existence package releases (which we don't have yet) would make some form of dependency management possible. But then people would actually start using that ;-) and later, when we realize that hey, this actually is a bit too simple - then we will have an interesting battle to migrate to a slightly more capable model.
I fully agree with STTCPW - but only during development. I don't really think you can apply the principle (at least not without looking at the consequences) to systems actually being deployed. Which SM is.
It is not what I want to have for resolving complex dependency networks. They are two different things and they are needed both IMHO.
Aha - we may be addressing different requirements. I'm addressing precisely this problem - I want packages to be modular, I want users to be able to load a package with it's prerequisites, I want maintenance of configurations to be separate from maintenance of code. Either solution does all of these (haven't changed my mind about any of these).
Ok, I want a bit more. :-) I am aiming (in the end) for a conflict resolution engine that given this question:
Hey, Mr Engine - can you please load me up with the latest possible Seaside, Cassowary, Magma, Traits and experimental new Collection hierarchy?
Mr Engine mumbles for a while and then answers ok, it looks feasible but I only found one configuration for Seaside that works in this scenario and that is a configuration published by Daniel Vainsencher who is not the maintainer of Seaside. Do you trust Daniel? Ok, then I will use package X1.2 instead of X1.1 that Seaside needs (because Daniel has published such a verified configuration for Seaside). Ooops, almost forgot - there are three different configurations for Magma and they all require package Y1.1 but Traits requires Y1.2. But don't worry - it seems that version 1.2 has been classified as "should be backwards compatible, only bugfixes" - would you like to take a chance regarding Traits and use 1.2?
Anyway - the above little scenario both relies on my multiple configs for packages AND the thing I call "stretchable dependencies". Didn't we discuss them earlier? I think we did. The idea that the package maintainer classifies a new release "how backwards compatible" it is. I have 6 levels written down somewhere and the first 2 are machine detectable.
I'm not looking for anything more complicated, among things because I'm hoping to make a working release within days of having an SM that supports package releases, for many good reasons mentioned before.
What additional needs are you addressing? (elaborate on complex analysis...)
Well, the description above covers it I think. I want multiple configs per package release linked to the release. Anyone can register a config for a package release. This also avoids the "version cascade problem" (btw, Resources are NOT versioned in my model). I also want the backwards compatibility classification of package releases (just a simple dropdown menu will do fine) in order to make the conflict resolution "human aidable".
And I don't see many ways to go around that...
What? I didn't understand this.
I'm simply pointing out that when a code package is updated, a human will have to evaluate it to update the configuration. That's the main thing humans maintaining configuration (not code) will have to do, and that's the same between both proposals.
Well, no. :-) (or perhaps I am daft) When I change a configuration for package X (or add one) I *do not* need to change the version of package X. But you do. Still a major difference IMHO.
How that translates to changes in the metadata itself, I don't care much about - it can be mechanized, either way.
I don't follow you. It is IMHO a big difference that I care about because it will create "ripples" in the map which in turn will make packages conflict even when they in fact don't.
I think the models we're proposing are very similar, mine is just minimal and maybe a little crude, but I think it can take us a pretty long way.
I agree in principal but I think we should aim a little big higher from the start here in order to win out in the long run. :-)
And the two systems can definitely coexist, and probably even interoperate (you can depend on my kind of package, a vice versa).
Yes. As I described before - you are simply aiming to handle dependencies through "static load scripts". Of course you will be able to do that as soon as package releases are available.
And hopefully not too many will follow your lead and produce a big complicated mess of load scripts that conflict with each other all over the place until I get my model working. ;-) ;-)
regards, Göran
squeakfoundation@lists.squeakfoundation.org