Hash: SHA1

Alec Mitchell wrote:
> On 11/15/06, Tres Seaver <[EMAIL PROTECTED]> wrote:
>> Hash: SHA1
>> Alec Mitchell wrote:
>>> Tres,
>>> What are your feeling about this?  Is there a reason not to jettison
>>> the toolset registry, other than backwards compatibility?
>>> Thanks,
>>> Alec
>>> On 11/14/06, yuppie <[EMAIL PROTECTED]> wrote:
>>>> Hi Alec!
>>>> Alec Mitchell wrote:
>>>>> So I've recently run into a bit of a problem involving the extension
>>>>> profiles and the toolset registry.  The issue is that if I install an
>>>>> extension profile that overrides one of the tools from the base
>>>>> profile, then switch back to the base profile (but not run any steps),
>>>>> then switch to another extension profile that provides a toolset step
>>>>> (which has no mention of the tool overridden in the first extension
>>>>> profile), the tool from the base profile will replace the tool from
>>>>> the first extension profile, even though the base profile was never
>>>>> re-installed and the second extension profile makes no mention of this
>>>>> tool.
>>>> I personally just ignored the toolset registry because I never needed it
>>>> and it never did get in my way.
>>>> The issue you describe is annoying. Instead of working on a fix I'd
>>>> prefer to rip the toolset registry out. But maybe Tres knows why the
>>>> toolset registry exists and why it is still useful.
>> I don't think the registry is redundant:  it enables some
>> "bootstrapping" that would otherwise require writing procedural code.
>> Essentially, the overall "meta-profile" is defined via the three
>> registries:  required / forbidden tools, import steps, and export steps.
>> IIRC, extension profiles are not properly *supposed* to override the
>> base profiles tools, precisely for this reason.  They are not really
>> designed to be "reversible" either.
>> The "add-on" use case people are trying to shoehorn into extension
>> profiles is not really appropriate, especially if "reversion" becomes
>> part of the deal.
> In this case reversibility is not the issue, and I don't think we're
> expecting it.  The problem is that the tools that are loaded when a
> toolset step is run are not those specified in the current active
> extension profile, but rather a combination of all of those in every
> profile that has ever been made active, regardless of whether the
> steps of that profile were imported or not.  This seems pretty
> inconsistent with the way that all the other import steps work.
> Perhaps the toolset registry should only be updated when the toolset
> step is run, not whenever a profile is made active?

We really shouldn't have to make an extension the "active" profile in
order to apply it to a site (and in fact, the new "tarball upload"
feature allows applying an uploaded profile wiithout it).

> Add-on products almost always make changes to skins, actions,
> properties, registries, and other things under the purview of GS.  It
> would be a shame if such products can't easily use the very convenient
> mechanisms that GS provides to do so.

That's what they are *supposed* to do.  Changing the "meta profile" is
*not* something which extensions are designed for.

- --
Tres Seaver          +1 202-558-7113          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to