Re: A bit about SM1.1 and dependencies

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

[email protected] wrote:
> Daniel Vainsencher <[email protected]> wrote:
> > [email protected] wrote:
> > > Daniel Vainsencher <[email protected]> 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
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Thu Feb 13 02:58:27 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 1394 invoked from network); 13 Feb 2003 02:58:26 -0000
Received: from mailout.whidbey.net (HELO mail.whidbey.net) (209.166.64.124)
  by mail.theinternetone.net with SMTP; 13 Feb 2003 02:58:26 -0000
Received: from vdsl-72-234.whidbey.net ([209.166.72.234] helo=ned)
	by mail1 with esmtp (Exim 4.12)	id 18j9Yw-0004zO-00
	for [email protected];
	Wed, 12 Feb 2003 18:57:23 -0800
From: Ned Konz <[email protected]>
To: [email protected]
Date: Wed, 12 Feb 2003 18:58:03 -0800
User-Agent: KMail/1.5
X-Image-URL: http://bike-nomad.com/nedicon.jpg 
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[email protected]>
Subject: [Squeakfoundation]identifying existing apps to package
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2003 02:58:27 -0000

I'd like to start the packaging process for parts of the 3.5 image, as 
planned.

I know Daniel and others have written tools for static analysis; I was 
hoping someone could come up with a good way to actually discover the 
contents of the different packages (strongly coupled clusters of 
otherwise independent classes along with class extensions that they 
use or that refer to them). Plus, I'd like to get the names of the 
major writers of the existing code.

Ideally, this is something that we'd apply to an image that has as 
many change sets in it as possible (to get the historical version 
information). So if someone has (say) a 2.8 image that they've 
updated all the way to 3.5a, it would be the ideal test case.

I'd like to come up with a table in HTML that lists:
* Category
* Class names
* Major authors
* Last period (quarter year?) in which substantial changes were made
* Outside dependencies

And I'd like to do this automatically, if possible.

Then we can start signing up volunteers to pick these apart.

Once we have tools and HOWTO manuals on package stripping, we should 
be able to get more volunteers.

Some relatively easy targets that I can see:

* Speech
* Fabrik
* Games
* Piano Roll
* Process Browser
* Archive Viewer
* eToy communications and Nebraska
* Scamper
* VM Construction

Harder ones:

* Genie
* Active Books
* eToys
* Browsers
* File List
* MVC
* Morphic

Any ideas?

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE