-----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 tsea...@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----- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )