On Jul 7, 2005, at 6:16 AM, Bert Freudenberg wrote:
Am 07.07.2005 um 08:35 schrieb Andreas Raab:
Any suggestions on how I should implement this? I guess we could just have a method defined somewhere (in the load-updates code) which has a hardcoded, ordered list of the 35 package names. I guess this list won't change very often. (The 3.9a-6676 image doesn't seem to be hanging onto the MCConfiguration instance that was loaded in update #6676, otherwise I might try to use that.)
That "hardcoded, ordered list of the 35 package names" would just be like the literal configuration that you issue as changeset (without the #upgrade call), but put into a method. It is precisely that literal representation why the configuration is as simple as it is now (compared to a full-blown MCVersion). It just defines a load order for a few packages, that's all :)
Right, sounds good.
I haven't tried adding this yet to the update stream.
This may become obvious when I look into it, but I assume this MC configuration will load the very latest versions of each package, not necessarily the specified versions? (That's what I was looking for... a simple "load order" configuration and not a configuration that only loaded specific versions.) I think that's what the #upgrade does if I remember right, but I'll have to try it.
I assume the CProjectBuilder class below is in a particular Tweak package. Meaning that if you wanted to change the list of packages in #defaultConfiguration, the #defaultConfiguration method in that package would be updated. (In other words, that particular package would sort of store the configuration.) But I guess it wouldn't change that often, if it was simply used for the load order (and didn't have to be updated every time one package in the list bumped versions).
- Doug
What we've done so far is to have a global which stores the latest version of a configuration and then just works issuing a "updateFromRepositories". It's very simple stuff - if you are curious check out CProjectBuilder>>loadUpdates and updateFromRepositories.
Yep, this works nicely in Tweak. Pasting the methods below for easier reference. I stripped out the progress display and logging.
loadUpdates TweakUpdateStreamManager loadUpdates. "from update stream" self updateFromRepositories.
updateFromRepositories | map | map := self defaultConfiguration. [map updateFromRepositories. map upgrade. DefaultConfiguration == nil] whileTrue. "repeat if we have a new map"
defaultConfiguration ^DefaultConfiguration ifNil: [ DefaultConfiguration := MCConfiguration fromArray: #( ... )]
There is a hook to set DefaultConfiguration to nil whenever the #defaultConfiguration method is recompiled (but this relies on Tweak semantics). Alternatively, you might have a class-side #initialize method that contains the new configuration, so it would automatically get overwritten after an update, and you test for map identity in #updateFromRepositories rather than testing for nil.
The call to #updateFromRepositories in #loadUpdates might possibly be guarded by a "bleeding edge" preference. That way, normal users only would get the "stable" configuratons explicitly posted to the stream, while the system developers would get all the latest packages from the repository.