Re: [Zope-dev] RFC: proposal to split zope.configuration into ZCML and non-ZCML related packages
On Wed, 2011-08-31 at 10:59 +0200, Hanno Schlichting wrote: > On Wed, Aug 31, 2011 at 9:17 AM, Wolfgang Schnerring wrote: > > Splitting zope.configuration into core mechanics and ZCML support > > makes a lot of sense to me. > > > > So, +1 from me. > > +1 here too It turns out that we were using so little of zope.configuration in the Pyramid core that it was much to replace it than it is to port this stuff (and write docs/unittests) so I withdraw this proposal. FTR, apologies, it's a bit lame of me to not help with a zope.configuration Python 3 porting effort and just fork and steal bits of code I need. We do still depend on the entirety of zope.configuration in an add-on package named "pyramid_zcml", so if there is call to port that to Python 3, I may revisit this topic. - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: proposal to split zope.configuration into ZCML and non-ZCML related packages
On Wed, Aug 31, 2011 at 9:17 AM, Wolfgang Schnerring wrote: > Splitting zope.configuration into core mechanics and ZCML support > makes a lot of sense to me. > > So, +1 from me. +1 here too Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: proposal to split zope.configuration into ZCML and non-ZCML related packages
* Chris McDonough [2011-08-28 21:35]: > Pyramid doesn't actually require ZCML or zope.schema; it only uses > the parts of zope.configuration related to actions, conflict > resolution, and the "ConfigurationMachine" itself. These bits have > proven useful outside the context of ZCML and other schema-driven > configuration. > > I have tackled this issue by factoring zope.configuration into > two pieces: > - I have moved the bits that don't rely on ZCML or zope.schema > into a new 'zope.configmachine' package > - I have made zope.configuration which depends on > zope.configmachine in a branch: Splitting zope.configuration into core mechanics and ZCML support makes a lot of sense to me. I'm not too hot about the "zope.configmachine" name, because it's all mechanics and not much intention, but I realize the bikeshedding danger here. So, +1 from me. Wolfgang -- Wolfgang Schnerring · w...@gocept.com · software development gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RFC: proposal to split zope.configuration into ZCML and non-ZCML related packages
Rationale Like the previous proposal by Tres Seaver related to zope.component, this is a step that will help port crucial Pyramid dependencies to Python3: https://github.com/Pylons/pyramid/wiki/Python-3-Porting At the end of this year's US PyCon, Lennart Regebro described the zope.configuration porting effort as mostly dependent on the porting of zope.schema (see http://permalink.gmane.org/gmane.comp.web.zope.devel/26373). In the meantime, Pyramid doesn't actually require ZCML or zope.schema; it only uses the parts of zope.configuration related to actions, conflict resolution, and the "ConfigurationMachine" itself. These bits have proven useful outside the context of ZCML and other schema-driven configuration. An Pyramid add-on named pyramid_zcml still has a dependency on zope.component as it provides ZCML analogues of built-in Pyramid configuration directives. We will likely end up eventually helping to port zope.schema to Python 3 as a result. But splitting the zope.configuration package in two parts seems to make sense regardless, as the Pyramid core just doesn't need the extra zope.schema dependency, it just "comes along for the ride". I have tackled this issue by factoring zope.configuration into two pieces: - I have moved the bits that don't rely on ZCML or zope.schema into a new 'zope.configmachine' package, now hosted in the Zope SVN repository: http://svn.zope.org/zope.configmachine/trunk Notes on the new package: - The tests in this package are incomplete. I intend to provide full coverage once discussion concludes, as well as some documentation for the package as a standalone entity. - The branch is not yet Python 3 compatible. It's trivial to make it so, once discussion concludes that the configuration/configmachine division is acceptable. - I have made zope.configuration which depends on zope.configmachine in a branch: http://svn.zope.org/zope.configuration/branches/chrism-configmachine This branch leaves BBB imports intact. Proposal I would like to propose the following changes to the ZTK trunk, after test coverage and documentation for zope.configmachine land: - Land 'zope.configmachine' as a full ZTK package, with its own Launchpad artifacts, etc. This step may also involve moving bugs from zope.configuration to zope.configmachine. - Merge the 'chrism-configmachine' branch of zope.configuration to the trunk, and bump its major version accordingly. - Cut releases of both packages. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
