[Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch

Tres Seaver tseaver at palladion.com
Tue May 12 11:33:38 EDT 2009

Hash: SHA1

Andreas Jung wrote:
> On 12.05.09 16:02, Andreas Jung wrote:
>> On 12.05.09 15:25, Chris Withers wrote:
>>> Andreas Jung wrote:
>>>>> - It's being done into the beta phase of Zope 2.12 
>>>> changes in this *early* beta phase, no changes after beta 2 are
>>>> acceptable).
>>> This feels like an abuse of your position as release manager.
>> I call it adjusting the policies as needed for getting things done and
>> for getting important things and I emphasize once again: it happend
>> during beta 1 - we proceeded always this way to some degree. I am not
>> the slave to the policy.
>>> Can you honestly tell me that if it was anyone other than you, you'd
>>> let them merge these changes after you'd already cut beta 1?
>>>> Feature 2 (the one you are complaining about): Making <environment> a
>>>> multisection.
>>>> The rational behind this change is clear: making the Zope configuration
>>>> more modular for bigger setups. In complex setups there is a need for
>>>> having this
>>>> extension if you don't want and can't to build a monolithic
>>>> configuration.
>>> There are plenty of options other than this, the one that jumps to
>>> mind would be a buildout recipe similar to collective.recipe.template
>>> that staples together your various config file snippets into one
>>> zope.conf.
>> Possibly. As said, I am not married with this particular feature.
>>>> "The community" working on Zope 2.12 was basically Hanno doing most of
>>>> the work,
>>>> Tres and me.
>>> That's not quite true, other people have been contributing fixes and I
>>> know I spent a lot of time getting Zope 2.12 to work in a buildout
>>> without the need for rewriting the zope2instance recipe.
>>> But, that aside, people working on Zope 2.12 does not make up the
>>> whole community, there's the whole userbase, or even potential
>>> userbase to consider.
>> We try our best for not breaking things - this happens from time to time
>> - usually
>> unintended. It's perfectly fine when an incompatiblity pops up during
>> the beta phase.
>> No need for crying out lould.
>>>> So the actual development is driven by the people doing the
>>>> work and by
>>>> their needs. 
>>> I agree with this.
>>>> Not every new feature must be discussed in depth on the list. 
>>> I don't agree with this. New features should always be discussed. Had
>>> you posted the messages you posted to the bug tracker to this list
>>> instead, and then waited a week or so for people to comment, that
>>> would have been fine.
>> A mis-configuration/mis-feature of Launchpad. There should be a list for
>> all LP
>> related traffic. Right now you have to be member of the Zope 2 group on LP.
>> Something we can easily fix.
>>>> Consider this being a defect of your release process and planning. 
>>> *My* release process and planning?
>> Sorry, basically not my problem - if you depend on bleeding-edge
>> releases, you
>> have to be aware of the consequences. And since we have no schedule for
>> the release, your planning is pretty much obsolete.
>>>> The primary purpose of the <environment> section is for making
>>>> additional environment
>>>> variables available with Zope. I consider being an "internal"
>>>> functionality.
>>> Well, I consider it less than internal ;-)
>> That <http://dict.leo.org/ende?lp=ende&p=thMx..&search=That>'s
>> <http://dict.leo.org/ende?lp=ende&p=thMx..&search=s> a
>> <http://dict.leo.org/ende?lp=ende&p=thMx..&search=a> matter
>> <http://dict.leo.org/ende?lp=ende&p=thMx..&search=matter> of
>> <http://dict.leo.org/ende?lp=ende&p=thMx..&search=of> opinion
>> <http://dict.leo.org/ende?lp=ende&p=thMx..&search=opinion>.
>>>>> Andreas, please revert this change until people have had a chance to
>>>>> look at it properly.
>>>> Reverting the change without a discussion was offending (see above). And
>>>> I want to emphasize
>>>> once more: none of the people doing the development work need to ask for
>>>> every single
>>>> change made to the Zope 2 core for public feedback. 
>>> I actually agree with this, but I don't agree in the case of new
>>> features or in the case of backwards compatibility breakages.
>> See above. I could not commit the fixes and new features earlier  because
>> of constraints that don't belong into public.
>>> Nevertheless, if you're intent on bulldozing this change through,
>>> please consider using and writing a test for the one additional like I
>>> gave you that should result in getConfiguration().environment being
>>> the single dict it always has been and should logically be.
>> Where is the test telling us that getConfiguration().environment has to
>> be a dict (as it is used
>> only internally)?

I would consider the section type in 'zopeschema.xml' to be part of a
public-facing API:  the attrribute name 'environ' is part of the
documented schema.

Assuming that jamming things into os.environ from add-ons is a hard
requiremnt (I can't imagine that, myself:  a lot of the point of ZConfig
was to move *away* from dependencies on os.environ), it would be trivial
to add another importable component.xml which could be used to extend
the environment from an add-on products, rather than changing the type
of the <environment> section in a BBB-incompatible way.  E.g. in

   <sectiontype name="extended-evironment"
    <key name="+" attribute="environ">

   <multisection type="extended-environment" name="*"

and then tweak the startup code to iterate over those sections in
addition to the original one when populating os.environ::


  def root_handler(config):
      #existing <environment> code
      for k, v in config.environment.items():
          os.environ[k] = v
      #extensions to os.environ from add-on products
      for extension in config.extended_environment:
          for k, v in extension.items():
              os.environ[k] = v

- --
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Zope-Dev mailing list