Dependencies, Squeak Code Control [proposal, long] (was: [TFNR][REPORT]Where are we?!)

Peter van Rooijen squeak at vanrooijen.com
Tue Nov 18 20:29:05 UTC 2003


Goran, Stephane, et.al.,

I saw your discussion about code control: dependencies (module
requirements), package configurations, bundles, packages, etc.

I have some experience and have done some work in this area, and I thought
it might be helpful to present a code control scheme that I feel could work
well for Squeak. It's a design that is quite a bit lighter-weight than Envy
or
StORE, and much more powerful than simple class categories and variants of
that. It requires no change to the way the image works with code, yet it
provides versioning, dependency management, build control, and support for
a distributed repository.

I would be happy for this design to be used as a basis for discussion or
implementation.

Squeak Code Control Proposal

INTRODUCTION

This is a relatively simple, but not too simple, scheme of organizing code
that I have come to like after working with a few home-grown code control
systems and vendor-supplied ones such as class categories (StX, Squeak, old
VW), Envy (VA), StORE (VW) and the Dolphin PackageManager.

This scheme does /not/ introduce a concept of code (classes and methods) as
managed entities (things that have their identities and versions separated).
Looking at classes and methods as entities managed by the code control
system is not required. The code can stay in all the usual types of files.
So this is one way in which the scheme is simple. It changes nothing about
how Squeak already works in using images and image files.

THE DESIGN

1) Let's assume, to define terminology for the sake of argument, that when
talking about dependencies and configurations, we are thinking of all the
code (the classes and methods that do the actual work) that is involved as
being contained in a Module.

    - A Module is either a Package or a Bundle.
    - A Bundle contains (zero or more) Modules (composite pattern!).
    - A Package contains code = classes and methods (i.e., no other
Modules).

2) Let's note that there is a versioning aspect to this domain. When we talk
about a Module (a Bundle or a Package), we actually have two notions to deal
with:

    - The Module identity (the thing that groups all its versions).
    - The Module version.

[When we talk about Module, Bundle or Package, we often /implicitly/ mean
either the identity or the version. When devising a code control system, we
must actively keep the distinction in mind, and I will do so in the rest of
this proposal.]

3) Module Requirements and Configurations are declared things (someone
defines them, as opposed to them being dynamically derived), which both
describe relationships between Modules (Configurations additionally describe
relationships involving Maps and Modules - see below).

    - Module Requirements describe dependency relationships between a
(requiring) Module /version/ and the (required) /identities/ of other
Modules.

[Calling these relationships Module Requirements (i.e., not "dependencies")
allows talking about "requiring" and "required" modules as specified by a
Module Requirement. Module Requirements are also very specific things
whereas dependencies can be understood more as a broader concept that Module
Requirements address.]

    - Configurations describe relationships /between versions only/.

[Module Rrequirements are semantically different from Configurations and
they express different concerns"

    - Module Requirements express what Modules are (thought to be) required
for the the declaring Module to function correctly. Multiple versions of a
particular required Module may work, so a Module Requirement points from a
requiring Module /version/ to required module /identities/.
    - A Configuration expresses exactly which code will be installed when
the Configuration is loaded into an image. So, a Configuration points only
to Module /versions/.]

4) In order to be able to describe the code state of a whole image, which
contains multiple Modules, we need a higher-level managed entity than the
Module. Let's call this a Map. A Map is a managed entity with separation
between its identity and its versions. A Map version has a Configuration
(remember: Configurations are exact and point only to versions). The
Configuration of a Map points at zero or more versions of Modules (Bundles
and/or Packages) and zero or more versions of other Maps.

5) All managed entities (their identities and their versions) can be stored
persistently in a repository, completely separate from any images.

So, a repository contains:

    - Maps (identities and versions), with each Map version having a
Configuration.
    - Bundles (identities and versions), with each Bundle version having a
Configuration and a Module Requirement.
    - Packages (identities and versions), with each Package version having a
Module Requirement. Each Package version also knows the location of its code
(classes and methods).

[The code of Package versions may be stored in external files, a local or
remote database, somewhere behind a URL, whatever. We can only hope that the
code will indeed be found there, but even it isn't, the functioning of the
repository itself will not be hindered by that, merely the ability of
loading the code for that particular Package version]

Comments are welcomed.

Regards,

Peter van Rooijen
Amsterdam




More information about the Squeak-dev mailing list