Dependencies, Squeak Code Control [proposal,
long] (was: [TFNR][REPORT]Where are we?!)
Stephen Pair
stephen at pairhome.net
Wed Nov 19 04:20:34 UTC 2003
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
something?
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?
Perhaps configurations should live on their own and the list of
configurations for a given package is simply any configuration that
includes that package (rather than have an explicit relationship
there). A simple query can give you all the configurations for a given
package (you might add additional filtering options, such as
ranking/sorting configurations by maintainer, popularity, ones that
include the most recent package versions, etc). You could make it
optional to give a configuration a name and version number (otherwise,
it could be identified by UUID). In the context of configurations, a
version number is really more of a convenience for us humans (it allows
us to group similar configurations together under the same name).
As for a configuration being able to specify other configurations, it's
probably not necessary, but a tool that would allow you pull in
(subsume) all the package versions from another configuration when
defining a new configuration would be useful. It might even be
preferrable to allowing configurations to specify other configurations.
With Envy I find that when you start to get a tree of config maps, you
most often end up synchronizing the versions of all the required maps
with your top level map...when opening up maps for development, it keeps
the timestamps in sync (making it easy to see which config maps are
related to a given stream of development) and when versioning, you
version the maps all the way down with a given version name. Thus, the
lower level config maps will tend to have different versions for each
higher level config map for which it is a required map. You may as well
just subsume the lower level config map's package versions into the
higher level config map and just version it (but if you need to maintain
the lower level maps in sync with the higher level config maps for the
purposes of independent loading, then you'll need version the lower
level config maps, then subsume those into the higher level config
map)...basically, I think it's a wash either way, but not allowing
nested configurations does force you to deal with and correct any
inconsistencies up front (in Envy, you can have multiple required maps
that may have different versions of the same application released, thus
creating an inconsistency).
One additional thought: by not keeping any pre-requisite information in
the package itself (not even a listing of pre-req declarations) you are
able to handle situations where a pre-requisite morphs from a single
package into multiple packages. Here's an example:
WizBangTcpService 1.0 owned by xyz
(Comanche 5.1) owned by xyz
WizBangNetService depends on Comanche for two things, its service
management capability, and its packaging enhancements. Now lets suppose
that Comanche gets refactored into several smaller packages rather than
one large one...we could add the following configuration:
WizBangTcpService 1.0 owned by xyz
(Comanche 5.1) owned by xyz
(KomPackaging 1.0, KomServices 1.0) owned by xyz
The fact that we've not declared or even enumerated the package
pre-requisites in the package itself allows us to handle this situation
cleanly. And, I expect this situation to happen quite often as we get
better and better packaging tools.
- Stephen
More information about the Squeak-dev
mailing list
|