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

[Alec Mitchell]

On 11/15/06, Tres Seaver <tseaver at palladion.com> wrote:
> -----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:
> >>> 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).
> >
> > OK, so this seems like another argument for not updating the toolset
> > registry whenever the "active" profile changes.  This is really the
> > sole source of the problem here, and it seems that making something
> > "active" shouldn't really have side effects, especially if it's really
> > a non-essential operation.  Is there any reason why setImportContext
> > needs to make the call to  self._updateToolsetRegistry?  The toolset
> > import step already does this for the relevant profile.

The above is my primary concern (my only concern really).  Would it be
acceptable to make this change?  If we remove this call, the only time
the toolset registry is changed is when a toolset import step is run,
which seems very sensible to me at least.

...

Thanks,
Alec