cg at cdegroot.com (Cees de Groot) wrote:
>  <goran.hultgren at bluefish.se> said:
> >You just said "if available" which sounds optional to me! :-)
> >
> The optionality refers to the availability of tests, not to running them if
> available.

Ok.

> >Well, it feels a bit weird to me. If I want to produce a minimal image
> >those tests are - no matter how nice and secure they make me feel -
> >simply baggage during deployment/runtime.
> >
> Remove all subclasses of TestCase and all classes starting with Mock... and
> you're a long way. Other resources may be included in a manifest file in the
> SAR so an image stripper can find them.

No! Stripping is what we want to stop doing. I would go for having tests
either as a separate filein (inside a SAR) which can then be removed
(DVS is going in this direction - they have some rudimentary uninstall
working I think) or having them as a separate package which typically
can be pointed out by the package as being "my testpackage".

> >Actually, even though most packagesystems do include the dependencies
> >inside the package we (especially Daniel and I) are opting for
> >externalizing this as a "package configuration" which there may be
> >several for a given package release. 
> 
> That means that you unify the package distribution and package contents
> method. E.g. when I obtain a package outside SM, the package wouldn't have a
> way to verify whether the environment it lands in is the correct one
> (important for off-line situations). Therefore, I think you need the
> dependency information in both places, so that the package can check its own
> environment once it starts installing into the image - independent of how it
> arrived there. 
> 
> It's probably similar to the double validation you often end up doing in the
> user interface and the business model: the UI validation is there to help the
> user, and the business model validation is there to keep the business model
> correct. SM dependencies would be helping the user, while package-internal
> independencies are necessary to keep the image consistent.

Well, you have a point - but I still think it would be better to have
them separately.
Note also that SM handles "off line" pretty good - the map is in a
single file and can be loaded directly from it - no need at all to be
online. So if you have 134 package files then you just need one more
file to have all the dependency information - the map file.

And I typically think that dependency management should be handled
declaratively (not as running scripts inside the packages) as much as
possible - otherwise we can not have "global" analysis of dependencies
and conflict detection.

> >"Spaghetti tracer 1.0 has been verified by Daniel Vainsencher to work
> >with prerequisites DVS
> >1.34 and Connectors 1.3 on top of base image 3.2."
> >
> Are you planning to have multiple such 'statements' on packages? Like:
> "Spaghetti tracer 1.0 has been verified by Cees to work with DVS 1.35 ..."
> " ... by Goran to work with DVS 1.34 and Connectors 1.45 .."
> etcetera?

Exactly. These are verified working environments for the package release
in question.
The maintainer may typically know best, but not necessarily all possible
working setups.

> >(this last part is
> >interesting. I haven't decided but it seems to me that base images could
> >be considered as some kind of package. They have releases, they can be
> >downloaded, you can depend on them etc. This would in that case unify
> >this last step with step 2)
> >
> CPAN treats the Perl distribution as just another package. It's annoying
> sometimes, because it happens that you download a package with Perl 5.x, and
> the package has a prereq on Perl 5.y (y > x); CPAN reacts by downloading,
> configuring, and installing the new Perl distribution. I don't know whether
> that is the useful behavior (probably better to say "you can't do that on
> Squeak 3.1").

Yes, I am not sure either. Need to think a bit on this one. Handling
them *exactly* as packages is obviously stupid - I mean hey what do we
have inheritance for? ;-)

> >4. When a new configuration is discovered or when a dependency needs to
> >be added we don't need to release a new version of the package itself.
> >
> That is an advantage, of course. It's also all a matter of trust: if the
> author inside the package states 'A' on dependencies and tested platforms, and
> two people on SM state 'B' and 'C', who do you trust? How do you automate this
> (when fetching chains of dependencies)?

Yes, this is why a package configuration has a person signing it (well,
not digital signing - perhaps later). This gives the user the
possibility of saying "Load package X, latest version being at least at
beta level, with prereqs recursively and only trust configurations from
the package maintainers."

Since we may have multiple valid package configurations multiple
solutions can be found - ask the user for directions when needed. This
is also where another mechanism I have in mind comes in - the
compatibility level of a new release in regard with the previous
release. More on that another time.

> >Anyway, my main point here is that I actually think a package should be
> >minimal in this respect and having the package configuration as a
> >separate entity gives us more flexibility but at the same time it is
> >quite simple to understand.
> >
> With, IMHO, the explicit trade-off that, given the likelyhood that SM
> will in due time be too large to download, off-line configuration is
> not possible anymore.  Plus the assorted trust issues to be resolved...

Hehe, when the map is THAT large, then... We have come up with far
better solutions I think. :-)
The current map is compressed 24kb. And that is 40 packages. Lets say we
have 10000 packages.
That would be... 6Mb I think. I am not worried. :-)

> (I'm ok with the trade-off, just as long as the decision is made consciously
> ;-))

I agree. Well, we will have some time to discuss this - I am not rushing
this next step, it is too important for that.

regards, Göran