[Zope-CMF] Re: Base and Extension profiles

[Matt]

On 3/22/07, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Matt wrote:
>
> > On 3/22/07, Tres Seaver <tseaver at palladion.com> wrote:
> >> Extensions which have been imported modify the persistent profile state;
> >> exporting that state gives you the "locked down" merge.
> >
> > Right. I thought that might be the intention. It depends a lot on all
> > the export steps working well. It would be nice to know in an export
> > profile just what contributed to it ... but I presume that depends on
> > only using extension profiles to build out your site profile as you
> > progress.
>
> One issue here is that the profiles on the filesystm change over time,
> independently of the ZODB, due to software updates.  We did talk at the
> sprint about capture pre-import copies of each imported profile, in
> order to be able to report on what was actually imported, vs. what would
> be imported today if the same profile were loaded.
>
> <snip>
>
> >> I'm still not sure how such an "algebraic" approach would work, given
> >> that local modifications are potentially arbitrarily complex.
> >>
> >
> > I only see it being not complex if you can dissect out the original
> > base and then any extension profiles applied or local modifications of
> > the base profile. You could do this by way of good practice with
> > subversion.
>
> Maybe.  We also talked about automating the creation of before and after
> snapshots for each imported extenaion (or re-importig the baseline).
>
> > I am seeing an algebra not being very necessary; it seemed to only be
> > in the context of 1) comparing an exported profile to a previous  base
> > profile to see what a product or products installed with
> > quickinstaller contributed to the new profile, and then to see why in
> > most instances it didn't work (usually because their Install.py does
> > some crazy things that just don't get captured in an export of state).
>
> Yup, imperative stuff during import defeats most of the benefits, which
> is one reason we tried to factor out the imperative-by-nature upgrade
> steps from the intended declarative import steps.  The upgrade machinery
> is intended (as its name suggests) to suppot controlled one-way
>
> However, people will still want to have their extensions "scribble"
> (e.g., to replace types from the baseline profile, rather than adding
> new ones, or to modify other state in non-introspectable ways).
>
> > 2) comparing the base profile of say a new plone version to your
> > current site profile and trying to work out what you should change -
> > for example perhaps one of the products you installed at one time made
> > a change to a particular step - it ends up being a 3 way diff.
> >
> > Still, some canonical serialized form of profiles would be useful for
> > being able to still play with unified diffs. Which was very much my
> > original aim.
>
> Canonicalizing the XML for the profiles you are comparing would
> certainly reduce false-positive noise.  There are a couple of issues
> with it, however:
>
>   - The diff can't be applied directly to a non-canonicalized profile

Right. And that means that the diff mechanism would need to understand
the semantics of the elements in the xml files. That is really part of
what I was imagining an algebra to be ... a generated delta would be
simply a list of commands to perform on the xml tree to transform it.
That could be xslt or a generated python script or a custom xml
format. But I was imagining it being linear - i.e. readable from top
to bottom - and flat.

As an analogy, the RDF world is quite nice (I don't believe I said
that!) since you can represent your entire system as a linear set of
triples, which can be sorted in whatever way you want (it won't affect
the end graph (state) if applied in different orders). This means it
is quite simple to generate a set of commands - add this triple,
delete this one, that read from top to bottom and can be sorted
(useful for doctests).

>
>   - The libraries which support c14n (lxml is the one I know best)
>     are new dependencies.

Wouldn't you need more than c14n since there are ordered and unordered
parts to import step configurations? I can't see how a useful diff
utility can be made unless there is a schema provided for each
configuration xml for each import step (including custom ones that
people may add) that was explicit about whether the elements were
ordered or unordered. The skins.xml file is a good example of ordered
and unordered elements.

I still think unified diff of a canonical+ form will be useful as a
read only mechanism.


>
> 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
>
> iD8DBQFGAmJy+gerLs4ltQ4RAtwoAJ42dmpQv1XKHafiMoBmLKkXfbeczwCfa8Be
> 8QMXVQRzSlQY101NJPoUKd4=
> =XrVd
> -----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
>