-----BEGIN PGP SIGNED MESSAGE-----
Alec Mitchell wrote:
> On 11/15/06, Tres Seaver <[EMAIL PROTECTED]> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> Alec Mitchell wrote:
>>> What are your feeling about this? Is there a reason not to jettison
>>> the toolset registry, other than backwards compatibility?
>>> 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
>>>> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v188.8.131.52 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests