[Zope-CMF] Re: Base and Extension profiles

Wed Mar 21 05:55:58 EDT 2007

On 3/21/07, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> yuppie wrote:
> > Hi!
> >
> >
> > Rob Miller wrote:
> >> it may be argued that extension profiles were never meant to be used as
> >> a means for product installation.  so far, however, this strategy has
> >> proved effective, and IMO is considerably nicer than what we had
> >> before.  whether or not it was the original intent, it has become a
> >> valuable use case, and i suspect will continue to grow in usage.
> >
> > No need to argue. I'm quite sure I remember my intentions ;)
> > GenericSetup was called CMFSetup and extension profiles were called
> > add-on profiles at that time, but this is the original proposal:
> > http://mail.zope.org/pipermail/zope-cmf/2005-March/021963.html
> >
> > Supporting the installation of add-on products was exactly the reason to
> > propose this feature.

I'm not clear on when a product is deemed an add-on product and when
its not. Are the basic cmf types for Document, Image, etc add on
products? Are ATContentypes add on products for plone? Are products
that just add skin layers addon products?

If I create a CMFSite product that requires say ATVocabularyManager,
should ATVocabularyManager's extension profile (if it had one) be
folded into my base profile, or added through applying the extension
profile?

Is there a way to add extension profiles and lock them so they
effectively become part of an unchangeable base profile state? (but
see questions further down).

At the moment there is a lot of fuss when trying to create a static
base profile that reflects all the products you want to haul into a
particular site and also your own modifications. For example: fold in
an extension profile of product A to your base profile, then modify
that again to suit your own modifications (say changing default views,
some permissions for creations of the product, add another state and
transitions to workflow for that product). Now you want to upgrade A.
You are forced into a diff mode to figure out 1) what is new in
product A and 2) what were your original modifications in your base
profile, you can't simply rebuild from a base + new extension + your
own modifications.

> >
> > Nevertheless I'm not happy with the current implementation of extension
> > profiles. Using the 'skip purge' mode was the easiest way to implement
> > them, but it opened a can of worms:
> >
> > GenericSetup is not CMFQuickInstaller. Its strength is to manage states,
> > not state change procedures. In 'skip purge' mode GenericSetup behaves
> > more like a traditional installer. It modifies the site configuration
> > step by step. This encourages people to think in a procedural way. They
> > write importVarious steps and more update directives for the XML files.
> > Trying to use profiles like install scripts GenericSetup becomes more
> > and more complicated, loosing the focus on states.
>
> We sprinted on GenericSetup this past week, and hammered on this problem
> a bit.  One thing we tried to do was to break apart "upgrade" processing
> from "import" processing:
>
>   - Upgrades are procedural, messy, and therefore "dangerous".  They
>     also need protections so that they don't run more than once, or
>     maybe at all in some cases.
>
>   - Imports are state-oriented, declarative, and therefore "safer".
>     They should be re-runnable at will.
>
> In order to implement this divide, we landed the "upgrade" extension
> (with Nuxeo's permission) from CPS.  We also broke up the confusing /
> dangerous UI of the "Properties" (now "Profiles") tab, making it clear
> that the "baseline" profile was not normally replacable, and making it
> possible to import extensions without the dangerous "replace the
> baseline, import, put back the baseline" dance.
>
> This work is available on a branch:
>
>   svn+ssh://svn.zope.org/GenericSetup/branches/tseaver-bbq_sprint
>
> We (the sprint team, see
> http://www.openplans.org/projects/bbq-sprint/generic-setup-report) would
> like feedback on that branch, before proposing that we merge it to the
> trunk.
>
> > The GenericSetup way to do this would be transforming profiles, not
> > sites. Unfortunately implementing this kind of extension profile depends
> > on good diffs. Delta profiles based on unified diffs will not work for
> > this use case, they are not flexible enough. A solution might be the XML
> > diffs Matt offered to contribute:
> > http://mail.zope.org/pipermail/zope-cmf/2007-February/025570.html
>
> I don't yet understand how such diffs would be represented, much less
> implemented.  I do agree that the current line-oriented diff format is
> probably too fragile to use as the basis for a DeltaProfile,
> particularly if we continue to generate export XML using ZPT (an etree /
> objectify model would likely produce more normalized output).

I don't either at the moment.

At the moment it is more a conceptual algebra. For example, a usecase such as:

Site 1 has product A, B, and C as part of its base profile and the
developer wants to remove product B. If you have a version of the
extension profile that you based your folding in of B in the first
place, and you have that profile available (and the same for A and C -
since they may share steps) and a diff mechanism, then you could
figure out the transformation required to get back to a site profile
without B. The algebra in this case would be something like:

newsiteprofile = currentsiteprofile - B +
union(intersection(A,B),intersection(C,B))

If however a, b, and c, were applied as extension profiles and did not
infect directly the siteprofile resident on the fs for that site
product, then you could have instead:

newsiteprofile = orginalbaseprofile + A + C + localmods

where originalbase was the site profile with no add ons (whatever they
are defined to be), and A, B, C, and localmods are all versioned.

But this all may just be a byproduct of the current state of things in
the wild where:
1) it is hard to figure out what is different between two profiles
(most often when exporting profiles after quickinstalling products(in
plone) that have no extension profile and hoping the diff will give
you hints on what that product's extension profile might look like)
2) so many products don't come with extension profiles.

I want to build something that could help with both of these, so in
effect, the only algebra you ever really need is of the form:

newsiteprofile = orginalbaseprofile + A + C + localmod

And it wouldn't matter if that was created and merged into a single
resident base profile, or generated dynamically. But all of this
assumes that you still apply a product's extension profile in the
clear at some point and then make your local mods seperately.

>
>
> Tres.
> - --
> ===================================================================
> Tres Seaver          +1 540-429-0999          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
>
> iD8DBQFGABJ/+gerLs4ltQ4RAg0dAJ46pshif90RkP33+xrcB+q12hVolQCgv7g6
> 2oxiFIolhcL/cYCStgzD/cw=
> =EeA+
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF at lists.zope.org
> http://mail.zope.org/mailman/listinfo/zope-cmf
>
> See http://collector.zope.org/CMF for bug reports and feature requests
>