[Zope-CMF] Re: GS and the Toolset registry

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alec Mitchell wrote:
> On 11/15/06, Tres Seaver <tseaver at palladion.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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 <y.2006_ at wcm-solutions.de> 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.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFW3Jf+gerLs4ltQ4RAnZeAJwNgOWt4A5AMu5Vs04M0kCvqgxz2QCdE+HP
tov8wKDXbzgS8qyQIizv0tk=
=4DxS
-----END PGP SIGNATURE-----