[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


-----BEGIN PGP SIGNED MESSAGE-----
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
zopeschema.xml:

  <schema>
   ...
   <sectiontype name="extended-evironment"
                datatype=".cgi_evironment"
                keytype="identifier">
    <description>...</description>
    <key name="+" attribute="environ">
     <description>...</description>
    </key>
   </sectiontype>

   <multisection type="extended-environment" name="*"
                attribute="extended_environment"/>
  </schema>

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

  #Zope2/Startup/handlers.py

  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.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKCZbS+gerLs4ltQ4RAotQAJ9lqf/mvEB+k+TVmFp1TIOLmTVaGQCgh+IU
5Bvwp0Ry+0YKisLDZu8s7bk=
=NK6E
-----END PGP SIGNATURE-----



More information about the Zope-Dev mailing list