[Zope-CMF] Re: GenericSetup: purging steps on new base profile

[yuppie]

Hi Rob!


Rob Miller wrote:
> i'm picking up a thread from january that sort of petered out...
> 
> yuppie wrote:
>> Tres Seaver wrote:
>>> Florent Guillaume wrote:
>>>> Because the "current base profile id" is not stored, there's no way to
>>>> do detect the change to a different base profile. Should I store that
>>>> property to allow for that use case?
>>>
>>> Yes.  In fact, I would prefer to be able to introspect both "current
>>> base profile" and "applied extension profiles" from the tool.
>>
>> I don't want to go down that road.

I have to refine this statement: *For now* I don't want to go down that 
road. In the long run I think we have to keep track of applied profiles. 
That would help to make the setup tool more powerful and to implement 
features like reloading or uninstalling. But AFAICS doing this right 
requires a major refactoring and would come to late for CMF 1.6 or 2.0.

>> The next step would be to keep 
>> track of the applied profiles a snapshot is based on. Things become 
>> more and more complicated and we still can't rely on that information: 
>> Sites created with older CMF versions don't have that information and 
>> manual customizations can make it quite useless.
> 
> i, on the other hand, am very interested in being able to see which 
> profiles have been applied.  i don't think it's unreasonable to record 
> and expose this.  of course this can't be treated as the final word on 
> the current site configuration, but just because someone may have done 
> further manual configuration doesn't seem to me a good reason to make it 
> harder to figure out which profiles have been applied in the first place.
> 
> i'm going to cut a branch to experiment a bit w/ implementing this.  in 
> the meantime, this conversation can continue.  if the consensus ends up 
> being against these features, i can put any code from the branch in at 
> the Plone level.

I can see that this information might be useful, but it doesn't 
represent a state of the tool or the site. It has more the character of 
(sometimes incomplete) history information and I'd prefer to use the 
logging machinery for that.

What about adding that information to the import logs and creating an 
import log for the initial site creation as well?


Cheers,

	Yuppie