[Seaside-dev] on eliminating SeasidePlatformSupport - MonticelloConfigurations

Dale Henrichs dale.henrichs at gemstone.com
Tue Mar 25 18:06:08 UTC 2008


Avi Bryant wrote:

>On Tue, Mar 25, 2008 at 10:01 AM, Dale Henrichs
><dale.henrichs at gemstone.com> wrote:
>  
>
>> So for Squeak (and GemStone) we should come up with a tools solution
>> that eliminates load order and initialization as a factor - I suggest
>> that we choose a variant of MoticelloConfigurations and make it a
>> requirement for Squeak and GemStone (i.e., Monticello users).
>>    
>>
>> Comments?
>>    
>>
>
>Not a comment on the bulk of your message (which I think I agree
>with), but: I'm uncomfortable with MonticelloConfigurations because,
>although I've tried a few times, I've never managed to grok it or
>match my workflow to what it seems to expect.  I'm all for having
>*some* configuration tool that uses MCPackageLoader to the effect you
>describe, but I would suggest something simpler than MCConfigurations.
> For example, an empty meta-package that uses #requiredPackages to
>bring in the right ones.
>
>Avi
>  
>
I have to admit that I haven't lived with MonticelloConfigurations 
(yet), but I have been living with the meta-packaged/#requiredPackages 
model and I find that it is too brittle. I happen to work in a handful 
of images and making sure that the image I'm working in right now has 
the right version of the meta-package is very error prone and once I've 
made the mistake, I can't 'merge the meta package',  so I end up in a 
pickle ...  I am using a single monolithic configuration, but I would 
imagine that nested meta-packages would be even more brittle ...

I don't think MonticelloConfigurations are ideal, but I like the 
flexibility available with MonticelloConfigurations (I can create a 
MonticelloConfiguration with vi if I need too:), so I imagine that 
MonticelloConfigurations are a 'tool or two away' from being really useful.

Dale



More information about the seaside-dev mailing list