-----BEGIN PGP SIGNED MESSAGE-----
> On 3/22/07, Tres Seaver <[EMAIL PROTECTED]> 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
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.
>> 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
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
- The libraries which support c14n (lxml is the one I know best)
are new dependencies.
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v184.108.40.206 (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