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

Rob Miller ra at burningman.com
Fri Jun 22 13:14:05 EDT 2007


yuppie wrote:
> Hi Rob!
> 
> 
> Rob Miller wrote:
>> yuppie wrote:
>>>
>>> - Why is it necessary to use version numbers from VERSION.txt? AFAICS 
>>> it does not make much sense to keep profile version numbers in sync 
>>> with product version numbers. New profiles should have an explicit 
>>> version in metadata.xml, old profiles can use '0' as version number. No?
>>
>> i could go either way.  i thought that some folks, with products that 
>> had fast release cycle, might choose to use the product version as the 
>> profile version, so the product version is used as a failover if a 
>> profile version isn't present.  i don't feel strongly, though, and 
>> would be fine to remove this if others disagree.
> 
> Well. I'd prefer to have *one* obvious and explicit solution. The 
> failover adds extra code that needs to be maintained and makes it less 
> obvious where the version number comes from.

i agree.  i was thinking since my last reply that, since the code is already 
in there, we could support a special value in the metadata.xml file that 
explicitly tells GS to use the product version for the profile version, rather 
than having that be the default behaviour.

>>> - Why uses ProfileMetadata the old ImportConfiguratorBase? 
>>> ImportConfiguratorBase is just not deprecated because GenericSetup 
>>> still uses it in some places. But the goal was to get rid of it, not 
>>> to add new files that depend on it.
>>
>> since it wasn't deprecated, or even commented, i didn't know the goal 
>> was to get rid of it.  sorry.
> 
> I am sorry. Looks like you spent a lot of time on figuring out how it 
> works and writing documentation :(

yup.  ah well.

> I wrote that code long ago, replacing the old pattern still used in 
> DCWorkflow's WorkflowDefinitionConfigurator. Later I figured out that 
> this extra framework is less flexible and not much easier to use than 
> the generic DOM API. All new code is DOM based and a big part of the old 
> code is converted.
> 
> If you agree that this code can be removed in the long run, we should 
> figure out how to document this decision.

i'm fine to remove it.  it was a bit of a PITA.  putting a comment in the code 
or the docstring would have been enough to alert me to not use it, until such 
time as we can convert the remaining uses and officially deprecate it.

>>> - Why is exporting metadata.xml not supported?
>>
>> because metadata.xml is not actually site configuration.  it's 
>> metadata on the profile itself.  there's not any way, nor should there 
>> be, IMO, that the information provided in the metadata file can be 
>> changed on a live site in such a way that it would be exported.  
>> perhaps it would be better to change the metadata to an .ini file, or 
>> some other config syntax, to distinguish it more clearly from the rest 
>> of the profile.
> 
> If it is pure registration information, why don't we extend the ZCML 
> directive? But AFAICS data like the version number belongs to the 
> profile itself and it might be useful to add timestamp based version 
> numbers to exported profiles.
> 
>>> - How are profile dependencies specified, where are they used?
>>
>> dependencies are specified in metadata.xml; syntax can be found in 
>> test_profile_metadata.py.  unfortunately, they're not used yet... this 
>> was a goal that we didn't actually get to.  :-(.
> 
> 'DEPENDENCY 1' and 'DEPENDENCY 2' don't really explain how to specify 
> dependencies: Would we use identifiers like 
> 'Products.CMFCalendar:default'? Is it possible to use version numbers?

true enough.  i was thinking it would simply be the profile identifier, e.g. 
'Products.CMFCalendar:default'.  i'm not planning on developing a really rich 
dependency management infrastructure, just a way to have one profile trigger 
the importation of another.

> As long as these questions are not resolved I would disable the support 
> for dependencies completely.

it IS disabled completely.  but i'm fine w/ removing the 'dependency' pieces 
from the metadata.xml parsing, until such time as it can actually be implemented.

-r



More information about the Zope-CMF mailing list