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