[Zope-CMF] Re: state of GenericSetup trunk and branches

[Rob Miller]

Maurits van Rees wrote:
> Rob Miller, on 2007-06-21:
>> Wichert Akkerman wrote:
>>> The new GS looks very nice, but from the ZMI UI I can no longer see how
>>> I can import only selected steps of an extension profile. I hope that is
>>> still possible; it can be extremely useful. It looks like the import and
>>> export tab only act on the base profiels now.
>> hmm... i think that the aggregate of all of the steps from the various 
>> profiles that have ever been imported should show up on the import screen, so 
>> it should be possible to select ones that were added by a specific extension 
>> profile.  but this doesn't help, of course, when you only want to re-import 
>> the portal types step from an extension profile.
> 
> Indeed: currently you will just import the portal types as defined by
> the base profile.
> 
>> so you're right, the UI is missing a piece.  two pieces, actually.  on the 
>> 'profiles' tab, there should be another button, "load import steps", which 
>> will register the steps w/o actually running them.  (importing a profile does 
>> this for you.)  then the import and export tabs can have a dropdown that lets 
>> you choose from any profiles that have had the steps loaded.
>>
>> i won't be able to get to that until next week, unfortunately.  anyone else?
> 
> I have some code that I think does the first part: adding a button on
> the Profiles tab and adding some code to support it:
> 
> http://paste.plone.org/15348

great!  thanks!

> During testing I noticed that my knowledge of GenericSetup might be
> flawed though, as I discovered some things that were new to me, so I
> have some questions that crept up.
> 
> 1. In GenericSetup 1.2, if you select an extension profile on the
>    Properties tab (now called Profiles), and then go to the Import tab
>    and import all steps, is that extension profile then basically
>    treated as a BASE profile?

no, it's still an extension profile.  the tab formerly known as "properties" 
was where you would select the "active" profile.  the active profile could be 
either a base or an extension profile.  since these have different 
implications when you run them, it was a bit odd that you'd use the same 
mechanism for doing so.

> 2. What needs to happen on the import tab now on trunk?  We want a
>    drop down that lists all extension profiles.  When I select one of
>    those extension profiles, should I get a list of only those steps
>    for which this profile has an xml file?  Or should I just get a
>    list of all steps available (several dozen on Plone 3) and have the
>    extension profile as context when I click the correct button?

as you said in your later post, this is not only not desirable, it's not 
possible.  if you run a step that is unrelated to the profile which you have 
selected, nothing should happen.  of course, it's up to the implementation of 
the import step to make sure this is the case.  more on that below...

> 3. When I install Plone 3.0 with the new GenericSetup trunk, and go to
>    the Import tab, there are about 37 steps listed.  That is a lot.
>    Especially there are a few importVarious steps of different
>    products, at least when you add some third party products in the
>    Products dir.  I do not know how widespread and generally accepted
>    those importVarious steps are for third party products.  I do
>    notice that in the current situation in Plone 3 when you go to that
>    import tab and click Import All Steps, all registered steps are
>    tried, including all third party importVarious steps.

yep, that's as it should be.

>    As a test I added my own eXtremeManagement product in the Products
>    dir, which also has a GS extension profile with an importVarious
>    step.  I registered this profile with the patch I linked to above.
>    Then I tried to import all steps.  This meant that the
>    eXtremeManagement importVarious step was run, which gave problems
>    as it assumed some portal types to be available, which were not
>    there.  I now fixed that by checking what the context is:
> 
>      def importVarious(context):
>         if 'Products/eXtremeManagement/profiles/default' \
>           not in context._profile_path:
>             return
>         ...
> 
>    In fact, when running all import steps, the profile path of the
>    context is that of CMFPlone:
> 
>    u'/home/maurits/instances/xm30/Products/CMFPlone/profiles/default'
> 
>    Anyway, for extension profiles we want to give the users a means on
>    that import tab to get the context right.
> 
>    I guess my question is:
> 
>    A. Is my change to eXtremeManagement in the importVarious function
>       above logical?  I committed it already, so it had better be. :)

it's a reasonable first pass, and it's much better than not having it there. 
a better approach would be that taken by Plone, where you have the import step 
check the profile for the existence of a file with a specific name.  if the 
file exists, run the step, if not, don't.  then you 'touch' that file so it 
exists in your profile.

>    B. These importVarious steps that eXtremeManagement and other
>       products define, and that cannot be mapped to other handlers,
>       are they good practice?  Or are they an abomination, bound to
>       lead to problems?

they're not exactly an abomination, but they do have a gigantic gotcha that 
you've hit on here.  i'll restate it clearly:

IT IS THE RESPONSIBILITY OF AN IMPORT STEP'S IMPLEMENTATION TO ENSURE THAT IT 
IS INDEED APPROPRIATE TO PERFORM ITS ACTIONS DURING ANY GIVEN INVOCATION OF 
THE STEP.

all of the XML-based import steps already do this; they check for the 
existence of a specific XML file, and if they find it they perform the action. 
  if they do not find the file, no problem, they do nothing.

the so-called 'importVarious' steps, i.e. any step that uses a plain old 
python function as its handler (as opposed to building on the existing XML 
parsing infrastructure), must perform this check explicitly.  you could 
restrict it to only running when the intended profile is the one being 
imported, or you could check for the existence of a specific file within the 
profile.  i like the latter choice.

i tried to say this in my tutorial on plone.org 
(http://plone.org/documentation/tutorial/genericsetup), but i wrote that some 
time ago, it could probably be updated to be more clear about this issue.

anyway, hope this clears things up.

-r