[Zope-Checkins] SVN: Zope/branches/2.11/lib/python/DateTime/DateTime.py Omitted upgrade for state dicts w/o '_micros'.
Log message for revision 97472: Omitted upgrade for state dicts w/o '_micros'. Changed: U Zope/branches/2.11/lib/python/DateTime/DateTime.py -=- Modified: Zope/branches/2.11/lib/python/DateTime/DateTime.py === --- Zope/branches/2.11/lib/python/DateTime/DateTime.py 2009-03-04 16:44:48 UTC (rev 97471) +++ Zope/branches/2.11/lib/python/DateTime/DateTime.py 2009-03-04 17:00:38 UTC (rev 97472) @@ -356,6 +356,8 @@ def __setstate__(self, state): self.__dict__.clear() # why doesn't Python's unpickler do this? self.__dict__.update(state) +if '_micros' not in state: +self._micros = self._upgrade_old() def _parse_args(self, *args, **kw): Return a new date-time object. ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/ Updated to DateTime 2.12.0.
Log message for revision 97476: Updated to DateTime 2.12.0. Changed: U Zope/trunk/doc/CHANGES.rst U Zope/trunk/versions-zope2.cfg -=- Modified: Zope/trunk/doc/CHANGES.rst === --- Zope/trunk/doc/CHANGES.rst 2009-03-04 17:06:19 UTC (rev 97475) +++ Zope/trunk/doc/CHANGES.rst 2009-03-04 17:19:10 UTC (rev 97476) @@ -23,6 +23,8 @@ Restructuring + +- Updated to DateTime 2.12.0. + - Updated to ZODB 3.9.0a12. - Removed the `getPackages` wrapper from setup.py which would force all Modified: Zope/trunk/versions-zope2.cfg === --- Zope/trunk/versions-zope2.cfg 2009-03-04 17:06:19 UTC (rev 97475) +++ Zope/trunk/versions-zope2.cfg 2009-03-04 17:19:10 UTC (rev 97476) @@ -4,7 +4,7 @@ [versions] Acquisition = 2.12.0a1 -DateTime = 2.11.2 +DateTime = 2.12.0 ExtensionClass = 2.11.1 Persistence = 2.11.1 tempstorage = 2.11.1 ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/src/Zope2/utilities/mkzopeinstance.py Make 'mkzopeinstance' work from a SVN checkout.
Log message for revision 97478:
Make 'mkzopeinstance' work from a SVN checkout.
Changed:
U Zope/trunk/src/Zope2/utilities/mkzopeinstance.py
-=-
Modified: Zope/trunk/src/Zope2/utilities/mkzopeinstance.py
===
--- Zope/trunk/src/Zope2/utilities/mkzopeinstance.py2009-03-04 17:20:59 UTC
(rev 97477)
+++ Zope/trunk/src/Zope2/utilities/mkzopeinstance.py2009-03-04 17:57:23 UTC
(rev 97478)
@@ -50,6 +50,9 @@
skelsrc = None
python = None
+if check_buildout():
+python = os.path.abspath('bin/zopepy')
+
for opt, arg in opts:
if opt in (-d, --dir):
skeltarget = os.path.abspath(os.path.expanduser(arg))
@@ -186,5 +189,14 @@
fp.close()
os.chmod(fn, 0644)
+def check_buildout():
+ Are we running from within a buildout which supplies 'zopepy'?
+
+if os.path.exists('buildout.cfg'):
+from ConfigParser import RawConfigParser
+parser = RawConfigParser()
+parser.read('buildout.cfg')
+return 'zopepy' in parser.sections()
+
if __name__ == __main__:
main()
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/ empty object managers were evaluating to boolean false since Hanno fully implemented IContainer, because boolean checks fall through to __len__ if __nonzero__ is not i
Log message for revision 97521:
empty object managers were evaluating to boolean false since Hanno fully
implemented IContainer, because boolean checks fall through to __len__ if
__nonzero__ is not implemented. always evaluating to true is the
backwards-compatible approach
Changed:
U Zope/trunk/doc/CHANGES.rst
U Zope/trunk/src/OFS/ObjectManager.py
U Zope/trunk/src/OFS/tests/testObjectManager.py
-=-
Modified: Zope/trunk/doc/CHANGES.rst
===
--- Zope/trunk/doc/CHANGES.rst 2009-03-05 07:49:18 UTC (rev 97520)
+++ Zope/trunk/doc/CHANGES.rst 2009-03-05 07:52:06 UTC (rev 97521)
@@ -32,7 +32,11 @@
newer versions of the dependencies. This kind of KGS information needs
to be expressed in a different way.
+Bugs Fixed
+++
+- Object managers should evaluate to True in a boolean test.
+
2.12.0a1 (2009-02-26)
-
Modified: Zope/trunk/src/OFS/ObjectManager.py
===
--- Zope/trunk/src/OFS/ObjectManager.py 2009-03-05 07:49:18 UTC (rev 97520)
+++ Zope/trunk/src/OFS/ObjectManager.py 2009-03-05 07:52:06 UTC (rev 97521)
@@ -789,6 +789,9 @@
def __len__(self):
return len(self.objectIds())
+def __nonzero__(self):
+return True
+
security.declareProtected(access_contents_information, 'get')
def get(self, key, default=None):
return self._getOb(key, default)
Modified: Zope/trunk/src/OFS/tests/testObjectManager.py
===
--- Zope/trunk/src/OFS/tests/testObjectManager.py 2009-03-05 07:49:18 UTC
(rev 97520)
+++ Zope/trunk/src/OFS/tests/testObjectManager.py 2009-03-05 07:52:06 UTC
(rev 97521)
@@ -379,6 +379,10 @@
om['2'] = si2
self.failUnless(len(om) == 2)
+def test_nonzero(self):
+om = self._makeOne()
+self.failUnless(om)
+
def test_get(self):
om = self._makeOne()
si1 = SimpleItem('1')
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04.03.2009 8:50 Uhr, Chris McDonough wrote: Andreas Jung wrote: 2) I'm also not in favor of a giant lockstep set of software versions shared between notional releases Zope 3.5, Grok, and Zope 2.12. I can only see this as continuing our mistakes of old by trying to treat some collection of software as Zope as opposed to letting parts of it survive or die on their own based on merit; it'd be more effective to just let each framework use (or disuse!) whatever versions of stuff that work best for it. That's why the software is broken out into individual components in the first place; we should encourage diversity in component usage. Instead of trying to legislate and bless some set of components as a version, we should just work to make each piece better and worthwhile to use independently; it's value would be in its actual usefulness rather than some belief that it works well with the other components in the version. Could we at least agree that lockstep versioning of a huge set of Zope eggs to be shared across many frameworks is not optimal for the long term and that it would be better if each framework could pick and choose whatever components and versions it actually needed? Could we also agree that this would tend to result in better dependency partitioning (X depends on Y, I don't need Y, I just need X, let's fix that)? A central maintained KGS for Zope 3.X components is necessary since only a minor number of core developers knows exactly which version match together. You can not expect that non-core developers have this knowledge. In places that require cross-package API contracts, each contract should be spelled out in an interface. If each contract is spelled out in an interface, non-core developers should have no problem gaining this knowledge. That's what interfaces are for. Interfaces are one side of the medal, the other side are dependencies expressed through version pinning. We have had enough examples with version conflict with modules that would obviously fit together based on their interface definitions. That's where a KGS helps a lot - however this is not a contradiction to the approach that Tres pointed out with maintaining a per-project index with hand-selected packages. I find this idea very compelling for a bunch of usecases - not sure if this a general approach - one out of many. Andreas - -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: i...@zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK - E-Publishing, Python, Zope Plone development, Consulting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmuOPAACgkQCJIWIbr9KYwOjQCgt9O7I4qdRBlzqsm93OfzYBf2 VYQAoII60shD+EkPF9TqaTb5ZaQQ3rDT =DrbH -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ 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 )
Re: [Zope-dev] the Zope Framework project
Lennart Regebro wrote: On Wed, Mar 4, 2009 at 07:52, Chris McDonough chr...@plope.com wrote: Tather than reply in kind here, let me summarize: I'm glad we agree more than we disagree, and I apologize if I've attributed to you beliefs that you don't have. It's heartening to hear that you're in favor of most of the things I'm also in favor of. But we do have real differences in opinion I think. I'd rather be constructive than obstructionist here: at the end of each item below I ask for an opinion based on a suggestion. 1) I'm not in favor of a single steering group for the *entirety* of all Zope software. We've tried a similar thing in the past (via the foundation structure); it didn't work and I'm not sure how we'd expect things to turn out any differently this time. Instead, perhaps the focus of groups should be on some much smaller subset of Zope-related software (e.g. the zope.interface+zope.component group, the zope.schema group, the ZODB group, etc). Could we consider this? It's better certainly, but isn't this small enough in itself that these groups will form naturally by whoever is working on it? To the extent we can discourage the formation of the one-big-group-to-rule-them-all by encouraging the formation of smaller groups, I think it's a good idea. But in reality, I think nothing needs to be done: group-forming will always be a self-selecting process. No, we want Zope 3.4 to have one set of modules with one API, and Grok 1.0 and Zope 2.12 to use exactly the same. And then a Zope 3.4 with a Grok 1.1 (or something) and a Zope 2.13. So we DO want lockstep and to use the same major KGS over all these versions. At least I do I don't see why this must result in parts that should die being left undead. This just seems like a blindingly obvious antigoal to actually breaking apart the software into more discrete bits using eggs. Why not just stick with a huge tarball release or one single egg if it all has to be versioned through time to 99% of its consumers as one giant collection of software treated as a unit? If Repoze.bfg doesn't want to lockstep, the Zope2/Zope3/Grok lockstep would not pose a problem for Repoze, would it? Nope. Then again, if Repoze doens't want to be a part of The Zope Framework users but always make their own set of modules, that will admittedly lessen the purpose of it, as the minimalistic attitude of Repoze.bfg would work as a good test of what should be in the framework in the first place. Right. No one except people who've already bought in to the notion of Zope software as one huge pile will benefit from the lockstep centralized planning. It won't gain Zope any new users; no different framework users will begin to use Zope software as a result of this plan. How is this different than the current status quo? Could we at least agree that lockstep versioning of a huge set of Zope eggs to be shared across many frameworks is not optimal for the long term Well, since it's shared by many frameworks, I'm not sure it would be huge. But that's a matter of taste of course. But in any case, through this discussion, I must admit that I not not understand why this would pose problem. It doesn't pose a problem. It's just business as usual. and that it would be better if each framework could pick and choose whatever components and versions it actually needed? It can. These are not mutually exclusive. A central KGS for the core framework does not exclude you making your own KGS, neither does it mean you can't release each module separately. Could we also agree that this would tend to result in better dependency partitioning (X depends on Y, I don't need Y, I just need X, let's fix that)? I don't see how these are related. When components are not treated as one giant pile, and it's expected that you should be able to use pieces of the pile selectively without buying in to some unrelated software, dependency management becomes far more brutal and realistic. - C ___ 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 )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 07:52:09 schrieb Chris McDonough: Tather than reply in kind here, let me summarize: I'm glad we agree more than we disagree, and I apologize if I've attributed to you beliefs that you don't have. It's heartening to hear that you're in favor of most of the things I'm also in favor of. But we do have real differences in opinion I think. I'd rather be constructive than obstructionist here: at the end of each item below I ask for an opinion based on a suggestion. 1) I'm not in favor of a single steering group for the *entirety* of all Zope software. We've tried a similar thing in the past (via the foundation structure); it didn't work and I'm not sure how we'd expect things to turn out any differently this time. Instead, perhaps the focus of groups should be on some much smaller subset of Zope-related software (e.g. the zope.interface+zope.component group, the zope.schema group, the ZODB group, etc). Could we consider this? What I don't see in your proposal is, how these subset-groups would be coordinated, which leads to the following: - How would these groups be formed? If there's nobody who encourages people to do so, - Higher level package/groups may have a hard life in case basic packages/groups are not coordinated and all go their own way. - How does some foreigner know, if a package is actively supported, umaintaned, deprecated etc.? How does he know, what packages exist, what they are good for and the like? For instance, I yesterday wrote that I use lovely.remotetask, then I was asked on the list why I did not use the (maybe better) zc.async package. Know why? I did not know that it existed. - I think, Zope 3 is not only about some seperate packages, but about a complete programming experience. Thus there needs to be some integrating force, that draws together all these packages, writes some documentation / tutorial / website etc. - Newbies won't be attracted by single packages. Instead, they want something complete. Who would be interested in Plone if it would consist of various packages that people would have to draw together by themselves, without decent documentation? To my mind, one key point is attracting more users. And that can only be done if we try to view things from an external, newbie-perspective. Some Ruby on Rails / Java / Turbogears programmer will only be attracted by some big picture but probably not by a collection of some subpackages. So, my impression is that there is a need for some steering group, that will, however, encourage people to form groups around packages and maintain them. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 09:21, Chris McDonough chr...@plope.com wrote: To the extent we can discourage the formation of the one-big-group-to-rule-them-all by encouraging the formation of smaller groups, I think it's a good idea. But in reality, I think nothing needs to be done: group-forming will always be a self-selecting process. Well, at least we should try this first, I agree with that. No, we want Zope 3.4 to have one set of modules with one API, and Grok 1.0 and Zope 2.12 to use exactly the same. And then a Zope 3.4 with a Grok 1.1 (or something) and a Zope 2.13. So we DO want lockstep and to use the same major KGS over all these versions. At least I do I don't see why this must result in parts that should die being left undead. This just seems like a blindingly obvious antigoal to actually breaking apart the software into more discrete bits using eggs. Why not just stick with a huge tarball release or one single egg if it all has to be versioned through time to 99% of its consumers as one giant collection of software treated as a unit? But it doesn't have to be treated as a unit. I don't know what you mean with version through time to 99% of its customers. To me having releases of modules and releases of sets of modules is orthogonal and does not contradict each other. Then again, if Repoze doens't want to be a part of The Zope Framework users but always make their own set of modules, that will admittedly lessen the purpose of it, as the minimalistic attitude of Repoze.bfg would work as a good test of what should be in the framework in the first place. Right. No one except people who've already bought in to the notion of Zope software as one huge pile will benefit from the lockstep centralized planning. I have the feeling that either you or me have completely misunderstood the proposal, because I don't think you are talking about the same proposal as me. Could we also agree that this would tend to result in better dependency partitioning (X depends on Y, I don't need Y, I just need X, let's fix that)? I don't see how these are related. When components are not treated as one giant pile, and it's expected that you should be able to use pieces of the pile selectively without buying in to some unrelated software, dependency management becomes far more brutal and realistic. Yes. And I still do not see how this is related to the proposal. It is expected that you should be able to use pieces of the pile selectively, and it will continue to be expected. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 10:04, Hermann Himmelbauer du...@qwer.tk wrote: What I don't see in your proposal is, how these subset-groups would be coordinated, which leads to the following: - How would these groups be formed? If there's nobody who encourages people to do so, They will be formed by people grouping together to work on a piece of software, if such a group is necessary. - Higher level package/groups may have a hard life in case basic packages/groups are not coordinated and all go their own way. Then these higher level groups will help coordinate the lower level packages. - How does some foreigner know, if a package is actively supported, umaintaned, deprecated etc.? How does he know, what packages exist, what they are good for and the like? For instance, I yesterday wrote that I use lovely.remotetask, then I was asked on the list why I did not use the (maybe better) zc.async package. Know why? I did not know that it existed. - I think, Zope 3 is not only about some seperate packages, but about a complete programming experience. Thus there needs to be some integrating force, that draws together all these packages, writes some documentation / tutorial / website etc. - Newbies won't be attracted by single packages. Instead, they want something complete. Who would be interested in Plone if it would consist of various packages that people would have to draw together by themselves, without decent documentation? To my mind, one key point is attracting more users. And that can only be done if we try to view things from an external, newbie-perspective. Some Ruby on Rails / Java / Turbogears programmer will only be attracted by some big picture but probably not by a collection of some subpackages. So, my impression is that there is a need for some steering group, that will, however, encourage people to form groups around packages and maintain them. The steering group would not and could not help with any of these problems. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 08:16:26 schrieb Lennart Regebro: On Wed, Mar 4, 2009 at 07:52, Chris McDonough chr...@plope.com wrote: Tather than reply in kind here, let me summarize: I'm glad we agree more than we disagree, and I apologize if I've attributed to you beliefs that you don't have. It's heartening to hear that you're in favor of most of the things I'm also in favor of. But we do have real differences in opinion I think. I'd rather be constructive than obstructionist here: at the end of each item below I ask for an opinion based on a suggestion. 1) I'm not in favor of a single steering group for the *entirety* of all Zope software. We've tried a similar thing in the past (via the foundation structure); it didn't work and I'm not sure how we'd expect things to turn out any differently this time. Instead, perhaps the focus of groups should be on some much smaller subset of Zope-related software (e.g. the zope.interface+zope.component group, the zope.schema group, the ZODB group, etc). Could we consider this? It's better certainly, but isn't this small enough in itself that these groups will form naturally by whoever is working on it? But isn't that the current situation? I think there are two scenarious when people will deal with a package in-depth on their own: 1) They found a bug: I made the experience that in case I find some bug and dig into some Zope 3 code, things tend to become very complicated and I often can't understand/fix it. For instance, I found some bug/misbehaviour regarding combination of virtual hosts and ++xyz++ URL-variables (forgot the name for that) and was not able to apply a clean fix due to lack of understanding. I could not find anyone on the list, who was responsible for that piece of code, so I did some hacking and never committed this (dirty) hack as it's certainly not up to the Zope 3 standards. 2) They want to extend a package: In order to do that, I'd first like to understand the package in-depth, so that my extensions don't break concepts and code. But it seems that there are many packages (and even core packages) where nobody seems to feel responsible for, or, I just don't know who it is and can therefore not get to the required information. If there's no one that is motivated by (1) or (2), the package is abandoned (although it may even have core functionality). And my impression is that this has already happend for some packages, which is bad. Therefore I think it would be a great advantage if there is some group that makes sure that each package has someone associated with, who has in-depth knowledge and maintains it. And if there is no interest in a package anymore and it's not used, this group may give it the status umaintained and kill it off. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 2:34 PM, Hermann Himmelbauer du...@qwer.tk wrote: [snip] - I think, Zope 3 is not only about some seperate packages, but about a complete programming experience. Thus there needs to be some integrating force, that draws together all these packages, writes some documentation / tutorial / website etc. +1 I believe packages developed as part of the Zope 3 project is here to stay for a long time (of course, after dependency cleanup some of them may become obsolete). This will happen even if some of the frameworks based on it are no more available. Regards, Baiju M ___ 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 )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 10:25:19 schrieb Lennart Regebro: On Wed, Mar 4, 2009 at 10:04, Hermann Himmelbauer du...@qwer.tk wrote: What I don't see in your proposal is, how these subset-groups would be coordinated, which leads to the following: - How does some foreigner know, if a package is actively supported, umaintaned, deprecated etc.? How does he know, what packages exist, what they are good for and the like? For instance, I yesterday wrote that I use lovely.remotetask, then I was asked on the list why I did not use the (maybe better) zc.async package. Know why? I did not know that it existed. - I think, Zope 3 is not only about some seperate packages, but about a complete programming experience. Thus there needs to be some integrating force, that draws together all these packages, writes some documentation / tutorial / website etc. - Newbies won't be attracted by single packages. Instead, they want something complete. Who would be interested in Plone if it would consist of various packages that people would have to draw together by themselves, without decent documentation? To my mind, one key point is attracting more users. And that can only be done if we try to view things from an external, newbie-perspective. Some Ruby on Rails / Java / Turbogears programmer will only be attracted by some big picture but probably not by a collection of some subpackages. So, my impression is that there is a need for some steering group, that will, however, encourage people to form groups around packages and maintain them. The steering group would not and could not help with any of these problems. Why? Can you elaborate? Who/what group woud play that central/integrating role? Maybe we have different perceptions of a steering group, but my impression was that this group would see the above points as their key topics. Maybe I don't get your point, but your suggestion seems to be to let things go in a natural flow as it happens now. But that would imply that the current situation is satisfying, which seems not to be, as can be read in all those various posts regarding this topic. What would be further interesting is, if there are any successful open-source projects, that implement such a non-leadership/natural flow model, because I'm not aware of any. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 10:56, Hermann Himmelbauer du...@qwer.tk wrote: Am Mittwoch 04 März 2009 10:25:19 schrieb Lennart Regebro: On Wed, Mar 4, 2009 at 10:04, Hermann Himmelbauer du...@qwer.tk wrote: What I don't see in your proposal is, how these subset-groups would be coordinated, which leads to the following: - How does some foreigner know, if a package is actively supported, umaintaned, deprecated etc.? How does he know, what packages exist, what they are good for and the like? For instance, I yesterday wrote that I use lovely.remotetask, then I was asked on the list why I did not use the (maybe better) zc.async package. Know why? I did not know that it existed. [...] The steering group would not and could not help with any of these problems. Why? Can you elaborate? Who/what group woud play that central/integrating role? Maybe we have different perceptions of a steering group, but my impression was that this group would see the above points as their key topics. I don't think it's possible, and it seems to me to be a rather strange idea to have a group keep track of all the packages in the Zope world and somehow categorize them by quality. And it is in any case in no way even remotely connected to the group Martijn proposed and has been discussed in this thread. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Tue Mar 3 12:00:00 2009 UTC to Wed Mar 4 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue Mar 3 20:21:23 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011223.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Mar 3 20:23:28 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011224.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Tue Mar 3 20:25:28 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011225.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Tue Mar 3 20:27:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011226.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Tue Mar 3 20:29:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011227.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Tue Mar 3 20:31:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011228.html ___ 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 )
Re: [Zope-dev] Review of zc.dict tlotze-blist branch
On Mar 4, 2009, at 2:20 AM, Thomas Lotze wrote: Gary Poster gary.pos...@gmail.com schrieb: Index: src/zc/dict/configure.zcml === --- src/zc/dict/configure.zcml (.../trunk) (revision 0) +++ src/zc/dict/configure.zcml (.../branches/tlotze-blist) (revision 97211) @@ -0,0 +1,5 @@ +configure xmlns=http://namespaces.zope.org/zope; + + include package=.generations / + +/configure configure.zcml has a semantic of always include. Because the generations code may not work for many people (as we've discussed before, and see comment in evolve test below), I'd prefer that the generations code have a semantic of optionally include. Therefore, I suggest you rename this to generations.zcml or something like that. Wouldn't it be simpler to just remove this file as it does nothing but include the configure.zcml of a sub-package? Using the generations configuration would then read include package=zc.dict.generations / instead of include package=zc.dict file=generations.zcml / which wouldn't be for the worse either IMO. +1, good idea Also as mentioned before on the Zope list, until this API is deprecated in favor of one that encourages more granular changes, the change to blist only really helps the story for adding new items to an ordered dict. The Plone IExplicitOrdering interface looks reasonable, and could really take advantage of the blist characteristics. I do have that on my to-do list. Do you think we should add some comment about this to the code? I think the current performance characteristics are important to note somewhere, at least. Even CHANGES would be sufficient. Thanks, Gary ___ 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 )
Re: [Zope-dev] the Zope Framework project
On 3/4/09 1:07 AM, Chris McDonough wrote: Martin Aspeli wrote: Chris McDonough wrote: Sorry, the you above in you scolded was Martin Aspeli, not Faassen. Note that the scolding had something to do with you breaking Plone trunk due to a transitive change in Chameleon, and the realisation that from this point on, any package shared between repoze.bfg and Plone (or anything else) that is configured with ZCML, will probably need to be forked. We found a workaround with Chameleon, but not one that will scale. The fix is totally scalable and completely correct. Chameleon.zpt just does not have any (real) ZCML anymore. Any package that has ZCML is, by definition, written for some framework as stuff that is meant to be overridden, otherwise it wouldn't be written as configuration. ZCML is unlike code in this way. If it wasn't meant to be overridden, it would be in code. All packages which are meant to be maximally useful outside the scope of that framework should be split into two things: the library portion, then some portion that contains ZCML for gluing in to some framework that wants ZCML in some specific configuration. When I read Martin's post, I had a similar reaction. Namely, that the convenience of the Uberthing (Plone in this case) will always trump the desire of packages trying to survive on their own for new audiences. At the time of the configuration scolding, I remember thinking: there's little interest here in Chameleon's goal to be bigger than Zope. Keep things convenient for us in Plone! Package sharing between repoze.bfg and Plone should not mean that BFG gets dragged down, paying for things it specifically doesn't want to eat. BFG never claimed to sign up for Plone's contracts. I sense the logic of Chris's position: if the Zope Framework is as big as every current use case in Zope2+Zope3+Grok+etc., with nine years of accumulations on each (3 forms systems in one of them), then we're missing the goal (IMO). We'll make life incrementally better for ourselves, but we'll still scare off the folks who aren't after Uberthing. Plone is going towards a smaller-and-smaller core that is only as big as the manpower to do a great job at keeping it stable. Meaning, very small. Hopefully the Zope Framework is a tiny little thing that pays only for what it eats. Hopefully the goal is to make a very good microframework (or even better, set of libraries). If you can't make the best configuration language possible because one line of includes to get trusted adapters is an unconscionable burden is the rule, then I know how this movie ends. --Paul ___ 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 )
Re: [Zope-dev] the Zope Framework project
Paul Everitt wrote: When I read Martin's post, I had a similar reaction. Namely, that the convenience of the Uberthing (Plone in this case) will always trump the desire of packages trying to survive on their own for new audiences. At the time of the configuration scolding, I remember thinking: there's little interest here in Chameleon's goal to be bigger than Zope. Keep things convenient for us in Plone! In this case, you totally misread my post. It broke for all users of zope.component, and I never, once, made the argument that Chameleon was part of Plone or should be driven purely by Plone's needs. I have no such pretentions, nor does anyone else I know, about this, or zope.* or the CMF package or, well, anything that is not expressly part of Plone. That particular discussion is over, though, and I have no interest in having it again. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] SVN: zope.component/branches/tseaver-wo_zope_deferred/
Tres Seaver wrote: Tres Seaver wrote: Log message for revision 97465: Branch removing zope.deferred. This checkin is the branch I had in mind when sketching out a non-CPython-only zope.component story today. Wonderful, +1 I think the change makes sense from the perspective of zope.component as an individual package. Please keep those contributions coming :) Hanno ___ 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 )
Re: [Zope-dev] the Zope Framework project
On 3/4/09 8:16 AM, Martin Aspeli wrote: Paul Everitt wrote: When I read Martin's post, I had a similar reaction. Namely, that the convenience of the Uberthing (Plone in this case) will always trump the desire of packages trying to survive on their own for new audiences. At the time of the configuration scolding, I remember thinking: there's little interest here in Chameleon's goal to be bigger than Zope. Keep things convenient for us in Plone! In this case, you totally misread my post. It broke for all users of zope.component, and I never, once, made the argument that Chameleon was part of Plone or should be driven purely by Plone's needs. I have no such pretentions, nor does anyone else I know, about this, or zope.* or the CMF package or, well, anything that is not expressly part of Plone. Chameleon provided something that made it work for those users, while allowing it to not be burdened by those needs. Everybody wins. Hopefully such solutions will be the norm in the future. That particular discussion is over, though, and I have no interest in having it again. These two paragraphs seem contradictory. [wink] We'll consider the matter closed. --Paul ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Thu, Mar 5, 2009 at 3:04 AM, Hermann Himmelbauer du...@qwer.tk wrote: Am Mittwoch 04 März 2009 07:52:09 schrieb Chris McDonough: Tather than reply in kind here, let me summarize: I'm glad we agree more than we disagree, and I apologize if I've attributed to you beliefs that you don't have. It's heartening to hear that you're in favor of most of the things I'm also in favor of. But we do have real differences in opinion I think. I'd rather be constructive than obstructionist here: at the end of each item below I ask for an opinion based on a suggestion. 1) I'm not in favor of a single steering group for the *entirety* of all Zope software. We've tried a similar thing in the past (via the foundation structure); it didn't work and I'm not sure how we'd expect things to turn out any differently this time. Instead, perhaps the focus of groups should be on some much smaller subset of Zope-related software (e.g. the zope.interface+zope.component group, the zope.schema group, the ZODB group, etc). Could we consider this? What I don't see in your proposal is, how these subset-groups would be coordinated, which leads to the following: - How would these groups be formed? If there's nobody who encourages people to do so, - Higher level package/groups may have a hard life in case basic packages/groups are not coordinated and all go their own way. - How does some foreigner know, if a package is actively supported, umaintaned, deprecated etc.? How does he know, what packages exist, what they are good for and the like? For instance, I yesterday wrote that I use lovely.remotetask, then I was asked on the list why I did not use the (maybe better) zc.async package. Know why? I did not know that it existed. - I think, Zope 3 is not only about some seperate packages, but about a complete programming experience. Thus there needs to be some integrating force, that draws together all these packages, writes some documentation / tutorial / website etc. - Newbies won't be attracted by single packages. Instead, they want something complete. Who would be interested in Plone if it would consist of various packages that people would have to draw together by themselves, without decent documentation? To my mind, one key point is attracting more users. And that can only be done if we try to view things from an external, newbie-perspective. Some Ruby on Rails / Java / Turbogears programmer will only be attracted by some big picture but probably not by a collection of some subpackages. So, my impression is that there is a need for some steering group, that will, however, encourage people to form groups around packages and maintain them. I envision a Council of Elders with student representation. The Elders either know, or know who knows the history and current state of affairs, the students know the struggles of the newbies. They could provide welcome wagon, triage, and guide service for navigating the Zope wilds. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - zope-...@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 ) ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi Paul Betreff: Re: [Zope-dev] the Zope Framework project On 3/4/09 8:16 AM, Martin Aspeli wrote: [...] Chameleon provided something that made it work for those users, while allowing it to not be burdened by those needs. Everybody wins. Hopefully such solutions will be the norm in the future. That particular discussion is over, though, and I have no interest in having it again. I hope not! I don't like to have any code in an application which I don't use. But right now I don't see a better solution for the chicken and egg problem we have with z3c.pt and chameleon support in our base packages. In older days we used monkey patches for that problem, but that's no solution anymore. Regards Roger Ineichen These two paragraphs seem contradictory. [wink] We'll consider the matter closed. --Paul ___ 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 ) ___ 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 )
Re: [Zope-dev] SVN: zope.component/branches/tseaver-wo_zope_deferred/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Korostelev wrote: 2009/3/4 Tres Seaver tsea...@palladion.com: - - Due to the 'test' extra, buildout pulls in a bunch of extra dependencies, which I would like to zap (ZODB? really? just to verify that the persistent registry survives 'dumps' and 'loads'?) - - 'setup.py test' needs 'zope.testing', but then doesn't do anything (missing metadata). If I added the metadata, the tests would then pull in those extra packages: maybe I'll work on trimming them down, too. What's the motivation behind removing test dependenices for functionality that actually requires these dependencies, like ZODB/hookable/etc.? I was misled by the fact that ZODB isn't imported, except for testing:: [/home/tseaver/projects/Zope-CVS/zope.component-trunk] $ find src/ -name *.py | \ xargs grep -E (from ZODB)|(import ZODB) src/zope/component/tests.py: import ZODB.tests.util src/zope/component/tests.py: import ZODB.tests.util src/zope/component/tests.py: import ZODB.tests.util The actual import is 'persistent': $ find src/ -name *.py | \ xargs grep -E (from BTrees)|(import BTrees) $ find src/ -name *.py | \ xargs grep -E (from persistent)|(import persistent) src/zope/component/tests.py:import persistent src/zope/component/persistentregistry.py:import persistent.mapping src/zope/component/persistentregistry.py:import persistent.list This seems to me like a good candidate for splitting out the persistent registry into a separate package. Right now, the 'extra' means that the package can be *installed* without the ZODB dependencies, but it can't be properly *tested* without them. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrpSv+gerLs4ltQ4RAhaVAJwNDdHUgb4zxO1hSCmo2NzeZH2rkgCbBSz9 2IJTlcwJxzfmsM3/dC+Of0Y= =ko+r -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 )
Re: [Zope-dev] the Zope Framework project
On 3/4/09 9:47 AM, Roger Ineichen wrote: Hi Paul Betreff: Re: [Zope-dev] the Zope Framework project On 3/4/09 8:16 AM, Martin Aspeli wrote: [...] Chameleon provided something that made it work for those users, while allowing it to not be burdened by those needs. Everybody wins. Hopefully such solutions will be the norm in the future. That particular discussion is over, though, and I have no interest in having it again. I hope not! I don't like to have any code in an application which I don't use. But right now I don't see a better solution for the chicken and egg problem we have with z3c.pt and chameleon support in our base packages. In older days we used monkey patches for that problem, but that's no solution anymore. I agree, and I think this case is a good exemplar for the challenge. Chameleon wanted to make a good templating engine that was independent of megaframeworks. For that, it needed/wanted a configuration language that met your statement I don't like to have any code...I don't use. But legacy in one of the projects changed this from a self-contained, 1x amount of work into a cobweb of bigger issues, control in the hands of others, and 10x the work. Human nature says that's demoralizing. Hopefully the Zope Framework proposal helps untangle this, and gets to a point where you don't have to keep the Uberthing in your head when doing something small. --Paul ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there,
Hanno Schlichting wrote:
[snip]
You can try to bake more leadership of the overall Zope community into
this, but I think this is a fruitless fight right now. Reduce the scope,
try make some things better and don't step on other peoples feet if you
don't need to. For example don't try to push out style-guides for the
entirety of the svn.zope.org repository. They lead to bike-shed
discussions and discourage contributions.
Yes, I agree with restricting scope. I wanted to restrict scope to a set
of libraries that's shared between a bunch of the big consumer projects,
and that I called the Zope Framework. It's not something you install
by itself, and it's not something that everybody uses every bit of. But
it is something that is shared by a lot of people and we need to take
responsibility for and manage as a whole, not just as a whole bunch of
parts.
Beyond that in our repository, the framework steering group would have
influence but no authority. The document reflects that thinking.
Repository-wide guidelines do exist, such as the copyright assignment
policy, and the general 'trunk'/'branches'/'tags' structure of projects,
and the way people name distributions of packages the same name as the
package name ('zope.foo' is released as 'zope.foo'), and I'm sure we can
come up with many more of such conventions. It's not something for the
Zope Framework group to care about though. Part of that will just happen
by consensus and example anyway, but outside of the realm of the Zope
Framework Steering Group.
Regards,
Martijn
___
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 )
Re: [Zope-dev] the Zope Framework project
Hey there, Chris McDonough wrote: 1) I'm not in favor of a single steering group for the *entirety* of all Zope software. We've tried a similar thing in the past (via the foundation structure); it didn't work and I'm not sure how we'd expect things to turn out any differently this time. Instead, perhaps the focus of groups should be on some much smaller subset of Zope-related software (e.g. the zope.interface+zope.component group, the zope.schema group, the ZODB group, etc). Could we consider this? I don't recall we actually did anything within the Foundation structure. The structure was there in the bylaws but was never applied, so I don't think that can be qualified as a failure. :) The steering group isn't intended to take a responsibility for the entirety of the Zope software. Zope 2, Grok and the Zope 3 app server (which would be a distinct entity) would manage themselves and the Zope Framework steering group would not have a say over the libraries and configuration they add. I do think the steering group should start worrying about a larger amount of the libraries rather than a small set. Part of the reason is exactly so we *can* identify subsets and properly delegate their management. Delegating their management will require some kind of agreement on groups coordinating however. We need to have an overview of the whole in order to know how to evolve the parts in many cases. For instance, if we move some class due to a dependency cleanup, we need to have an effort to update the libraries in the whole to use the new imports relations. I do also think that we should go to a smaller set of libraries. We currently share a huge amount of code that only one consumer actually uses. For instance, I think all of the zope.app.* packages which contain ZMI code can eventually be left to the management of the Zope 3 developers, meaning they'd not be part of the Zope Framework anymore. The ZODB is a good example where I'm not sure whether the ZODB should be considered part of the Zope Framework at all. I think we should see this as an external library that the framework builds on. The idea that there is a bunch of people who take the responsibility for managing the whole doesn't mean they should be obstructing moves to improve the parts. Similarly I assume you're taking some form of responsibility for Repoze and that this is helpful the evolution of the parts of it. My hope is that we'll see more of a catalyst function than anything else. I think the answer to proposed changes in the lower layers (which is always risky) should be to point out potential risks and say: we can make this change, but we also need to make sure we do X. The answer should typically not be no. If it is a no, we should actively try to identify the use cases driving the proposed change and look for alternative solutions. 2) I'm also not in favor of a giant lockstep set of software versions shared between notional releases Zope 3.5, Grok, and Zope 2.12. I can only see this as continuing our mistakes of old by trying to treat some collection of software as Zope as opposed to letting parts of it survive or die on their own based on merit; it'd be more effective to just let each framework use (or disuse!) whatever versions of stuff that work best for it. That's why the software is broken out into individual components in the first place; we should encourage diversity in component usage. Instead of trying to legislate and bless some set of components as a version, we should just work to make each piece better and worthwhile to use independently; it's value would be in its actual usefulness rather than some belief that it works well with the other components in the version. I don't understand why you think a list of versions that has release numbers that we know works together is a blocker for independent evolution for the individual libraries. I think there are two parallel efforts: * evolving libraries standalone. We should improve those libraries so we can think about them standalone. If a library contains ZMI code, it's harder to think about it standalone for instance. * making sure that there is a list of library versions that people can install that isn't broken. That is, run the tests for these libraries in isolation and together. If a decision was made to change one library, make sure that all the other libraries in the list are updated so they actually still work. I see both efforts as necessary. If you just care about a smaller list of libraries, you don't have to worry about a larger list of course, though you will have to coordinate with some people who do. You probably can do quite well constructing your own list as it's a much smaller one. That's fine, and nothing should stop you. But the reality is that many people in this group *do* care about a larger list of libraries. Could we at least agree that lockstep versioning of a huge set of
Re: [Zope-dev] the Zope Framework project
Hi there, Andreas Jung wrote: [snip] This would definitely make sense to me. With respect to a steering committee: I am also a bit skeptical about such a committee. I think that the upcoming ZF board will have a good representation of each Zope project on the board in order to address things on the board level. You haven't read my document very well if you think I'm proposing a Steering Group for all Zope projects. I don't agree the Zope Foundation board should directly steer development of the Zope software. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wednesday 04 March 2009, Martijn Faassen wrote: I don't agree the Zope Foundation board should directly steer development of the Zope software. I totally agree. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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 )
Re: [Zope-dev] the Zope Framework project
Chris McDonough wrote: [snip] This just seems like a blindingly obvious antigoal to actually breaking apart the software into more discrete bits using eggs. Why not just stick with a huge tarball release or one single egg if it all has to be versioned through time to 99% of its consumers as one giant collection of software treated as a unit? Why not: * Repoze and others couldn't use the bits they care about. * Grok (or anything else) couldn't diverge from a common KGS when it needs to. * individual apps couldn't diverge from a common KGS when *they* need to. * A clear set of explicit, layered dependencies in software is generally a good thing. We can start thinking about smaller pieces better. By splitting up into individually packaged and released bits, we are forced to think about these things more. I don't see this as at all incompatible with a group managing a list of versions that is known to work together, as a service to various groups which do need such lists anyway. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Baiju M wrote: On Wed, Mar 4, 2009 at 2:34 PM, Hermann Himmelbauer du...@qwer.tk wrote: [snip] - I think, Zope 3 is not only about some seperate packages, but about a complete programming experience. Thus there needs to be some integrating force, that draws together all these packages, writes some documentation / tutorial / website etc. +1 I believe packages developed as part of the Zope 3 project is here to stay for a long time (of course, after dependency cleanup some of them may become obsolete). This will happen even if some of the frameworks based on it are no more available. I'm fine if some people want to get together and organize Zope 3 to offer an integrated experience. Zope 3 is the thing people install and start projects with. It's what should have a website explaining what it is all about. It's not what the Zope Framework Steering Group cares for however. It doesn't directly care for Zope 3. Zope 3 is explictly *not* the Zope Framework project, just like Grok isn't the Zope Framework project. Both have a stake in the project and will participate in the project, but just like the Zope Framework Steering Group doesn't manage grok.zope.org, it won't manage zope3.zope.org (if such a thing exists) either. While I'm quite interested in volunteering to help coordinate Zope Framework development, I'm not at all interested in volunteering to help coordinate Zope 3 app server development. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04.03.2009 17:26 Uhr, Martijn Faassen wrote: Hi there, Andreas Jung wrote: [snip] This would definitely make sense to me. With respect to a steering committee: I am also a bit skeptical about such a committee. I think that the upcoming ZF board will have a good representation of each Zope project on the board in order to address things on the board level. You haven't read my document very well if you think I'm proposing a Steering Group for all Zope projects I wasn't proposing that. I wanted to point out that the persons on the board could work out on proposal or on some agreement how to approach the controversial points...basically to layout a consensus plan. This not about steering the development but about finding some overall consensus. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmuszUACgkQCJIWIbr9KYwcbgCglkri5JcNPKHAQu/pWGcYWgUM WNIAoKQXa0HW404juEf/6zDo1ENdnjhU =h1TJ -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 17:48, Martijn Faassen faas...@startifact.com wrote: Note that the Zope Steering group is not about packages that are not in the framework, so if lovely.remotetask isn't there, it can say little. Which is exactly my point. It surely isn't at the moment, and I don't see that it should be any time soon. What Hermann suggested is somebody that keeps track of all Zope software modules and tells him which is good and which is bad. That's not what you suggested, and as mention, I don't think it's even possible, and definitely not a good idea. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Paul Everitt wrote: [snip] Hopefully the Zope Framework proposal helps untangle this, and gets to a point where you don't have to keep the Uberthing in your head when doing something small. It's not small, as it has an impact on a lot of things that build on zope.component. Changing things low in something that lots of people have built stacks on is almost never a small change. Just look at Python 3, which makes a bunch of actually rather small but still incompatible changes to the language. While small from the perspective of the language, they're *huge* from the perspective of the users. So you need ways to coordinate such changes. I hope that having someone actually taking responsibility for zope.component's evolution can get the zope.security dependency out of it, and then improvements of repoze.zcml into it, or alternatively move the ZCML implementations *entirely* out of zope.component. I hope Chris will coordinate with us where necessary. I don't want security bits to sit around in zope.component either. grokcore.component doesn't need that code, just like repoze.zcml doesn't need that code. It's still there, even if you use repoze.zcml, just inactive. I tried to propose various ways forward. I got nowhere as I got 10 people giving 10 answers. Original problem unresolved. I'd like there to be someone who can make this decision and I'd like this someone to usually make *positive* decisions that work towards resolving the underlying issue, while coordinating with everybody that is impacted by this decision. The zope.component ZCML case was very much in my head as I wrote this proposal. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 18:03, Martijn Faassen faas...@startifact.com wrote: I'd like there to be someone who can make this decision and I'd like this someone to usually make *positive* decisions that work towards resolving the underlying issue, while coordinating with everybody that is impacted by this decision. But we know pretty much who is impacted by this, and the people with enough gravitas to be able to say Yay or Nay to these sorts of refactoring. And they are all on this list. And if there was a Steering Group, most of them would need to be on that group. If it's impossible for these people to agree when discussing on this mailing list today, why would the suddenly agree on this mailing list if we call them The Zope Framework Steering Group? I really don't understand that. I think it is WAY more likely that we get agreement and come forward if we first of all stop having the internet between us. We all know how easy it is to misunderstand intentions and tone of voices on mailing lists as compared to real life. And if it *still* is impossible for these people to agree, then I can't see the Steering Group working either, and then we need a new dictator. But I don't think that's needed, because the technical disagreements we have here are so minor, and seems mostly based in massinderstindung. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] Zope2 trunk: getting 'mkzopeinstance' / 'mkzeoinstance' working
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
Hanno Schlichting wrote:
Tres Seaver wrote:
Hanno Schlichting wrote:
I looked at this, but guessing or reliably getting to the zopepy script
wasn't possible. So I added an explicit option to the script instead and
documented it. You can now use:
bin/mkzopeinstance --python=bin/zopepy
on the SVN trunk. You can omit this option and it will use
sys.executable as before.
Maybe we can detect buildout vs. tarball (e.g., the presence of
'buildout.cfg' vs. 'makefile'?)
What you have available inside the mkzopeinstance script is:
sys.executable which is just your regular Python interpreter and then
sys.argv which is ./bin/mkzopeinstance.
As the 'zopepy' script can be called anything, I don't see how you can
be smarter here.
I'm not worried about generalities: I think that 'mkzopeinstance'
should work from inside a SVN checkout of the Zope2 trunk, where the
script is going to have a known hame. Something like this::
--- src/Zope2/utilities/mkzopeinstance.py (revision 97232)
+++ src/Zope2/utilities/mkzopeinstance.py (working copy)
@@ -50,6 +50,9 @@
skelsrc = None
python = None
+if check_buildout():
+python = os.path.abspath('bin/zopepy')
+
for opt, arg in opts:
if opt in (-d, --dir):
skeltarget = os.path.abspath(os.path.expanduser(arg))
@@ -186,5 +189,14 @@
fp.close()
os.chmod(fn, 0644)
+def check_buildout():
+ Are we running from within a buildout which supplies 'zopepy'?
+
+if os.path.exists('buildout.cfg'):
+from ConfigParser import RawConfigParser
+parser = RawConfigParser()
+parser.read('buildout.cfg')
+return 'zopepy' in parser.sections()
+
if __name__ == __main__:
main()
Any objections if I check this in?
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJrrfo+gerLs4ltQ4RAg9nAKCMz3Vv9FJTD83E5g4EPE3OrWlIYwCgqkHF
++1Zv8K5hM/H3KH0jE0ZfUw=
=dn0X
-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 )
Re: [Zope-dev] Zope2 trunk: getting 'mkzopeinstance' / 'mkzeoinstance' working
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04.03.2009 18:18 Uhr, Tres Seaver wrote:
Tres Seaver wrote:
Hanno Schlichting wrote:
Tres Seaver wrote:
Hanno Schlichting wrote:
I looked at this, but guessing or reliably getting to the zopepy script
wasn't possible. So I added an explicit option to the script instead and
documented it. You can now use:
bin/mkzopeinstance --python=bin/zopepy
on the SVN trunk. You can omit this option and it will use
sys.executable as before.
Maybe we can detect buildout vs. tarball (e.g., the presence of
'buildout.cfg' vs. 'makefile'?)
What you have available inside the mkzopeinstance script is:
sys.executable which is just your regular Python interpreter and then
sys.argv which is ./bin/mkzopeinstance.
As the 'zopepy' script can be called anything, I don't see how you can
be smarter here.
I'm not worried about generalities: I think that 'mkzopeinstance'
should work from inside a SVN checkout of the Zope2 trunk, where the
script is going to have a known hame. Something like this::
--- src/Zope2/utilities/mkzopeinstance.py(revision 97232)
+++ src/Zope2/utilities/mkzopeinstance.py(working copy)
@@ -50,6 +50,9 @@
skelsrc = None
python = None
+if check_buildout():
+python = os.path.abspath('bin/zopepy')
+
for opt, arg in opts:
if opt in (-d, --dir):
skeltarget = os.path.abspath(os.path.expanduser(arg))
@@ -186,5 +189,14 @@
fp.close()
os.chmod(fn, 0644)
+def check_buildout():
+ Are we running from within a buildout which supplies 'zopepy'?
+
+if os.path.exists('buildout.cfg'):
+from ConfigParser import RawConfigParser
+parser = RawConfigParser()
+parser.read('buildout.cfg')
+return 'zopepy' in parser.sections()
+
if __name__ == __main__:
main()
Any objections if I check this in?
Not from my side.
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkmuuQkACgkQCJIWIbr9KYy44QCePL1et0sbZuiercxnG8b5JT1K
I4cAnR255teqWV4IKdegbcTiKOJUOeH2
=TFgh
-END PGP SIGNATURE-
begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd. Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard
___
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 )
Re: [Zope-dev] the Zope Framework project
Andreas Jung wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04.03.2009 17:26 Uhr, Martijn Faassen wrote: Hi there, Andreas Jung wrote: [snip] This would definitely make sense to me. With respect to a steering committee: I am also a bit skeptical about such a committee. I think that the upcoming ZF board will have a good representation of each Zope project on the board in order to address things on the board level. You haven't read my document very well if you think I'm proposing a Steering Group for all Zope projects I wasn't proposing that. I wanted to point out that the persons on the board could work out on proposal or on some agreement how to approach the controversial points...basically to layout a consensus plan. This not about steering the development but about finding some overall consensus. If you're talking about consensus about code, that's really not my vision of what the Zope Foundation board is for. I do think the Zope Foundation board might do something about community organization. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote: snip * A clear set of explicit, layered dependencies in software is generally a good thing. We can start thinking about smaller pieces better. By splitting up into individually packaged and released bits, we are forced to think about these things more. (I'm running out of steam on responses here. This will likely be one of the last). You've been saying this: we'll just identitfy and maintain this giant set of versions for backwards compatibility purposes and for purposes of *moving platforms forward through time*. But you also seem to be saying *real soon now* we'll also be making hard choices about the life and death of things that make up the 'framework' and evaluating each on its merit as an idependent entity. Personally, I disbelieve that this real soon now will ever happen without having it as the *primary* and maybe the *only* goal. I believe to get success here (measured as gaining new Python developer users), our path forward needs to be way, way, way more radical and needs to involve making hard choices that treat individual packages on their own merit rather than even considering their role as part of a larger collection. That's the bottom line and I believe it's our fundamental point of disagreement. IMO, the part a package plays as part of the larger collection should be utterly and brutally subservient to its merit as a standalone package. Also IMO, if there were absolutely no list of versions known to work together, but each piece worked on its own and had merit on its own, we'd be in a far better place as far as attracting new users. Any list of packages-known-to-work-together should be a oh, by the way, this might be handy, not the raison d'etre of the group and this discussion. I don't see this as at all incompatible with a group managing a list of versions that is known to work together, as a service to various groups which do need such lists anyway. Maybe not. But as far as I can tell, maintaining such a list is just business as usual and doesn't require any proposal at all. - C ___ 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 )
Re: [Zope-dev] the Zope Framework project
Lennart Regebro wrote: On Wed, Mar 4, 2009 at 17:48, Martijn Faassen faas...@startifact.com wrote: Note that the Zope Steering group is not about packages that are not in the framework, so if lovely.remotetask isn't there, it can say little. Which is exactly my point. It surely isn't at the moment, and I don't see that it should be any time soon. What Hermann suggested is somebody that keeps track of all Zope software modules and tells him which is good and which is bad. That's not what you suggested, and as mention, I don't think it's even possible, and definitely not a good idea. I think it would be possible to provide an infrastructure so that people who care about communicating certain bits of information (this package exists and here is its documentation, this package is really not maintained and therefore deprecated) could do so. Perhaps this infrastructure will be developed as a side-effect of what needs to be done for those libraries in the Zope Framework anyway. Regards, Martijn ___ 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 )
Re: [Zope-dev] SVN: zope.component/branches/tseaver-wo_zope_deferred/
Hi there, I think all this makes sense, so +1 from me. Regards, Martijn ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
Baiju M wrote: On Tue, Mar 3, 2009 at 2:35 PM, Dan Korostelev nad...@gmail.com wrote: 2009/3/2 Tres Seaver tsea...@palladion.com: -include package=zope.file/ I believe people still use the ZCML slug files like the above. They certainly aren't related to 'zpkg'. The intent of the slugs was to allow for something like 'sites-available' / 'sites-enabled' (the pattern in a stock Debian Apache2 install). I think it is particularly unfortunate to remove support for explicit, granular configuration at the same time as folks seem to be jumping to implicit (aka majyk) tools. Please revert this part of the change. I just reverted the change, however, I don't think that the slug files are useful anymore. I cannot see similar slugs in other packages either. Agreed. I don't understand Tres's or Benji's point either; thanks to buildout we've left such slugs long behind us I thought. Typically people would symlink these into an old old installation of Zope 3 (or copy them over). Explicit granular configuration isn't broken at all; if you want to explicitly include zope.file, you include its configure.zcml, not its zope.file-configure.zcml. Unless Tres comes back with some convincing explanation soon, please do get rid of this stuff. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 9:55 PM, Martijn Faassen faas...@startifact.com wrote: [snip] The steering group isn't intended to take a responsibility for the entirety of the Zope software. Zope 2, Grok and the Zope 3 app server (which would be a distinct entity) would manage themselves and the Zope Framework steering group would not have a say over the libraries and configuration they add. [snip] I do also think that we should go to a smaller set of libraries. We currently share a huge amount of code that only one consumer actually uses. For instance, I think all of the zope.app.* packages which contain ZMI code can eventually be left to the management of the Zope 3 developers, meaning they'd not be part of the Zope Framework anymore. [snip] As a service to the users of the Zope Framework, the Zope developers also make available lists of version numbers of core libraries that have been tested to work together as a Known Good Set. This receives a version number and is the Zope Framework release. Users of the Zope framework can use this list, but may also diverge from it where they see fit. Other projects (such as the Zope 3 application server and the Grok project) also have a Known Good Sets that expand on the Zope framework list (and may diverge from it). Each of these consumer projects can of course have their own release process, schedule and version numbering. [snip] It may very well be true that in some time we'll develop clusters of libraries that can be more or less managed on their own. The ZMI is such a cluster that I hope will eventually emerge (and that the Zope Framework Steering Group doesn't care about directly). That'd reduce the coordination overhead. But sometimes we do need to take coordinated action, and I don't see that need disappearing entirely. I think those who care about Zope 3 (framework/app server/libraries/ or whatever) should form a team and mailing list to discuss about the future development. All other major consumers of the Zope Framework Project has their on mailing list for discussions. I guess very soon zope-dev list will become inappropriate to discuss about Zope 3. Just like Grok,Repoze etc. it is better to create a list for Zope 3, may be re-activate zope3-dev list to discuss about the Zope 3 (framework/app server/libraries/ or whatever). Well, if no one cares about Zope 3, let's leave it. Regards, Baiju M ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, On Wed, Mar 4, 2009 at 6:26 PM, Chris McDonough chr...@plope.com wrote: Martijn Faassen wrote: snip * A clear set of explicit, layered dependencies in software is generally a good thing. We can start thinking about smaller pieces better. By splitting up into individually packaged and released bits, we are forced to think about these things more. (I'm running out of steam on responses here. This will likely be one of the last). You've been saying this: we'll just identitfy and maintain this giant set of versions for backwards compatibility purposes and for purposes of *moving platforms forward through time*. But you also seem to be saying *real soon now* we'll also be making hard choices about the life and death of things that make up the 'framework' and evaluating each on its merit as an idependent entity. Personally, I disbelieve that this real soon now will ever happen without having it as the *primary* and maybe the *only* goal. It can't be the only goal, we also want to build new stuff, right? Anyway, cleaning this stuff up is one of my most important goals for me personally; I and 5 others spent a week of our life doing that a month ago. Real soon now, zope.app.container and zope.app.folder and zope.app.keyreference and zope.app.catalog are not going to be the business of the Zope Framework developers anymore. They contain ZMI stuff the Zope Framework developers do not care about directly and will only care about indirectly if enough people speak up for it and are willing to work on it. I hope many of them join the real soon now. We have a line behind which I, and many others, don't have to care anymore. A receding line, leaving many things behind. I don't want to stop anyone else from caring about these other things. I can't anyway. If people do get together who want to develop Zope 3 the app server they should get together and organize. I hope I can convince them that this line is important and I hope I can convince people in general to care *more* about the stuff in the Zope Framework than anything else. The ZMI isn't the main thrust of Zope 3 development, and hasn't been for a long time anyway. I want to stop having to worry about it as soon as possible, and am willing to do work to get there. I believe to get success here (measured as gaining new Python developer users), I think success is not just python developer users, but also serving current users in the Zope 2, Zope 3 and Grok worlds better by having a more comprehensible platform. our path forward needs to be way, way, way more radical and needs to involve making hard choices that treat individual packages on their own merit rather than even considering their role as part of a larger collection. That's the bottom line and I believe it's our fundamental point of disagreement. IMO, the part a package plays as part of the larger collection should be utterly and brutally subservient to its merit as a standalone package. Look, I know you are not using the packages the way that I am, but can't we work together? I want these packages to make sense stand-alone very much, but I also need to consider them as part of a whole that needs to be managed. Also IMO, if there were absolutely no list of versions known to work together, but each piece worked on its own and had merit on its own, we'd be in a far better place as far as attracting new users. Any list of packages-known-to-work-together should be a oh, by the way, this might be handy, not the raison d'etre of the group and this discussion. I think the group needs to have a list of packages it cares about, so we know what we're talking about. That way we know which packages we need to document and present and clean up, and we know *what* code we want to move out of packages that are in that list. And none of these packages can be broken so they *need* to work together! And we also present a list of versions that we have tested together as a service to the people who need such lists. If we *don't* make such a list we'll remain in the limbo where *all* packages are of some nebulous importance. I don't see this as at all incompatible with a group managing a list of versions that is known to work together, as a service to various groups which do need such lists anyway. Maybe not. But as far as I can tell, maintaining such a list is just business as usual and doesn't require any proposal at all. We're maintaining a different list now, for the Zope 3 app server that you install. What's in the list is mainly just inertia and ad-hoc decision making. That's not the list I'm talking about, though there'll be tremendous overlap to start with. I'm proposing not just a different list but a community that cares about those libraries. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related
Re: [Zope-dev] the Zope Framework project
Chris McDonough wrote: I believe to get success here (measured as gaining new Python developer users), our path forward needs to be way, way, way more radical and needs to involve making hard choices that treat individual packages on their own merit rather than even considering their role as part of a larger collection. That's the bottom line and I believe it's our fundamental point of disagreement. IMO, the part a package plays as part of the larger collection should be utterly and brutally subservient to its merit as a standalone package. Also IMO, if there were absolutely no list of versions known to work together, but each piece worked on its own and had merit on its own, we'd be in a far better place as far as attracting new users. Any list of packages-known-to-work-together should be a oh, by the way, this might be handy, not the raison d'etre of the group and this discussion. + lots Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 18:27, Martijn Faassen faas...@startifact.com wrote: If it's impossible for these people to agree when discussing on this mailing list today, why would the suddenly agree on this mailing list if we call them The Zope Framework Steering Group? I really don't understand that. Two answers: * they wouldn't all be on the steering group Why not? They are the people who should have a say, and they are the people most likely to be able to actually implement the decisions. * the steering group is *tasked* with coming to a single answer that is recorded. And implement it? -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
[Zope-dev] Declaration of the foundation of the Zope Framework and Steering Group
Hi there, Enough discussion. I'm taking a few next steps so we can make progress. I'm going to arbitrarily assume we have enough of a consensus to move forward. Next step is to Just Do It, as Gary said. So, as of right now, we have the Zope Framework. We have a Zope Framework Steering Group. The membership of the Steering Group is Just Me to start with. I'm going to let 4 other people into the group and I'm going to risk offending people by excluding whoever I like. I'm of course going to do my best to work with everybody, in the Steering Group or not; we're just here to help keep things moving in a good set of directions. Who wants to join the Steering Group? Feel free to mail me in private. The Zope Framework is all the zope.* libraries, including all the zope.app.* libraries. That's way too big, it's ridiculous actually, and the priority of the steering group is to get that list down to size as soon as possible. Expect new smaller lists, and expect them to keep shrinking. The first project of the steering group is this: the Zope Framework shouldn't contain a trace of the ZMI. We're going to pull out anything that appears useful out of existing libraries and evict the ZMI out of the Zope Framework, one way or another. Please help, as the success of this project depends on you, Zope Hacker! If you want to make some change to the Zope Framework, start a thread on zope-dev about it. The Steering Group is watching. The Steering Group is going to make decisions in the following way: * a steering group member participates in discussions as normally, saying +1 or -1 or whatever alternative suggestions they may have. * if it's clear there's a consensus by the steering group, we will record the decision in a document in SVN to be announced. If not all steering group members voted and it's enough time later, fine, the decision is made by those who did care to contribute. * if there is no consensus by the steering group, the most votes by steering group members in the thread win. It is the task of the steering group to detect this and record it (or delegate its recording by someone else, even better). * if for some reason it's hard to count votes and get consensus in the Steering Group, people can point this out. Steering Group help, no consensus detected!. We will then reach a consensus. * If there's still no consensus, I'm going to flip a coin and that's going to be the answer. I'm going to do my best to avoid having to flip any coins, as it's very silly to decide on the flip of a coin. * If no steering group member participates in a discussion and consensus is reached, please proceed. Everything's fine. You only need to worry about the steering group if they're actually participating in a discussion or if you don't like the consensus or if no consensus is reached. Feel free to call in the Steering Group and it will fly in. It's not a bird, it's not a plane, it's the Steering Group! The Steering Group has no say over Zope 3, Grok, Zope 2 or whatever. Well, I do have some say over Grok, so currently the steering group is heavily biased towards what Grok wants. :) Regards, Martijn ___ 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 )
[Zope-dev] zope3docs - zopeframework?
Hi there, We have an area called 'zope3docs': http://svn.zope.org/zope3docs/ which contains many documents that are actually more about the Zope Framework than the Zope 3 app server. In fact I suspect all of these documents are more about the framework than anything else, so we should move them all over. http://svn.zope.org/zopeframework/trunk/ Opinions? Regards, Martijn ___ 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 )
[Zope-dev] decisions of the Zope Framework Steering Group
Hi there, This document contains the decisions made by the Zope Framework Steering Group: http://svn.zope.org/zopeframework/trunk/decisions.txt This is the project area for the zopeframework steering group: http://svn.zope.org/zopeframework/trunk It is currently designated to contain documents, no code. Regards, Martijn ___ 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 )
Re: [Zope-dev] zope3docs - zopeframework?
2009/3/4 Martijn Faassen faas...@startifact.com: Hi there, We have an area called 'zope3docs': http://svn.zope.org/zope3docs/ which contains many documents that are actually more about the Zope Framework than the Zope 3 app server. In fact I suspect all of these documents are more about the framework than anything else, so we should move them all over. http://svn.zope.org/zopeframework/trunk/ Opinions? Well, that docs are currently not necessarily about the zope framework (as far as I understood what's zope framework now), but more about general development guidelines applied to any package in zope svn (except the migration section, maybe), but I personally don't have any objections, as it's still easy to find those docs and that's the most important. :-) -- WBR, Dan Korostelev ___ 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 )
Re: [Zope-dev] zope3docs - zopeframework?
Hi there, On Wed, Mar 4, 2009 at 8:05 PM, Dan Korostelev nad...@gmail.com wrote: [snip Well, that docs are currently not necessarily about the zope framework (as far as I understood what's zope framework now), but more about general development guidelines applied to any package in zope svn (except the migration section, maybe), but I personally don't have any objections, as it's still easy to find those docs and that's the most important. :-) I think following the Zope Framework model we should make these documents just apply to the source files in the Zope Framework, and let them serve as an example for other files. There's nobody who can *enforce* compliance though. Besides, lots of those guidelines won't apply to Zope 2 code anyway as far as I know. Well, there is a group that could force compliance for the entire repository, and that's the Zope Foundation (soon), but they care only about a few basic things. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hi there, Paul Everitt wrote: [snip] Hopefully the Zope Framework proposal helps untangle this, and gets to a point where you don't have to keep the Uberthing in your head when doing something small. It's not small, as it has an impact on a lot of things that build on zope.component. Changing things low in something that lots of people have built stacks on is almost never a small change. Just look at Python 3, which makes a bunch of actually rather small but still incompatible changes to the language. While small from the perspective of the language, they're *huge* from the perspective of the users. So you need ways to coordinate such changes. I hope that having someone actually taking responsibility for zope.component's evolution can get the zope.security dependency out of it, and then improvements of repoze.zcml into it, or alternatively move the ZCML implementations *entirely* out of zope.component. I hope Chris will coordinate with us where necessary. I don't want security bits to sit around in zope.component either. grokcore.component doesn't need that code, just like repoze.zcml doesn't need that code. It's still there, even if you use repoze.zcml, just inactive. I tried to propose various ways forward. I got nowhere as I got 10 people giving 10 answers. Original problem unresolved. I'd like there to be someone who can make this decision and I'd like this someone to usually make *positive* decisions that work towards resolving the underlying issue, while coordinating with everybody that is impacted by this decision. The zope.component ZCML case was very much in my head as I wrote this proposal. OK, can we table the proposal per se for the moment, and prototype the process around the how do we move zope.component forward question? I'm not even sure I understand why you think anything in repoze.zcml has squat to do with zope.component, but I could just be missing the obvious. I have a strawman proposal, focused on stripping zope.component down as far as possible: 1. Merge my branch which drops the deferred import stuff. 2. Move the persistent registry stuff out into another package, including whatever support is needed to allow for people to migrate existing persistent references. Effectively, this moves one extra out to a package, *including* its testing dependencies. 3. Move the ZCML directive implementations out into another package, taking the zope.security and zope.configuration dependencies along with them. 4. Rework zope.hookable to use a pure-Python implementation via descriptors, instead of the C extension. Make it a non-optional dependency (but small and lightweight) of zope.component. If *current* profiling shows that the hooked things are bottlenecks, make the C version and optional replacement for the Python version. At the end, we would have three packages: zope.component depends on: - zope.interface - zope.event - zope.hookable zope.componentzcml (BIKESHED NAMING ALERT) depends on: - zope.configuration - zope.security - zope.configuration - zope.proxy - zope.i18nmessageid zope.persistentregistry (BIKESHED NAMING ALERT) depends on: - zope.configuration - ZODB3 Folks could then work on refactoring the new packages (e.g., depending on a separate 'persistent' package, making the secuirity bits optional, etc.). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrv9u+gerLs4ltQ4RApPjAJ4nZKFNxrrpiQfXgR8YRxtgn4YMSQCgk4wx TnvvQUfwhVo2X64YAyPAdm0= =KDnz -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 )
Re: [Zope-dev] the Zope Framework project
Hey Tres, Could you repost this to a new thread as I think people aren't paying attention to this thread very much anymore? I'd very much like to make progress on actual cleanups now. Regards, Martijn ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Baiju M wrote: On Tue, Mar 3, 2009 at 2:35 PM, Dan Korostelev nad...@gmail.com wrote: 2009/3/2 Tres Seaver tsea...@palladion.com: -include package=zope.file/ I believe people still use the ZCML slug files like the above. They certainly aren't related to 'zpkg'. The intent of the slugs was to allow for something like 'sites-available' / 'sites-enabled' (the pattern in a stock Debian Apache2 install). I think it is particularly unfortunate to remove support for explicit, granular configuration at the same time as folks seem to be jumping to implicit (aka majyk) tools. Please revert this part of the change. I just reverted the change, however, I don't think that the slug files are useful anymore. I cannot see similar slugs in other packages either. Agreed. I don't understand Tres's or Benji's point either; thanks to buildout we've left such slugs long behind us I thought. Typically people would symlink these into an old old installation of Zope 3 (or copy them over). Explicit granular configuration isn't broken at all; if you want to explicitly include zope.file, you include its configure.zcml, not its zope.file-configure.zcml. Unless Tres comes back with some convincing explanation soon, please do get rid of this stuff. Those files exist to allow for a use case we may have abandoned, which is allowing packages to be installed in such a way that a tool could help users enable / disable their configurations, without mutating something like 'site.zcml'. The folks who might have that usecase are those who package zope3 components for deployment outside buildout (as .deb / .rpm, etc.) I don't know if there is such an audience; Benji also pointed out that he thought there were such folks. My initial reaction to Dan's removal was that the checkin message (remove zpkg stuff) had nothing to do with that particular change: 'zpkg' was entirely separate from slugs. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrxCW+gerLs4ltQ4RAlKOAJ4iMu+SQUceUq0w5Fh9+bmBNeALlACfTPAG N2Uc9sTzSBFXvy2Vh5LGw/g= =13vt -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 )
[Zope-dev] Stripping down zope.component
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (reposted at Martijn's request in a new thread). Martijn Faassen wrote: Hi there, Paul Everitt wrote: [snip] Hopefully the Zope Framework proposal helps untangle this, and gets to a point where you don't have to keep the Uberthing in your head when doing something small. It's not small, as it has an impact on a lot of things that build on zope.component. Changing things low in something that lots of people have built stacks on is almost never a small change. Just look at Python 3, which makes a bunch of actually rather small but still incompatible changes to the language. While small from the perspective of the language, they're *huge* from the perspective of the users. So you need ways to coordinate such changes. I hope that having someone actually taking responsibility for zope.component's evolution can get the zope.security dependency out of it, and then improvements of repoze.zcml into it, or alternatively move the ZCML implementations *entirely* out of zope.component. I hope Chris will coordinate with us where necessary. I don't want security bits to sit around in zope.component either. grokcore.component doesn't need that code, just like repoze.zcml doesn't need that code. It's still there, even if you use repoze.zcml, just inactive. I tried to propose various ways forward. I got nowhere as I got 10 people giving 10 answers. Original problem unresolved. I'd like there to be someone who can make this decision and I'd like this someone to usually make *positive* decisions that work towards resolving the underlying issue, while coordinating with everybody that is impacted by this decision. The zope.component ZCML case was very much in my head as I wrote this proposal. OK, can we table the proposal per se for the moment, and prototype the process around the how do we move zope.component forward question? I'm not even sure I understand why you think anything in repoze.zcml has squat to do with zope.component, but I could just be missing the obvious. I have a strawman proposal, focused on stripping zope.component down as far as possible: 1. Merge my branch which drops the deferred import stuff. .. note: I'm about to do this merge, based on positive feedback on the list. 2. Move the persistent registry stuff out into another package, including whatever support is needed to allow for people to migrate existing persistent references. Effectively, this moves one extra out to a package, *including* its testing dependencies. 3. Move the ZCML directive implementations out into another package, taking the zope.security and zope.configuration dependencies along with them. 4. Rework zope.hookable to use a pure-Python implementation via descriptors, instead of the C extension. Make it a non-optional dependency (but small and lightweight) of zope.component. If *current* profiling shows that the hooked things are bottlenecks, make the C version and optional replacement for the Python version. .. note: In the meanwhile, I have done the latter, with a pure-Python 'hookable' module in zope.component as a fallback for zope.hookable. At the end, we would have three packages: zope.component depends on: - zope.interface - zope.event - zope.hookable (optional) zope.componentzcml (BIKESHED NAMING ALERT) depends on: - zope.configuration - zope.security - zope.configuration - zope.proxy - zope.i18nmessageid zope.persistentregistry (BIKESHED NAMING ALERT) depends on: - zope.configuration - ZODB3 Folks could then work on refactoring the new packages (e.g., depending on a separate 'persistent' package, making the secuirity bits optional, etc.). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrxQl+gerLs4ltQ4RAgpLAJ0bOowoDHcKmcdolDjoFT+eTisUhACg2Bt0 wZ7SzkMMpBd1Q89z2qilc0Q= =Kl5M -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 )
[Zope-dev] the future of ZCML slugs?
Hi there, Tres Seaver wrote: [snip] Those files exist to allow for a use case we may have abandoned, which is allowing packages to be installed in such a way that a tool could help users enable / disable their configurations, without mutating something like 'site.zcml'. The folks who might have that usecase are those who package zope3 components for deployment outside buildout (as .deb / .rpm, etc.) True. Perhaps Brian Sutherland could tell us? I could certainly imagine automation that generated such slugs automatically and I don't believe such slugs exist many of our packages, so I suspect the use case has been abandoned quite a while ago. I don't know if there is such an audience; Benji also pointed out that he thought there were such folks. My initial reaction to Dan's removal was that the checkin message (remove zpkg stuff) had nothing to do with that particular change: 'zpkg' was entirely separate from slugs. That's true, it's unrelated. Let's see whether any of this audience will speak up and say they're still using slugs. I think that still shouldn't stop us from *still* getting rid of them, but let's gather a bit more information first. If we get no information, we should certainly get rid of them. I also took this opportunity to record our decision concerning ZPKG stuff (which isn't slugs, I'll record that separately when we reach a decision). Regards, Martijn ___ 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 )
Re: [Zope-dev] SVN: zope.component/trunk/ Merge the 'tseaver-wo_zope_deferredimport' branch:
Tres Seaver wrote: [snip] It probably could be (in fact, I prototyped it there first). However, it turns out that zope.hookable has effectively *no* clients beyond zope.component, which meant that I could lose the 'install_requires' dependency altogether by moving the pure-Python bits to zope.component. Thoughts, My thought is that if we treat zope.hookable as a library that stands on its own, which I believe is a principle we should follow, we should do what Dan suggests and move it into zope.hookable. But your discovery that zope.hookable isn't used anywhere else is an interesting one, so we need to weigh that against the opportunity to get rid of a separate library people need to understand. I think we can only make the correct determination if we get an idea of the performance implications. If it turns out the C code brings significant speedups in real-world applications, we should create a zope.hookable with a Python + C implementation. If not, we should get rid of zope.hookable altogether. Regards, Martijn ___ 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 )
Re: [Zope-dev] Stripping down zope.component
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: snip 4. Rework zope.hookable to use a pure-Python implementation via descriptors, instead of the C extension. Make it a non-optional dependency (but small and lightweight) of zope.component. If *current* profiling shows that the hooked things are bottlenecks, make the C version and optional replacement for the Python version. How do we do current profiling? The existing implementation is the result of Jim's work profiling component lookups back in 2002, using (I think) Python 2.2. I'm suggesting that we think about redoing the profiling against the versions we care about (2.5, 2.6), and reconsider whether pure-Python alternatives, using newer language features, might be sufficient. For another example of this idea, see my proposal last fall to reimplement the pickle cache inside persistent using pure Python: http://mail.zope.org/pipermail/zodb-dev/2008-September/012112.html Anyway, I'm +1 a pure-python implementation for zope.hookable, but we need to get some grasp of the performance implications nonetheless. Does anyone have any ideas on how determine the impact? At the moment, the trunk of zope.component will use zope.hookable if it is present, but fall back to a pure Python version if not. If any of the bench code Jim and others used back in the original optimization pass is still around, the comparing / profiling the two implementations is where I would start. snip To get back to repoze.zcml: it is my understanding that repoze.zcml contains some fixes to the way component registration is done in the context of multiple WSGI applications. I'm no expert on this myself, so I may understand this wrong, but that is my understanding. If that is correct, we could look at applying these lessons to zope.componentzcml. That isn't correct. repoze.zcml provides only alternative security-free directive handlers, registered in a separate XML namespace. If other folks want those handlers, they can use the package directly, or somebody could migrate them into another zope.* package. The trouble starts because we'd also need to apply those lessons to grokcore.component as well, which doesn't need to depend on zope.componentzcml at all. ZCML isn't really relevant: the problem I think you are worrying about is actually in zope.component (one global registry to rule them all). The bits I think you are talking about are inside repoze.bfg's component registry setup code: http://svn.repoze.org/repoze.bfg/trunk/repoze/bfg/registry.py which makes the global registry actually bound to a specific application. I don't know how reusable the code for that is, but the idea should be liftable. So it would seem applying this knowledge would touch quite a few places, and my instinct is to look for a way to share the implementation and knowledge in a single place. We might be able do this by placing some basic action implementations (or at least code that helps implementing such actions) in zope.component itself. This would NOT implement any ZCML directives nor introduce any dependencies (not even zope.configuration), but would be an API implementers of configuration mechanisms could then use. Perhaps this is overkill or not possible; I don't quite understand the issues involved, but I hope someone who does chips in. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJryLa+gerLs4ltQ4RAmGBAKDTJQUUxcisSbUoogkmhEdXxQkBHQCgr/9i o+4meVIViWXh7E/I6SwNies= =ptBg -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 )
[Zope-dev] zope.publisher
Hi Martijn, Shane I fixed some issues in zope.publisher and at the same time I implemented the default skin pattern within an adapter pattern. The adapter getDefaultSkin in zope.publisher.browser.py is registered in configure.zcml The changes are compatible within the zope core but only if zmcl is used. The concept is the following A request implementation can provide a named IDefaultSkin adapter within the name default. This default skin get used if no other default skin get defined. The IDefaultBrowserLayer is used as such a default adapter for IBrowserRequest. This was done hardcoded in setDefaultSkin before my changes. A default skin in your own projects get registered as an unnamed IDefaultSkin adapter. This is normaly done within the defaultSkin ZCML directive. Such a unnamed adapter get used before the setDefaultSkin method will lookup for the *fallback* named adapter. Everything is 100% compatible if the adapter configuration get used in configure.zcml. Questions - Everbody, Right now the setDefaultSkin method will silently fail if a skin doesn't provide ISkinType. What do you think should we raise an exception instead of silently ignore the skin? A general problem in the implemenation before and after my changes is that the skin interfaces registered by the defaultSkin ZCMl directive will register the interface as adapter which is not adaptable because it's not an adapter factory. Should we change the defaultSkin directive and register an adapter factory? This whould ensure that we don't have junk in the dapter registry. Another question The applySkin method removes all skin types from the request. Why do we not remove all skin types in setDefaultLayer? Are there any skins applied at the time we call setDefaultSkin? Martijn, Does grok need to register this new adapter somewhere? If the adapter configuration is missing the default skin apply pattern will break. Shane, Can you review and merge this changes into your zope.pipeline branch? Regards Roger Ineichen _ END OF MESSAGE ___ 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 )
[Zope-dev] Dependency of zope.deprecation in zope.configuration
Hi, zope.deprecation is used in zope.configuration *only* to turn off deprecation warning when accessing attribute of an object in one place. But there is no test case or comment about when such a warning will occur. I have pasted the relevant code here: def resolve(self, dottedname): Resolve a dotted name to an object. try: zope.deprecation.__show__.off() obj = getattr(mod, oname) zope.deprecation.__show__.on() return obj except AttributeError: zope.deprecation.__show__.on() # No such name, maybe it's a module that we still need to import try: return __import__(mname+'.'+oname, *_import_chickens) except ImportError: if sys.exc_info()[2].tb_next is not None: # ImportError was caused deeper raise raise ConfigurationError( ImportError: Module %s has no global %s % (mname, oname)) Can anyone point the reasoning behind turning off deprecation warning there. What kind of deprecation is expected, and why it should not be displayed ? Regards, Baiju M ___ 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 )
Re: [Zope-dev] zope.publisher
Roger Ineichen wrote: Shane, Can you review and merge this changes into your zope.pipeline branch? I'm going to put zope.pipeline on hold until the PyCon sprints. Jim and I need to discuss it in person; hopefully then I can understand his opposition and the group can decide on the best direction for zope.publisher and zope.app.publication. Shane ___ 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 )
Re: [Zope-dev] Dependency of zope.deprecation in zope.configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: Hi, zope.deprecation is used in zope.configuration *only* to turn off deprecation warning when accessing attribute of an object in one place. But there is no test case or comment about when such a warning will occur. I have pasted the relevant code here: def resolve(self, dottedname): Resolve a dotted name to an object. try: zope.deprecation.__show__.off() obj = getattr(mod, oname) zope.deprecation.__show__.on() return obj except AttributeError: zope.deprecation.__show__.on() # No such name, maybe it's a module that we still need to import try: return __import__(mname+'.'+oname, *_import_chickens) except ImportError: if sys.exc_info()[2].tb_next is not None: # ImportError was caused deeper raise raise ConfigurationError( ImportError: Module %s has no global %s % (mname, oname)) Can anyone point the reasoning behind turning off deprecation warning there. What kind of deprecation is expected, and why it should not be displayed ? Stephan added that code in revision 29143, four years ago now. He actually added the deprecation framework in that same revision. I would rip it out and see what warnings happen during a big test run: suppressing them doesn't look like a good plan to me. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJr2mU+gerLs4ltQ4RAt36AKCjWSU8tgWcLz/ldIOR1bhV+Y1MwgCgwyf6 uT2vXXedLl/YlVNiquIAWJI= =dzwK -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 )
Re: [Zope-dev] Dependency of zope.deprecation in zope.configuration
On Thu, Mar 5, 2009 at 11:26 AM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: Hi, zope.deprecation is used in zope.configuration *only* to turn off deprecation warning when accessing attribute of an object in one place. But there is no test case or comment about when such a warning will occur. I have pasted the relevant code here: def resolve(self, dottedname): Resolve a dotted name to an object. try: zope.deprecation.__show__.off() obj = getattr(mod, oname) zope.deprecation.__show__.on() return obj except AttributeError: zope.deprecation.__show__.on() # No such name, maybe it's a module that we still need to import try: return __import__(mname+'.'+oname, *_import_chickens) except ImportError: if sys.exc_info()[2].tb_next is not None: # ImportError was caused deeper raise raise ConfigurationError( ImportError: Module %s has no global %s % (mname, oname)) Can anyone point the reasoning behind turning off deprecation warning there. What kind of deprecation is expected, and why it should not be displayed ? Stephan added that code in revision 29143, four years ago now. He actually added the deprecation framework in that same revision. I would rip it out and see what warnings happen during a big test run: suppressing them doesn't look like a good plan to me. How to run these kind of big test run now-a-days, any pointer ? Thanks, Baiju M ___ 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 )
Re: [Zope-dev] zope3docs - zopeframework?
On Wed, 2009-03-04 at 20:50 +0100, Martijn Faassen wrote: Hi there, On Wed, Mar 4, 2009 at 8:05 PM, Dan Korostelev nad...@gmail.com wrote: [snip Well, that docs are currently not necessarily about the zope framework (as far as I understood what's zope framework now), but more about general development guidelines applied to any package in zope svn (except the migration section, maybe), but I personally don't have any objections, as it's still easy to find those docs and that's the most important. :-) I think following the Zope Framework model we should make these documents just apply to the source files in the Zope Framework, and let them serve as an example for other files. There's nobody who can *enforce* compliance though. Besides, lots of those guidelines won't apply to Zope 2 code anyway as far as I know. Well, there is a group that could force compliance for the entire repository, and that's the Zope Foundation (soon), but they care only about a few basic things. When I started putting in those documents I named it zope3docs initially although I suspected that they would apply to what now became the Zope Framework. The migration document would ne a slight revamp though, as we don't have Zope Framework releases, yet. As Dan pointed out, some of those documents are a bit more general than Zope Framework, but, then again, they're also more general than Zope 3. So even for that its better to have them in the Zope Framework area than Zope 3. Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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 )
Re: [Zope-dev] zope3docs - zopeframework?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 5, 2009, at 08:24 , Christian Theune wrote: As Dan pointed out, some of those documents are a bit more general than Zope Framework, but, then again, they're also more general than Zope 3. So even for that its better to have them in the Zope Framework area than Zope 3. Before anything is moved around please be aware that the zope3docs repository folder is used to rebuild http://docs.zope.org/zope3docs/ on a daily basis. So make sure you don't completely break it since the URL is now known, indexed and used. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmvg4wACgkQRAx5nvEhZLK0sgCeKvPJRd6OSzBpGY7SV1470yFq cF8AnR1ZFLTQdMdJpB36RJK+qgcL5hMG =dDsp -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 )
[Zope] sending a encrypted login URL
We'd like to construct a zope login URL of the form on another server: http://zope.domain:port/context/logged_in?__ac_name=uzz__ac_passwor d=xxxsubmit=Log+in where the ac_name and ac_password parameters are encrypted using zope public key (?) and have the parameters decrypted when zope receives the request and login the user. Is there an API or some way to encrypt the username and password on the 3rd party app server and configure zope so that it treats the parameters as encrypted values rather than plaintext? Joseph Thomas College of American Pathologists http://www.cap.org http://www.cap.org/ Consider our environment; please print this e-mail only if truly necessary. Thank you! ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] sending a encrypted login URL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Use SSL and you're done. - -aj On 04.03.2009 17:29 Uhr, Joseph Thomas (s) wrote: We’d like to construct a zope login URL of the form on another server: http://zope.domain:port/context/logged_in?__ac_name=uzz__ac_password=xxxsubmit=Log+in http://zope.domain:port/context/logged_in?__ac_name=uzz__ac_password=xxxsubmit=Log+in where the ac_name and ac_password parameters are encrypted using zope public key (?) and have the parameters decrypted when zope receives the request and login the user. Is there an API or some way to encrypt the username and password on the 3^rd party app server and configure zope so that it treats the parameters as encrypted values rather than plaintext? Joseph Thomas College of American Pathologists http://www.cap.org http://www.cap.org/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) - -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: i...@zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK - E-Publishing, Python, Zope Plone development, Consulting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmurnAACgkQCJIWIbr9KYylKQCgn3WWP5SzGrrAQbJIQXv7Bfac 3fwAoIiI4iwtVBFVRg7jtZu5Vgy5fw3f =MHol -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] sending a encrypted login URL
Andreas Jung wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Use SSL and you're done. SSL solves SSO? I don't think so. Cheers Tino - -aj On 04.03.2009 17:29 Uhr, Joseph Thomas (s) wrote: We’d like to construct a zope login URL of the form on another server: http://zope.domain:port/context/logged_in?__ac_name=uzz__ac_password=xxxsubmit=Log+in http://zope.domain:port/context/logged_in?__ac_name=uzz__ac_password=xxxsubmit=Log+in where the ac_name and ac_password parameters are encrypted using zope public key (?) and have the parameters decrypted when zope receives the request and login the user. Is there an API or some way to encrypt the username and password on the 3^rd party app server and configure zope so that it treats the parameters as encrypted values rather than plaintext? Joseph Thomas College of American Pathologists http://www.cap.org http://www.cap.org/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) - -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: i...@zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK - E-Publishing, Python, Zope Plone development, Consulting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmurnAACgkQCJIWIbr9KYylKQCgn3WWP5SzGrrAQbJIQXv7Bfac 3fwAoIiI4iwtVBFVRg7jtZu5Vgy5fw3f =MHol -END PGP SIGNATURE- ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) smime.p7s Description: S/MIME Cryptographic Signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] FW: sending a encrypted login URL
-Original Message- From: Joseph Thomas (s) Sent: Wednesday, March 04, 2009 10:50 AM To: 'li...@zopyx.com' Subject: RE: [Zope] sending a encrypted login URL I think I get what you're suggesting, but let me clarify. I actually wanted the sensitive portions of URL to be encrypted..because it will be link on a page that says login to zope..but I wouldn't want the user or a snooper to be able to view the page source and figure out the URL pattern and the username/password. SSL will ensure that the transport between the browser and the zope server will be encrypted using PKI, but I really want to obfuscate the user name and password parameters in the login URL. So that that if some1 where to view the source they'd see garbled username/password parameters. I suppose I could use the PKI to encrypt the username/password with my zope server's public key (but is there a API to do this on a J2EE container) and then have my zope server decrypt using its private key (but how would zope know that the username/password parameters are 2 be treated as encrypted data)? -Original Message- From: Andreas Jung [mailto:li...@zopyx.com] Sent: Wednesday, March 04, 2009 10:38 AM To: Joseph Thomas (s) Cc: zope@zope.org Subject: Re: [Zope] sending a encrypted login URL -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Use SSL and you're done. - -aj On 04.03.2009 17:29 Uhr, Joseph Thomas (s) wrote: We'd like to construct a zope login URL of the form on another server: http://zope.domain:port/context/logged_in?__ac_name=uzz__ac_password=xxxsubmit=Log+in http://zope.domain:port/context/logged_in?__ac_name=uzz__ac_password=xxxsubmit=Log+in where the ac_name and ac_password parameters are encrypted using zope public key (?) and have the parameters decrypted when zope receives the request and login the user. Is there an API or some way to encrypt the username and password on the 3^rd party app server and configure zope so that it treats the parameters as encrypted values rather than plaintext? Joseph Thomas College of American Pathologists http://www.cap.org http://www.cap.org/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) - -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: i...@zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK - E-Publishing, Python, Zope Plone development, Consulting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmurnAACgkQCJIWIbr9KYylKQCgn3WWP5SzGrrAQbJIQXv7Bfac 3fwAoIiI4iwtVBFVRg7jtZu5Vgy5fw3f =MHol -END PGP SIGNATURE- Consider our environment; please print this e-mail only if truly necessary. Thank you! ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] FW: sending a encrypted login URL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joseph Thomas (s) wrote: I think I get what you're suggesting, but let me clarify. I actually wanted the sensitive portions of URL to be encrypted..because it will be link on a page that says login to zope..but I wouldn't want the user or a snooper to be able to view the page source and figure out the URL pattern and the username/password. SSL will ensure that the transport between the browser and the zope server will be encrypted using PKI, but I really want to obfuscate the user name and password parameters in the login URL. So that that if some1 where to view the source they'd see garbled username/password parameters. I suppose I could use the PKI to encrypt the username/password with my zope server's public key (but is there a API to do this on a J2EE container) and then have my zope server decrypt using its private key (but how would zope know that the username/password parameters are 2 be treated as encrypted data)? On the Zope side, write a PAS plugin which knows how to extract the URL-based credentials, decrypting them as appropriate. You could prototype this as a ScriptablePlugin containing an ExternalMethod named 'extractCredentials' (might even be good enough for production, depending). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrrpQ+gerLs4ltQ4RAiujAKCNVtsj1Xalx5nYOd7CmQZiwgQNQQCgpxSz pVs7DRkz8wZuSBpM4/DiYM0= =6g7H -END PGP SIGNATURE- ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
