Dependencies, Squeak Code Control [proposal,
long] (was: [TFNR][REPORT]Where are we?!)
stephen at pairhome.net
Wed Nov 19 14:07:18 UTC 2003
goran.krampe at bluefish.se wrote:
>Stephen Pair <stephen at pairhome.net> wrote:
>>gohu at bluefish.se wrote:
>>>Anyway, I hope the above model seems simple and capable. It is much like
>>>Stephen's (but configs don't have versions and can't refer to other
>>>configs - would be interesting to hear Stephen's words on that).
>>[Lots of stuff snipped...see previous email for details about the model]
>>Now this sounds interesting...as I had thought about configurations, it
>>bothered me that it seemed every package would also have a configuration
>>(i.e. you would have a KomHttpServer package and a KomHttpServer
>>configuration). With this model, that no longer is an issue. However,
>>I think you still need a mechanism for naming a configuration so that a
>>configuration can be easily referenced (i.e. if Seaside 2.1's three
>>configs were named A, B, and C, then you would refer to conf A as
>>"Seaside 2.1 configuration A")...or, were you planning to use UUIDs or
>They will both have UUIDs and names. And actually also a "version" field
>- but that is only as in SM1.x - meaning that it knows its *current*
>version, but nothing about older versions.
>As you can see a config describes ONE possible setup for one specific
>package release. Since the releases will be immutable (not enforced, but
>I assume we all will abide) a config can only be "correct" or
>"incorrect" - meaning that there is no point in remembering an old
>version of a specific config.
>Btw, I also realized that one way of looking at all this is that the
>configs are "inside" the package releases - well, not inside the actual
>file holding the code - but surely "inside" the SMPackageRelease object
>in the map. Meaning that they aren't shared by others etc.
>>But, another use of configurations (that you may not be accounting for)
>>is to specify some arbitrary grouping of packages that you want to load
>>together and use. Such configurations might not be naturally associated
>>with any single package. For example, I want a configuration that loads
>>both Seaside and HttpView together...would I attach that to Seaside? or
>>HttpView? Or both?
>I can see two solutions - either a "virtual package" that has no code,
>but has configs attached.
>Or a load script.
>Personally I think this isn't really a config - because it doesn't
>specify package releases that are *needed* to ensure some other package
>release works. So we would be "abusing" the model a bit.
>A load script on the other hand seems pretty perfect. :) And sure, if we
>would like to introduce a more "declarative" object for this - we can do
I think you need to be careful that "load scripts" and "configs" are
sufficiently different animals that you're not just replicating
everything a config does in a load script. For example, I will want to
simply select one or more configs and say "load them" without needing to
define a load script. Conversely, when I do define a load script, I'll
simply want to identify one or more configs and perhaps packages to load
(together with an ordering of those things). Will a config carry enough
information (i.e. a load order) such that a load script could be created
on the fly for a config? Perhaps you could elaborate on exactly how you
envision load scripts working.
If package A has a config that specifies KomHttpServer 6.2, does that
also imply all pre-requisites of KomHttpServer 6.2? If so, do you need
to be explicit about which KomHttpServer 6.2 config you are talking
about when specifying the config for package A? Or, does a load script
do that? For example, would the load script specify package A (and some
config), KomHttpServer 6.2 (and one of its configs)? If that's the
case, then configs don't really specify a completely working assembly of
packages (i.e. certain configs of KomHttpServer 6.2 may not work with
package A's config).
It seems to me that your definition of a config may really just a
listing of immediate pre-requisites for a package. Which, in
combination with load scripts and good load tools, might work. Not sure
I would call these "configs" though.
More information about the Squeak-dev