Re: [Zope] re ad-only-database
Hi Dieter It describes a configuration option for your storage subsections of the zodb_db sections in your Zope configuration file. Yes, that's what I understood -- thank you! What I meant was that few people seem to use this functionality, as the outdated howtos stand uncorrected, and the new option seems largely unknown. I'll post comments on the howtos when I find time .. -- jean . .. //\\\oo///\\ ___ 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] Zope and SSL
Hello, I'm trying to find out how to generate a CSR, and I can't find the information I need. All my research covers Zope and Apache or Zope and Linux, etc., but our server is running ONLY Zope. Version 2.6.2, to be exact. Unfortunately, I know next to nothing about setting up a secure server anyway. Any help you can offer would be much appreciated! Thanks, Cat - Catherine E. Reinehr Webmaster Director of Publications Huntingdon College 1500 E. Fairview Ave. Montgomery, AL 36106 (334) 833-4429 / Flowers 218B ___ 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] Zope and SSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Catherine, well.. I don't have much experience running SSL on Zope itself, but we use Apache in front and that works well. You'll just have to figure out some RewriteRule directives for Apache and configure it. Most SSL providers (that I've seen anyway) do have clear instructions on how to go about SSL when Apache is involved. - -Morten Catherine E. Reinehr wrote: Hello, I'm trying to find out how to generate a CSR, and I can't find the information I need. All my research covers Zope and Apache or Zope and Linux, etc., but our server is running ONLY Zope. Version 2.6.2, to be exact. Unfortunately, I know next to nothing about setting up a secure server anyway. Any help you can offer would be much appreciated! Thanks, Cat - Catherine E. Reinehr Webmaster Director of Publications Huntingdon College 1500 E. Fairview Ave. Montgomery, AL 36106 (334) 833-4429 / Flowers 218B ___ 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 ) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm+iocACgkQmq0JiiIWC2rBcwCeINv9NFBAnslnP/LQF/PpRpvm qVgAnRUjz/kEpkLT9SDctRAlFqqRXcGF =cQ9o -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 )
Re: [Zope] Zope and SSL
Cat, I'm trying to find out how to generate a CSR, and I can't find the information I need. If you are trying to generate a CSR, you probably need to use OpenSSL, not Zope. If your *Zope application* needs to generate a CSR for some reason, you need to interface OpenSSL from Zope somehow - either using command line interface (works great if you do it carefully) or using M2Crypto or another wrapper (more hassle than benefit, if you are not doing something really complex). Well, there is PyCrypto that I haven't looked into, maybe the bright future is here already :-). All my research covers Zope and Apache or Zope and Linux, etc., but our server is running ONLY Zope. Version 2.6.2, to be exact. Unfortunately, I know next to nothing about setting up a secure server anyway. Any help you can offer would be much appreciated! With this ancient version of Zope you actually may have some luck setting up a secure server without Apache or another reverse, using hacks provided in the earlier versions of M2Crypto. Be careful: it leaks memory when not in a good mood. But really, consider putting Apache in the front. M ___ 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-dev] [Zope 2.12] distribution broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.03.2009 1:17 Uhr, Martin Aspeli wrote: Andreas Jung wrote: As mentioned earlier: use buildout. easy_install support has no high priority right now. Whilst I understand that we don't have the capacity to test all different configurations now, I think it's a good principle to try to avoid a 'hard' dependency on zc.buildout. If we can, we should rely on e.g. setuptools console scripts rather than things generated through specific recipes. Of course, this is just part of an evolution. 'mkzopeinstance' was a completely custom build solution. Using a standard zc.buildout configuration is better, imho, than maintaining a custom build script. But using just setuptools/eggs and letting buildout be a preference rather than a hard dependency is better still. hmm.? The easy_install approach was working at the time when we released a1 some weeks ago. So there must be a small problem causing the issue. In fact easy_install Zope2 acts like configure; make and will create bin/mkzopeinstance and all the other stuff within out Python environment. We will also check about having the traditional source-dist containing everything..but we are at alpha 1 right now. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkm96vcACgkQCJIWIbr9KYz3UgCgrQA7mxsZnYtR6qUPA7HL5iZt YJoAoKocjNwGtg2zzop4gSraxToBdUe9 =meB0 -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] [Zope 2.12] distribution broken
Andreas Jung wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.03.2009 1:17 Uhr, Martin Aspeli wrote: Andreas Jung wrote: As mentioned earlier: use buildout. easy_install support has no high priority right now. Whilst I understand that we don't have the capacity to test all different configurations now, I think it's a good principle to try to avoid a 'hard' dependency on zc.buildout. If we can, we should rely on e.g. setuptools console scripts rather than things generated through specific recipes. Of course, this is just part of an evolution. 'mkzopeinstance' was a completely custom build solution. Using a standard zc.buildout configuration is better, imho, than maintaining a custom build script. But using just setuptools/eggs and letting buildout be a preference rather than a hard dependency is better still. hmm.? The easy_install approach was working at the time when we released a1 some weeks ago. So there must be a small problem causing the issue. In fact easy_install Zope2 acts like configure; make and will create bin/mkzopeinstance and all the other stuff within out Python environment. We will also check about having the traditional source-dist containing everything..but we are at alpha 1 right now. That's excellent - I didn't know that we were so far along. :) 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] [Zope3-checkins] [Checkins] SVN: zope.app.component/trunk/setup.py set missing minimum version
Previously Stephan Richter wrote: On Sunday 15 March 2009, Wichert Akkerman wrote: If the package does not work with an older version of zope.publisher than imho that version restriction *has* to be in setup.py. And what if I backport the fix? We have done version specification like this in the Zope packages before and it almost brought development to complete halt, because versions would not match anymore. Than you adjust the dependency accordingly. I do not believe we should force the KGS on all users of zope packages, which is what you are effectively doing by never putting in version restrictions. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: z3c.layer.pagelet/trunk/ Removed dependency on``zope.app.security`` by using the new packages``zope.authentication`` and ``zope.principalregistry``.
Am 15.03.2009 um 23:47 schrieb Roger Ineichen: Hi Michael Can you explain why you implemented the login viewlets? The login in zope.app.security is implemented using browser pages and metal-macros and is not really customizable. I needed a login/logout which works fine with pagelets and behaves like the one in zope.app.security as I think zope.app.security was not implemented so badly. What does this viewlets have to do with the pagelet layer? It's a pagelet implementation of login/logout, so I thought it matches the goal of this package very well. I think they are very project specific and should go to an explicit package which offers login viewlets. I'm not sure about this, as the implementation as adopted from the one in zope.app.security. I don't think the one in zope.app.security is project specific. But I might be wrong. The pagelet layer has nothing to do with such explicit implementations. The z3c.layer.pagelet package offers only the minimum setup for make pagelets traversable and offers error handling etc. My implementation does not even require new dependencies. ``zope.authentication`` and ``zope.principalregistry`` where split out from zope.app.security to reduce dependencies. What do you think, can we move your viewlet part into another package which is based on z3c.layer.pagelet or probably on z3c.layer.ready2go which uses the pagelet layer too? It could be an idea to add it to z3c.layer.ready2go which currently only contains some interfaces. But a completely new package seems a bit overkill to me. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] [Zope3-checkins] [Checkins] SVN: zope.app.component/trunk/setup.py set missing minimum version
Am 16.03.2009 um 03:33 schrieb Stephan Richter: On Sunday 15 March 2009, Wichert Akkerman wrote: If the package does not work with an older version of zope.publisher than imho that version restriction *has* to be in setup.py. And what if I backport the fix? In this case it was not a little fix which can be back-ported, it was a larger refactoring where a couple of packages where involved. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] zc.relationship - can't pickle module objects
Hi,
I *think* this is a bug in zc.relationship, but I'm not quite sure.
I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install
plone.app.relations, which depends on zc.relationship 1.0.2. In
particular, it subclasses zc.relationship.shared.Container, and stores
a zc.relationship.index.Index object in self.relationIndex.
Now, the __init__ of zc.relationship.index.Index, which derives from
Persistent, contains the code below. In self._relTools and and
self._attrs, there are a pile of modules, types and functions being
stored. I think these are causing the ZODB to barf. Interestingly, with
whatever version of ZODB that comes with Zope 2.10 (3.7?), there's no
problem.
Any ideas how to work around this, or even why it's a problem in one
version of the ZODB but not another?
zc.relationship.index.Index's initialiser:
def __init__(self, attrs, defaultTransitiveQueriesFactory=None,
dumpRel=generateToken, loadRel=resolveToken,
relFamily=IFBTree, deactivateSets=False):
self._name_TO_mapping = OOBTree.OOBTree()
# held mappings are objtoken to (relcount, relset)
self._EMPTY_name_TO_relcount_relset = OOBTree.OOBTree()
self._reltoken_name_TO_objtokenset = OOBTree.OOBTree()
self.defaultTransitiveQueriesFactory =
defaultTransitiveQueriesFactory
self._relTools = getModuleTools(relFamily)
self._relTools['load'] = loadRel
self._relTools['dump'] = dumpRel
self._relLength = Length.Length()
self._relTokens = self._relTools['TreeSet']()
self.deactivateSets = deactivateSets
self._attrs = _attrs = {} # this is private, and it's not
expected to
# mutate after this initial setting.
seen = set()
for data in attrs:
# see README.txt for description of attrs.
if zope.interface.interfaces.IElement.providedBy(data):
data = {'element': data}
res = getModuleTools(data.get('btree', IFBTree))
res['element'] = val = data['element']
res['attrname'] = val.__name__
res['name'] = data.get('name', res['attrname'])
if res['name'] in _attrs or val in seen:
raise ValueError('Duplicate in attrs', name, val)
seen.add(val)
_attrs[res['name']] = res
res['dump'] = data.get('dump', generateToken)
res['load'] = data.get('load', resolveToken)
if (res['dump'] is None) ^ (res['load'] is None):
raise ValueError(
either both of 'dump' and 'load' must be None, or
neither)
# when both load and dump are None, this is a small
# optimization that can be a large optimization if the
returned
# value is one of the main four options of the selected
btree
# family (BTree, TreeSet, Set, Bucket).
res['interface'] = val.interface
res['multiple'] = data.get('multiple', False)
res['call'] = zope.interface.interfaces.IMethod.providedBy(val)
if res['TreeSet'].__name__.startswith('I'):
Mapping = IOBTree.IOBTree
else:
assert res['TreeSet'].__name__.startswith('O')
Mapping = OOBTree.OOBTree
self._name_TO_mapping[res['name']] = Mapping()
# these are objtoken to (relcount, relset)
Regards,
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] [Zope3-checkins] [Checkins] SVN:zope.app.component/trunk/setup.py set missing minimum version
Am 16.03.2009 um 03:53 schrieb Roger Ineichen: Hi Stephan, Wichert, Michael Betreff: Re: [Zope3-checkins] [Checkins] SVN:zope.app.component/trunk/setup.py set missing minimum version On Sunday 15 March 2009, Wichert Akkerman wrote: If the package does not work with an older version of zope.publisher than imho that version restriction *has* to be in setup.py. And what if I back-port the fix? We have done version specification like this in the Zope packages before and it almost brought development to complete halt, because versions would not match anymore. +1 If one of several packages doesn't get updated with buildout is only possible if someone uses an index server which only have one of the both released packages available. It is also possible if someone uses fixed versions in buildout (like me) and starts to upgrade versions of individual packages step by step to see if the current versions work together with the project code (as I did). It would be really helpful to know if an updated version requires new versions of other packages before seeing that the tests break. The version requirement produces is a much more explicit error message than an ImportError (which was the reason I added the minimum version). [...] Michael, can you explain what's happen that you didn't got the zope.publisher release? And was this problem solved after fixing the version or did you do something else too? I described above what I did. Fixing the version did not help me directly as this would require a new release of zope.app.component first, but it might help somebody else after a release was done. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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: 5 OK, 1 Unknown
Summary of messages to the zope-tests list. Period Sun Mar 15 12:00:00 2009 UTC to Mon Mar 16 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Unknown --- Subject: UNKNOWN : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Sun Mar 15 21:32:24 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011281.html Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sun Mar 15 21:24:22 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011277.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sun Mar 15 21:26:23 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011278.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Sun Mar 15 21:28:24 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011279.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Sun Mar 15 21:30:24 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011280.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Sun Mar 15 21:34:25 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011282.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] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote: Hi, I *think* this is a bug in zc.relationship, but I'm not quite sure. I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install plone.app.relations, which depends on zc.relationship 1.0.2. In particular, it subclasses zc.relationship.shared.Container, and stores a zc.relationship.index.Index object in self.relationIndex. Now, the __init__ of zc.relationship.index.Index, which derives from Persistent, contains the code below. In self._relTools and and self._attrs, there are a pile of modules, types and functions being stored. I think these are causing the ZODB to barf. Interestingly, with whatever version of ZODB that comes with Zope 2.10 (3.7?), there's no problem. Any ideas how to work around this, or even why it's a problem in one version of the ZODB but not another? No idea yet. What's the barf's traceback? 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] zc.relationship - can't pickle module objects
Gary Poster wrote: On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote: Hi, I *think* this is a bug in zc.relationship, but I'm not quite sure. I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install plone.app.relations, which depends on zc.relationship 1.0.2. In particular, it subclasses zc.relationship.shared.Container, and stores a zc.relationship.index.Index object in self.relationIndex. Now, the __init__ of zc.relationship.index.Index, which derives from Persistent, contains the code below. In self._relTools and and self._attrs, there are a pile of modules, types and functions being stored. I think these are causing the ZODB to barf. Interestingly, with whatever version of ZODB that comes with Zope 2.10 (3.7?), there's no problem. Any ideas how to work around this, or even why it's a problem in one version of the ZODB but not another? No idea yet. What's the barf's traceback? Mmmm... it seems that zc.relationship 1.1 fixes the issue, but has some other problems (an undefined variable minValues or similar - I haven't got a build with this version in it right now); 2.0dev seems better, albeit a bit scary at pre-alpha. Also, I think 2.0dev *requires* ZODB 3.8, though, which means we have to choose one or the other. Ideally, I'd like a version of plone.relations that works with both ZODB 2.7 and 2.8. I'm still having some problems with zc.relationship 2.0dev interacting with five.intid (which has some special path handling to aq-wrap objects that are turned from key references), though I'm hoping to work around them. The traceback was: File /Users/optilude/.buildout/zope/Zope-2.10.6-final-py2.4/lib/python/ZServer/PubCore/ZServerPublisher.py, line 25, in __init__ response=b) File /Users/optilude/.buildout/zope/Zope-2.10.6-final-py2.4/lib/python/ZPublisher/Publish.py, line 401, in publish_module environ, debug, request, response) File /Users/optilude/.buildout/zope/Zope-2.10.6-final-py2.4/lib/python/ZPublisher/Publish.py, line 202, in publish_module_standard response = publish(request, module_name, after_list, debug=debug) File /Users/optilude/.buildout/eggs/Products.PDBDebugMode-0.2-py2.4.egg/Products/PDBDebugMode/__init__.py, line 47, in pdb_publish mapply=mapply, ) File /Users/optilude/.buildout/zope/Zope-2.10.6-final-py2.4/lib/python/ZPublisher/Publish.py, line 125, in publish transactions_manager.commit() File /Users/optilude/.buildout/zope/Zope-2.10.6-final-py2.4/lib/python/Zope2/App/startup.py, line 238, in commit transaction.commit() File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/transaction/_manager.py, line 93, in commit return self.get().commit() File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/transaction/_transaction.py, line 328, in commit t, v, tb = self._saveAndGetCommitishError() File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/transaction/_transaction.py, line 325, in commit self._commitResources() File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/transaction/_transaction.py, line 424, in _commitResources rm.commit(self) File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/ZODB/Connection.py, line 541, in commit self._commit(transaction) File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/ZODB/Connection.py, line 586, in _commit self._store_objects(ObjectWriter(obj), transaction) File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/ZODB/Connection.py, line 620, in _store_objects p = writer.serialize(obj) # This calls __getstate__ of obj File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/ZODB/serialize.py, line 407, in serialize return self._dump(meta, obj.__getstate__()) File /Users/optilude/.buildout/eggs/ZODB3-3.8.1-py2.4-macosx-10.3-i386.egg/ZODB/serialize.py, line 416, in _dump self._p.dump(state) File /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/copy_reg.py, line 69, in _reduce_ex raise TypeError, can't pickle %s objects % base.__name__ TypeError: can't pickle module objects 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] zc.relationship - can't pickle module objects
Martin Aspeli wrote: Gary Poster wrote: On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote: Hi, I *think* this is a bug in zc.relationship, but I'm not quite sure. I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install plone.app.relations, which depends on zc.relationship 1.0.2. In particular, it subclasses zc.relationship.shared.Container, and stores a zc.relationship.index.Index object in self.relationIndex. Now, the __init__ of zc.relationship.index.Index, which derives from Persistent, contains the code below. In self._relTools and and self._attrs, there are a pile of modules, types and functions being stored. I think these are causing the ZODB to barf. Interestingly, with whatever version of ZODB that comes with Zope 2.10 (3.7?), there's no problem. Any ideas how to work around this, or even why it's a problem in one version of the ZODB but not another? No idea yet. What's the barf's traceback? Mmmm... it seems that zc.relationship 1.1 fixes the issue, but has some other problems (an undefined variable minValues or similar - I haven't got a build with this version in it right now); 2.0dev seems better, albeit a bit scary at pre-alpha. Also, I think 2.0dev *requires* ZODB 3.8, though, which means we have to choose one or the other. Ideally, I'd like a version of plone.relations that works with both ZODB 2.7 and 2.8. I meant ZODB 3.7 and 3.8, of course. :) 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] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 8:39 AM, Martin Aspeli wrote: Gary Poster wrote: On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote: Hi, I *think* this is a bug in zc.relationship, but I'm not quite sure. I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install plone.app.relations, which depends on zc.relationship 1.0.2. In particular, it subclasses zc.relationship.shared.Container, and stores a zc.relationship.index.Index object in self.relationIndex. Now, the __init__ of zc.relationship.index.Index, which derives from Persistent, contains the code below. In self._relTools and and self._attrs, there are a pile of modules, types and functions being stored. I think these are causing the ZODB to barf. Interestingly, with whatever version of ZODB that comes with Zope 2.10 (3.7?), there's no problem. Any ideas how to work around this, or even why it's a problem in one version of the ZODB but not another? No idea yet. What's the barf's traceback? Mmmm... it seems that zc.relationship 1.1 fixes the issue, but has some other problems (an undefined variable minValues or similar - I haven't got a build with this version in it right now); OK. 2.0dev seems better, albeit a bit scary at pre-alpha. zc.relationship 2.0 trunk is now essentially a wrapping of zc.relation code for backwards compatibility. You guys are the main clients for zc.relationship at this point, I suspect. As I see it, your relatively reasonable options are these: - MOST WORK: Move the plone.relation code to depend on zc.relation. There is an upgrade path for the old indexes. You would need to copy over the old zc.relationship relationship containers to the Plone package. IIRC, Alec's tests of those bits were good, and you could just keep the bits from zc.relationship you needed. ZODB module path issues in legacy databases would be among the more annoying bits of this approach, though we all know the usual solutions there. - LESS WORK: See how zc.relationship trunk works for you. If it makes the code happy, I can release it or help you to do so. It's certainly been sitting around long enough. Then at least you are sitting (indirectly) on top of zc.relation, the package that (for instance) Martijn F.'s Grok work exercises. This would be my preferred compromise between effort and migration. The problem here is that it probably does depend on ZODB 3.8, and I'd rather not make the zc.relation code support the older spellings, so that's probably out for you unless you want to make a concrete counter-proposal in this regard. - LEAST WORK: Figure out what's wrong with zc.relationship 1.1. What you described sounds trivial to fix, and I don't have any ethical issues over only supporting the most recent release of the 1.x line, so I don't want to think about the earlier releases. I suspect this is what you want. We can make a 1.1.1 release and you can move on. 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] zc.relationship - can't pickle module objects
Hi Gary, zc.relationship 2.0 trunk is now essentially a wrapping of zc.relation code for backwards compatibility. I see. But 2.0dev on pypi isn't? What's the story behind zc.relation and the evolution of zc.relationship? You guys are the main clients for zc.relationship at this point, I suspect. Possibly, yes. ;-) As I see it, your relatively reasonable options are these: - MOST WORK: Move the plone.relation code to depend on zc.relation. There is an upgrade path for the old indexes. You would need to copy over the old zc.relationship relationship containers to the Plone package. IIRC, Alec's tests of those bits were good, and you could just keep the bits from zc.relationship you needed. ZODB module path issues in legacy databases would be among the more annoying bits of this approach, though we all know the usual solutions there. I think we'd need Alec to find the time to do this if it's to happen, but it does sound like the better option. - LESS WORK: See how zc.relationship trunk works for you. If it makes the code happy, I can release it or help you to do so. It's certainly been sitting around long enough. Then at least you are sitting (indirectly) on top of zc.relation, the package that (for instance) Martijn F.'s Grok work exercises. This would be my preferred compromise between effort and migration. The problem here is that it probably does depend on ZODB 3.8, and I'd rather not make the zc.relation code support the older spellings, so that's probably out for you unless you want to make a concrete counter-proposal in this regard. Well, having a version that only works with ZODB 3.8 isn't *terrible*, it's just annoying. If and when Plone actually ships with five.intid and plone.relations, it'll be on ZODB 3.8 anyway. It's just a bit more work for people wanting to use it. - LEAST WORK: Figure out what's wrong with zc.relationship 1.1. What you described sounds trivial to fix, and I don't have any ethical issues over only supporting the most recent release of the 1.x line, so I don't want to think about the earlier releases. I suspect this is what you want. We can make a 1.1.1 release and you can move on. Hopefully. Do we know that zc.relationship 1.1 works with both ZODB versions? What's the difference between 1.1.1 and 2.0dev on pypi? 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] Dependencies for ZCML
Hey, Tres Seaver wrote: [snip] Doesn't that in some cases make tests harder to understand, as lower-level APIs are in use that are not as recognizable as the equivalent ZCML directives? (say, registering an event) Don't we place a burden on the test writers to learn these APIs while they could use the ones abstracted away behind ZCML instead? No. Relying on real ZCML in testing, as is using the real components is an anti-pattern: it makes tests fragile, couples the packages tightly, etc. Huh? You can't be serious saying there is not extra burden on the test developers if you require them to learn about the implementation of various ZCML directives in order to write a test. The burden is in learning how a view is registered, or how a subscriber is registered, in order to write a test. You need them to break through the abstraction that ZCML provides in order to write a test. It will also make it harder to read the tests as the reader will need to share this understanding as well. You can't just go and say it's an anti-pattern without giving an alternative, otherwise people will continue to use the higher-level of abstraction for registration (i.e. ZCML). [snip] I don't think library packages have ZCML in them at all, except as examples, because trying to reusing ZCML doesn't actually win unambiguosly over copying it. Here's my position on this: You take a hard-line purist opinion. We may want to take an attitude like this for the Zope Framework libraries, eventually. We cannot just do this by throwing out all ZCML from our packages. Why not? Because the Zope community is in the business of providing an integrated experience too (Zope 2, Zope 3 and Grok), like it or not. (hold on, I know you don't care about this. I'm getting to this) This means that we, as a community on zope-dev care about configuration (no matter where it is maintained). Since we do, we should maintain and test it. Since we're a community and care about compatibility it's good to share the burden of maintaining and distributing this configuration, instead of just ignoring this and deferring it to the individual projects. Today, the shared configuration project is scattered over the individual packages in individual zcml files that refer to each other. If we want this project elsewhere, we need to take realistic, active evolutionary steps to get there, package by package. We can't just drop the ball on this, as we have projects depending on this information. I know you don't care one bit about such projects yourself. You just care about the libraries. Fine, but you'll have to acknowledge that other people *do* care about this project. They have frameworks and applications to maintain that need the configuration scattered through the Zope Framework code base right now. I've heard your purist opinions in this area before. It's not very helpful in the way presented. If you want us to buy into your opinions you'll have to make them more attractive to us, and you know about our concerns as a community. 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] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 9:19 AM, Martin Aspeli wrote: Hi Gary, zc.relationship 2.0 trunk is now essentially a wrapping of zc.relation code for backwards compatibility. I see. But 2.0dev on pypi isn't? What's the story behind zc.relation and the evolution of zc.relationship? Briefly, I wanted a package that only included the bit I used, the index (in zc.relation, the catalog). I abstracted it, made sure that zc.relation had 100% test coverage, and changed the names and the API in a backwards incompatible way. I also added a bunch of new features, like a transitive index for hierarchies. See http://pypi.python.org/pypi/zc.relation#changes for details. zc.relationship trunk then depended on zc.relation, and existed to provide backwards compatibility while not forcing me to maintain two versions of the same codebase. The upgrade path that the zc.relation PyPI doc describes from a zc.relationship index to a zc.relation index has been used in production, IIRC, but it requires zc.relationship trunk. I would be quite happy to release zc.relationship trunk as 2.0, if it helped you: it was used in production. If the ZODB 3.8-only issue is not a show-stopper then that's a good approach, and hopefully pretty easy for everyone. You guys are the main clients for zc.relationship at this point, I suspect. Possibly, yes. ;-) As I see it, your relatively reasonable options are these: - MOST WORK: Move the plone.relation code to depend on zc.relation. There is an upgrade path for the old indexes. You would need to copy over the old zc.relationship relationship containers to the Plone package. IIRC, Alec's tests of those bits were good, and you could just keep the bits from zc.relationship you needed. ZODB module path issues in legacy databases would be among the more annoying bits of this approach, though we all know the usual solutions there. I think we'd need Alec to find the time to do this if it's to happen, but it does sound like the better option. Perfect world, sure. - LESS WORK: See how zc.relationship trunk works for you. If it makes the code happy, I can release it or help you to do so. It's certainly been sitting around long enough. Then at least you are sitting (indirectly) on top of zc.relation, the package that (for instance) Martijn F.'s Grok work exercises. This would be my preferred compromise between effort and migration. The problem here is that it probably does depend on ZODB 3.8, and I'd rather not make the zc.relation code support the older spellings, so that's probably out for you unless you want to make a concrete counter-proposal in this regard. Well, having a version that only works with ZODB 3.8 isn't *terrible*, it's just annoying. If and when Plone actually ships with five.intid and plone.relations, it'll be on ZODB 3.8 anyway. It's just a bit more work for people wanting to use it. Gotcha. Your choice. FWIW, this was the path I intended/hoped you guys would follow when I did the work to make zc.relationship sit on top of zc.relation. - LEAST WORK: Figure out what's wrong with zc.relationship 1.1. What you described sounds trivial to fix, and I don't have any ethical issues over only supporting the most recent release of the 1.x line, so I don't want to think about the earlier releases. I suspect this is what you want. We can make a 1.1.1 release and you can move on. Hopefully. Do we know that zc.relationship 1.1 works with both ZODB versions? That would be a significant point of its existence, so I certainly hope so. I'm 80%+ confident that it does, and would regard not supporting 3.7 as a bug that I'd be willing to fix. What's the difference between 1.1.1 and 2.0dev on pypi? I intended that 1.1.1 would simply make the absolutely minimal changes necessary for you to be able to use the 1.1 branch. It would not have any of the 2.x changes at all. 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] Death of local/persistent permissions (zope.app.security refactoring)
Hey, Dan Korostelev wrote: [snip] Thinking now. If we want local persistent permissions to be considered dead and we want to discourage their usage, may be the package should be called zope.app.localpermission then? If so, we could also move its ZMI views there and forget about that package. :) It's just because zope.localpermission name sounds like some nice part of zope framework, but in reality, the functionality provided by the package is deprecated for use withing _the framework_. You're right, we shouldn't be calling it zope.localpermission. Perhaps we shouldn't be calling it zope.app.localpermission either though, as this implies this package can be mined for useful bits. But I don't want a naming discussion, so I think we should go for your suggestion now (zope.app.localpermission which also has the ZMI). But, do we really want it deprecated and dead? May be there's some nice use cases for it? Anyone? At best right now it can serve as example code on how to accomplish this. I can imagine some kind of mythical future ZMI the Next Generation project that would need this. But we cannot afford to care about such mythical future projects as a community, so we should consider it dead. We'll see the fact that nobody but me answered your question as good evidence for this. 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] zope.app.security refactoring results
Hey Dan, Thanks for doing the great work and thanks for this summary. Go Dan!! Could you update our upgrade_notes in the Zope Framework documentation with a sketch of your work here? My work is that eventually we can aggregate information from our changelogs to create a similar document from them, but we're not there yet. On a related note: I noticed that you earlier released some packages as a bugfix release even though they had been undergoing some dependency refactoring. I think we want to err on the side of caution an always do a feature release (x.y instead of x.y.z). I've noted this down now in the steering group decisions. Dan Korostelev wrote: [snip] I created another thread about possibility of death of local permisions, so may be this package will be named zope.app.localpermission and forgotten forever. :) +1, as mentioned in that thread. 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] zope.app.security refactoring results
Stephan Richter wrote: On Friday 13 March 2009, Dan Korostelev wrote: 2009/3/13 Dan Korostelev nad...@gmail.com: The refactoring of zope.app.security is now generally done. In the process, three new packages has been created: [snip] Please, check it out and say your opinion. I'd like new packages to be released ASAP. :-) BTW, now when we have a steering group, I'd like my changes to be approved by them :) You can assume I approve unless I send you a message. :-) Keep sending the summary E-mails as they are a good redux as well. Yeah, I think the rule for larger projects should be: * make sure at least one steering group member is involved in discussing your proposal. (I was, so that's fine) * assume the steering group approves unless informed otherwise. I'll make a note of the make sure at least one steering group member is involved bit in our decision making documentation. 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] Dependencies on zope.app.appsetup
Hey Dan, You bring up another great topic! Dan Korostelev wrote: One of most annoying dependencies is the zope.app.appsetup package. Some packages, like zope.session depend on it just to provide boostrap setup for using these packages in context of zope3, the application server, however, they can be greatly used without it, so this is really awful dependency. I saw that, on last sprint, the subscriber for error reporting utility was moved from zope.error to zope.app.appsetup, so zope.error could lose the dependency on zope.app.appsetup. So, the first question is: do we want to move all subscribers like that? It doesn't seem like a best solution though, because then zope.app.appsetup should depend on all those packages, like zope.session. :-/ We did run this into this issue at the last sprint. We analyzed cycles in package dependencies and decided this was a way to break these dependencies. I think it's less bad that zope.app.appsetup depends on a lot of dependencies than for zope.session to do so, at least if nothing much actually depends on zope.app.appsetup. After all, something setting up Zope 3 the application server will of course have to include a lot of packages... The problem is that the bootstrap code in zope.app.appsetup is really zope3, the application-specific, so it uses root folders, persistent site managers, site management containers, ZopePublication.root_name, and so on. The code itself is okay, because it provides an easy way to setup misc. components for the zope3 application server, but still it's a problem, because it's probably impossible to refactor it in a application-independent way (until we provide some cool pluggable application bootstrapping mechanism, which is probably will become too complex and not needed/used by most application developers). While it might be too complex for most application developers it might not be too complex for framework developers that use the Zope Framework as a base. I think such an infrastructure might arise if the Zope 3 and Grok and Zope 2 developers sit together one day. But not today. :) So, the general question is where should we move the bootstrap setup code? Or, alternatively, we could just leave it in place, but greatly separate it from another package components and provide zope.app.appsetup as an extra dependency (sigh...). I think your question ties into the need for some packages to depend on zope.app.appsetup? Does zope.session really need this stuff? Can't we just get rid of that need? 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] producing a list of packages in the Zope Framework?
Hey Christian, Thanks for picking up on this discussion. Christian Theune wrote: [snip] It might be a goal to get rid of all of zope.app with respect to the Zope Framework definition. Our *goal* is not to have any zope.app package within the framework. zope.app should be useful for Zope 3 as it provides the ZMI and backwards compatibility, but I hope that Grok and Zope 2 can move away from using zope.app.* packages very soon. But today, the major users of the wider Zope Framework (Zope 2, Zope 3 and Grok) all do use these packages, so it's our business to take care of them. Until the zope.app.* packages have all become backwards compatibility stubs, deprecated code and the home for the ZMI we have to continue to take responsibility for it. zope.broken Hmm. There's only a single marker interface in that package. Created by Tres recently, to remove a further dependency from zope.container. We'll have to discuss what to do with packages that don't seem to carry their weight at some point, but let's go with it for now. [snip] zope.datetime Is this actually still needed? It looks like this pre-dates Python's datetime module. There's also pytz around. I don't know, does other code refer to it? zope.deferredimport I feel like we might wanna keep it although we want to avoid deferredimports. It'll have to stay around as we use it for now. But we might at some point decide that zope.deferredimport (with its rather heavy dependency on zope.proxy which has C code) is more trouble than it is worth. Right now the policy is: * If zope.deferredimport is used in a package merely to avoid the use of ``from`` imports, then instead we will use ``from`` imports to get rid of this dependency. [snip] Parts of the Zope 3.5 KGS not required by Zope 2.12 / Plone 4 Most of the following list I agree to exclude, except the ones I marked up. Some I'm not sure about. zope.catalog +1 for keeping I agree we should keep the catalog, intid and indexing infrastucture as something we care about. We should also investigate things like zc.catalog as something within the framework. zope.decorator zope.documenttemplate zope.file zope.html zope.index +1 for keeping I think zope.documenttemplate should eventually be able to live as a template language implementation that can plug into the framework as opposed as an integral part of it. How do we proceed? Shall we take Hanno's list as a starting point, put it in our documentation for now, and then weed out bits on a case by case basis? (continuing this discussion) 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] Standard request/response API
Christian Theune wrote: On Tue, 2009-03-03 at 01:33 +0100, Martijn Faassen wrote: [a possible role for WebOb in the Zope Framework] @Martijn: This thread somewhat overlapped with the forming of the steering group. Do you think this should go to the list of open issues? Yes. I've just documented this, thanks for reminding 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] zc.relationship - can't pickle module objects
Hi Gary, Thanks for being so helpful! What's the difference between 1.1.1 and 2.0dev on pypi? I intended that 1.1.1 would simply make the absolutely minimal changes necessary for you to be able to use the 1.1 branch. It would not have any of the 2.x changes at all. But we're saying that 2.0dev is a very different beast to the trunk that could eventually become 2.0, right? 2.0dev doesn't have a zc.relation dependency, for example. I'm not sure what else there may be in 2.0dev that's useful, of course. I think we need to hear from Alec on what makes most sense for plone.relations. I care pretty much only about the plone.relations API, so I'm sure either of your three options could work. However, I have no idea how hard it'd be in practice to move closer to zc.relation. 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 )
[Zope-dev] setting missing minimum version in setup.py
Stephan Richter wrote: On Sunday 15 March 2009, Wichert Akkerman wrote: If the package does not work with an older version of zope.publisher than imho that version restriction *has* to be in setup.py. And what if I backport the fix? We have done version specification like this in the Zope packages before and it almost brought development to complete halt, because versions would not match anymore. I'm not sure I agree you here, Stephan. A possible disagreement within the steering group, how interesting! :) I agree we should never hardcode version requirements in setup.py that limit the usable version to only one or a few selected ones. The version requirements in setup.py should always be open. The most widely open requirement is this: zope.foo but another open requirement is this: zope.foo = 1.3 I also don't recall open requirements bringing development to a halt? I think more specific open requirements (as opposed to the most widely open requirement) can be very useful. Useful to the maintainers of the Zope Framework KGS, the Zope 3 KGS, the Grok KGS, the Zope 2 KGS, and to application specific lists of packages, and users who are developing or testing packages in some other way. I've used this pattern quite successfully when developing a bunch of related packages. You bring up the case of backporting a fix (a relatively rare occurrence, but it certainly happens): So, zope.bar 3.2 says it needs zope.foo = 1.3. Now you take something from zope.foo 1.3 and also put it in zope.foo 1.2.3 and onwards. zope.bar could now work with zope.foo 1.2 too, and it doesn't declare that it does. You could release a new minor version of zope.bar 3.2.1 that has a wider specification (if I get the spelling right): zope.foo = 1.3, = 1.2.3 (I'm not sure whether setuptools will consider this an adjacent redundant condition and resolve this to zope.foo = 1.2.3..) Updating that in all packages that depend on zope.foo for just that feature is indeed a bit of a burden. It does make it more likely that when someone does an update they'll get a set of package that work together. 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 )
Re: [Zope-dev] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 10:21 AM, Martin Aspeli wrote: Hi Gary, Thanks for being so helpful! Happy to. What's the difference between 1.1.1 and 2.0dev on pypi? I intended that 1.1.1 would simply make the absolutely minimal changes necessary for you to be able to use the 1.1 branch. It would not have any of the 2.x changes at all. But we're saying that 2.0dev is a very different beast to the trunk that could eventually become 2.0, right? 2.0dev doesn't have a zc.relation dependency, for example. Yes. They are related, of course, but practically significantly different. I'm not sure what else there may be in 2.0dev that's useful, of course. Honestly, I'm not sure about the alpha any more either, though IIRC I did do a reasonable job on the change logs, so we could figure it out. I think we need to hear from Alec on what makes most sense for plone.relations. I care pretty much only about the plone.relations API, so I'm sure either of your three options could work. However, I have no idea how hard it'd be in practice to move closer to zc.relation. Sure. My hope is that switching to zc.relationship trunk (2.0) would be a drop-in change. Otherwise, 1.1(.1) definitely should be (with whatever necessary bug fixes). Let me know how I can help, once you all decide what direction you want to go. 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] zope.app.security refactoring results
On Monday 16 March 2009, Martijn Faassen wrote: On a related note: I noticed that you earlier released some packages as a bugfix release even though they had been undergoing some dependency refactoring. I think we want to err on the side of caution an always do a feature release (x.y instead of x.y.z). I've noted this down now in the steering group decisions. +1 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] setting missing minimum version in setup.py
On Mon, Mar 16, 2009 at 10:24 AM, Martijn Faassen faas...@startifact.com wrote: Stephan Richter wrote: On Sunday 15 March 2009, Wichert Akkerman wrote: If the package does not work with an older version of zope.publisher than imho that version restriction *has* to be in setup.py. And what if I backport the fix? We have done version specification like this in the Zope packages before and it almost brought development to complete halt, because versions would not match anymore. I'm not sure I agree you here, Stephan. A possible disagreement within the steering group, how interesting! :) I think more specific open requirements (as opposed to the most widely open requirement) can be very useful. Useful to the maintainers of the Zope Framework KGS, the Zope 3 KGS, the Grok KGS, the Zope 2 KGS, and to application specific lists of packages, and users who are developing or testing packages in some other way. I've used this pattern quite successfully when developing a bunch of related packages. I don't like version requirements in setup.py because they assume too much about how people are using the package. Lets say that someone adds two bug fixes to zope.foo (call them fix A and fix B) and then does a release. Fix A requires zope.bar = 1.5 and fix B doesn't. If I want to benefit from fix B in my app (and don't use the feature fix A repaired), then I shouldn't be forced to upgrade zope.bar. Another way to look at it: Just because a package's test suite won't pass without a particular version of a dependency doesn't mean that every user of the package needs that version of the dependency. If there were a way to ignore setup.py version requirements I'd be happy to have them and ignore them. Alternatively (my preference) the package would set versions in its buildout using the KGS against which it works (plus any exceptions). People could then refer to that to know what versions it actually works with and they can verify that it works by running the tests. -- Benji York Senior Software Engineer Zope Corporation ___ 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] setting missing minimum version in setup.py
On Monday 16 March 2009, Martijn Faassen wrote: I'm not sure I agree you here, Stephan. A possible disagreement within the steering group, how interesting! :) :-) The most widely open requirement is this: zope.foo but another open requirement is this: zope.foo = 1.3 Sure, but here is what happened before. Person A made a bugfix to zope.foo 1.3, releasing zope.foo 1.3.1. He then said, ok, zope.bar 1.0.0 depends on zope.foo = 1.3.1. Person B backports the bug fix to zope.foo 1.2.1. Now zope.bar would also work with 1.2.1, but can't because of the version specification. So person B has the choice of upgrading to zope.foo 1.3.x or release a new version of zope.bar. Updgrading to zope.foo 1.3.x might not be easy for various reasons that I think most of us experienced (I know I did). Releasing a new zope.bar version might not be possible, if person B does not have access. Also expecting person B to create new releases for all packages where the bug fix would work is unrealistic. I also don't recall open requirements bringing development to a halt? They did. :-) You bring up the case of backporting a fix (a relatively rare occurrence, but it certainly happens): Not so rare at all, I think. Updating that in all packages that depend on zope.foo for just that feature is indeed a bit of a burden. It does make it more likely that when someone does an update they'll get a set of package that work together. I think we have seen this is a no-go. There is a compromise I am willing to take. If package zope.bar depends on a *new feature* or *feature change* in zope.foo 1.3.x, then it should specify the version. In other words specifying open restrictions on the major version levels is okay, but never on the bug fix level. (I just hope this does not bite us later. ;-) 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] Dependencies on zope.app.appsetup
On Monday 16 March 2009, Martijn Faassen wrote: I saw that, on last sprint, the subscriber for error reporting utility was moved from zope.error to zope.app.appsetup, so zope.error could lose the dependency on zope.app.appsetup. So, the first question is: do we want to move all subscribers like that? It doesn't seem like a best solution though, because then zope.app.appsetup should depend on all those packages, like zope.session. :-/ We did run this into this issue at the last sprint. We analyzed cycles in package dependencies and decided this was a way to break these dependencies. I think it's less bad that zope.app.appsetup depends on a lot of dependencies than for zope.session to do so, at least if nothing much actually depends on zope.app.appsetup. After all, something setting up Zope 3 the application server will of course have to include a lot of packages... BTW, +1. zope.app.appsetup being a little bit of an all toppings pizza is okay. It's job is to wire things up. In zome respect it represents a basic Zope 3 app setup. 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] setting missing minimum version in setup.py
Hi Betreff: Re: [Zope-dev] setting missing minimum version in setup.py On Monday 16 March 2009, Martijn Faassen wrote: I'm not sure I agree you here, Stephan. A possible disagreement within the steering group, how interesting! :) :-) The most widely open requirement is this: zope.foo but another open requirement is this: zope.foo = 1.3 Sure, but here is what happened before. Person A made a bugfix to zope.foo 1.3, releasing zope.foo 1.3.1. He then said, ok, zope.bar 1.0.0 depends on zope.foo = 1.3.1. Person B backports the bug fix to zope.foo 1.2.1. Now zope.bar would also work with 1.2.1, but can't because of the version specification. So person B has the choice of upgrading to zope.foo 1.3.x or release a new version of zope.bar. Updgrading to zope.foo 1.3.x might not be easy for various reasons that I think most of us experienced (I know I did). Releasing a new zope.bar version might not be possible, if person B does not have access. Also expecting person B to create new releases for all packages where the bug fix would work is unrealistic. I also don't recall open requirements bringing development to a halt? They did. :-) You bring up the case of backporting a fix (a relatively rare occurrence, but it certainly happens): Not so rare at all, I think. Even if it's rare, why should we not support that? The consequence of fixing versions is to skip backporting. There is no way to have both. Are you really sure we like to skip backporting. Regards Roger Ineichen ___ 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: z3c.layer.pagelet/trunk/ Removed dependency on``zope.app.security`` by using the new packages``zope.authentication`` and ``zope.principalregistry``.
Hi Michael Betreff: Re: AW: [Checkins] SVN: z3c.layer.pagelet/trunk/ Removed dependency on``zope.app.security`` by using the new packages``zope.authentication`` and ``zope.principalregistry``. Am 15.03.2009 um 23:47 schrieb Roger Ineichen: Hi Michael Can you explain why you implemented the login viewlets? The login in zope.app.security is implemented using browser pages and metal-macros and is not really customizable. I needed a login/logout which works fine with pagelets and behaves like the one in zope.app.security as I think zope.app.security was not implemented so badly. What does this viewlets have to do with the pagelet layer? It's a pagelet implementation of login/logout, so I thought it matches the goal of this package very well. Yes and No. It's of corse usefull to have predefined login views available. But I use a z3c.form based implementation for this. Which means I don't need them. Everything else in z3c.layer.pagelet is needed by everyone. Otherwise the pagelet pattern doesn't work. This let me think that everything which is not needed by default in z3c.layer.pagelet should go to another package because it's only optional. Then z3c.layer.pagelet is only a base implmentation for make pagelet working and is used in other packages as mixin. I think they are very project specific and should go to an explicit package which offers login viewlets. I'm not sure about this, as the implementation as adopted from the one in zope.app.security. I don't think the one in zope.app.security is project specific. But I might be wrong. I think that's right. The pagelet layer has nothing to do with such explicit implementations. The z3c.layer.pagelet package offers only the minimum setup for make pagelets traversable and offers error handling etc. My implementation does not even require new dependencies. ``zope.authentication`` and ``zope.principalregistry`` where split out from zope.app.security to reduce dependencies. What do you think, can we move your viewlet part into another package which is based on z3c.layer.pagelet or probably on z3c.layer.ready2go which uses the pagelet layer too? It could be an idea to add it to z3c.layer.ready2go which currently only contains some interfaces. But a completely new package seems a bit overkill to me. Ok, sounds good to me. I'll take a closer look at that and let you know if I change something. Regards Roger Ineichen Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] setting missing minimum version in setup.py
Hey, Stephan Richter wrote: [snip] There is a compromise I am willing to take. If package zope.bar depends on a *new feature* or *feature change* in zope.foo 1.3.x, then it should specify the version. In other words specifying open restrictions on the major version levels is okay, but never on the bug fix level. (I just hope this does not bite us later. ;-) Yes, I was thinking in this direction too. I can see this as more of an issue with bug fixes than with feature changes. This means that requirements can only say zope.foo = x.y, and never zope.foo = x.y.z. What do people think? 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] setting missing minimum version in setup.py
Hey, Roger Ineichen wrote: [snip] Even if it's rare, why should we not support that? The consequence of fixing versions is to skip backporting. There is no way to have both. Are you really sure we like to skip backporting. I haven't a clear idea about how often we backport and even less an idea on how often we'd *want* to backport. :) If, as Stephan was suggesting as a possible compromise, we try this for feature changes only, we'd only run into this issue if we start backporting features. 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] setting missing minimum version in setup.py
2009/3/16 Martijn Faassen faas...@startifact.com: There is a compromise I am willing to take. If package zope.bar depends on a *new feature* or *feature change* in zope.foo 1.3.x, then it should specify the version. In other words specifying open restrictions on the major version levels is okay, but never on the bug fix level. (I just hope this does not bite us later. ;-) Yes, I was thinking in this direction too. I can see this as more of an issue with bug fixes than with feature changes. This means that requirements can only say zope.foo = x.y, and never zope.foo = x.y.z. What do people think? That looks sane, so I'm +1 :) -- 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] [Checkins] SVN: z3c.layer.pagelet/trunk/ Removed dependency on``zope.app.security`` by using the new packages``zope.authentication`` and ``zope.principalregistry``.
Am 16.03.2009 um 16:43 schrieb Roger Ineichen: [...] It's a pagelet implementation of login/logout, so I thought it matches the goal of this package very well. Yes and No. It's of corse usefull to have predefined login views available. But I use a z3c.form based implementation for this. I thought this as the next step: the template for cookie login is not really nice and makes wrong assumptions (e. g. unauthenticated principal has the id zope.anybody). So I planned to replace it with a z3c.form based login form. But this would add a new dependency and I was not sure if this is a good idea. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] setting missing minimum version in setup.py
On Mar 16, 2009, at 12:05 PM, Dan Korostelev wrote: 2009/3/16 Martijn Faassen faas...@startifact.com: There is a compromise I am willing to take. If package zope.bar depends on a *new feature* or *feature change* in zope.foo 1.3.x, then it should specify the version. In other words specifying open restrictions on the major version levels is okay, but never on the bug fix level. (I just hope this does not bite us later. ;-) Yes, I was thinking in this direction too. I can see this as more of an issue with bug fixes than with feature changes. This means that requirements can only say zope.foo = x.y, and never zope.foo = x.y.z. What do people think? That looks sane, so I'm +1 :) Also +1 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] [Checkins] SVN: z3c.layer.pagelet/trunk/ Removed dependency on``zope.app.security`` by using the new packages``zope.authentication`` and ``zope.principalregistry``.
2009/3/16 Michael Howitz m...@gocept.com: Am 16.03.2009 um 16:43 schrieb Roger Ineichen: [...] It's a pagelet implementation of login/logout, so I thought it matches the goal of this package very well. Yes and No. It's of corse usefull to have predefined login views available. But I use a z3c.form based implementation for this. I thought this as the next step: the template for cookie login is not really nice and makes wrong assumptions (e. g. unauthenticated principal has the id zope.anybody). So I planned to replace it with a z3c.form based login form. But this would add a new dependency and I was not sure if this is a good idea. Look at my latests changes in zope.app.authentication loginForm template, it cleans up the template by separating camefrom/unauthenticated logic into a python class. I think you should do the same for your implementation. -- 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] setting missing minimum version in setup.py
Am 16.03.2009 um 15:49 schrieb Benji York: [...] I don't like version requirements in setup.py because they assume too much about how people are using the package. Lets say that someone adds two bug fixes to zope.foo (call them fix A and fix B) and then does a release. Fix A requires zope.bar = 1.5 and fix B doesn't. If I want to benefit from fix B in my app (and don't use the feature fix A repaired), then I shouldn't be forced to upgrade zope.bar. +1 in principal, but this thread arose from adding a minimum version because the package failed with an ImportError in its main __init__.py Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] setting missing minimum version in setup.py
Am 16.03.2009 um 16:56 schrieb Martijn Faassen: Hey, Stephan Richter wrote: [snip] There is a compromise I am willing to take. If package zope.bar depends on a *new feature* or *feature change* in zope.foo 1.3.x, then it should specify the version. In other words specifying open restrictions on the major version levels is okay, but never on the bug fix level. (I just hope this does not bite us later. ;-) Yes, I was thinking in this direction too. I can see this as more of an issue with bug fixes than with feature changes. This means that requirements can only say zope.foo = x.y, and never zope.foo = x.y.z. What do people think? Sounds reasonable: +1 Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] [Fwd: [Bug 343079] [NEW] Broken distribution (2009-03-15)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: On 16.03.2009 4:52 Uhr, Tres Seaver wrote: Andreas Jung wrote: On 15.03.2009 18:42 Uhr, Tres Seaver wrote: Original Message Subject: [Bug 343079] [NEW] Broken distribution (2009-03-15) Date: Sun, 15 Mar 2009 07:42:00 - From: dmaurer die...@handshake.de Reply-To: Bug 343079 343...@bugs.launchpad.net To: tsea...@palladion.com References: 20090315074200.12457.19313.malone...@potassium.ubuntu.com Public bug reported: The current (2009-03-12) PyPI distribution for Zope2 2.12.0a1 is broken. 'easy_install'ing it leads to version conflicts for 'zope.component' (3.5.1 versus 3.6.0) in the call of 'mkzopeinstance'. ** Affects: zope2 Importance: Undecided Status: New The breakage is due to the release of the new zope.prinipalregistry egg. We should probably manage a Zope2 indes and tell people to use it when running easy_install, because PyPI is not suitable for the task given setuptools' incremental requirements discovery design. Easy_installing the a1 sdist should behave like using buildout since the versions within the sdist are pinned as well. It actually worked at the time of the a1 release. I don't understand right now why we get this failure. I don't see any pinning at all here: http://svn.zope.org/Zope/tags/2.12.0a1/setup.py?rev=97288view=auto Please look at the getPackages() method taking the version*cfg files into account. So all versions should be pinned. However there is obviously a difference between using buildout with pinned versions and setuptools or a small undetected hole in the process. The issue must be that one of the pinned dependencies (zope.publisher?) has an unpinned dependency (maybe transitively?) which requires a newer version of zope.component. This kind of issue was the source of my contentiont that released versions should ship with exact pins of the egg versions (the full transitive closure): it should at least be possible to generate a 'Zope2-exact' distribution which provides a known good installation, even it a 'Zope2-upgradable' distribution might be better for some people. The other option, as I said earlier, is to maintain an index for each release branch of Zope2, and populate it only with eggs which have been tested not to break the upgrade. We could specify that index in the install docs, and maybe even in the 'setup.cfg' of the package. I hope we can discuss and resolve remaining issues during PyCon. Maybe generating indexes from the varios known good metadata we are already maintaining would be the right path. 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 iD8DBQFJvnyA+gerLs4ltQ4RAiZ2AKCZ8KW2700uFQMQgX/UWggBfXo4pQCglqMV O2wVPbaBQzLjFLj/RW7AsuY= =4Lix -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] setting missing minimum version in setup.py
Previously Martijn Faassen wrote: Hey, Stephan Richter wrote: [snip] There is a compromise I am willing to take. If package zope.bar depends on a *new feature* or *feature change* in zope.foo 1.3.x, then it should specify the version. In other words specifying open restrictions on the major version levels is okay, but never on the bug fix level. (I just hope this does not bite us later. ;-) Yes, I was thinking in this direction too. I can see this as more of an issue with bug fixes than with feature changes. This means that requirements can only say zope.foo = x.y, and never zope.foo = x.y.z. What do people think? -1 still If I install a package I want to have a guarantee all aspects of that package work correctly. With this compromise that is not possible. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] [Fwd: [Bug 343079] [NEW] Broken distribution (2009-03-15)]
Tres Seaver wrote: Andreas Jung wrote: Please look at the getPackages() method taking the version*cfg files into account. So all versions should be pinned. However there is obviously a difference between using buildout with pinned versions and setuptools or a small undetected hole in the process. The issue must be that one of the pinned dependencies (zope.publisher?) has an unpinned dependency (maybe transitively?) which requires a newer version of zope.component. What I think is more likely to have happened here is: An additional package (like one under development) was installed first. This depends on some zope.foo package (maybe zope.publisher) which wants zope.component 3.6. setuptools goes and fetches the latest version of all of these. Now later on the Zope2 egg is put into the environment and requires zope.component 3.5.1 - result VersionConflict. Setuptools loads packages and puts them into the environment as it finds them. It doesn't build a full tree of dependencies first. This is what pip adds for example. Unless you have a KGS or any kind of version restrictions for everything from the start, you will always run into these problems. Managing exact versions inside setup.py doesn't work. 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] Dependencies for ZCML
Am 12.03.2009 um 19:25 schrieb Tres Seaver: [...] Now when testing these libraries you could do three things: * not use ZCML at all and recreate the effect of these registrations in Python code. +1. * use the ZCML in the package's configure.zcml. (perhaps through ftesting.zcml) - -lots. I disagree: if there is ZCML inside the package it must be tested inside the package. If there is a syntax errors in the zcml, tests do not find it. It is even possible to make a release without noticing this defect. I think that's really bad. Otherwise we should we require to run the compat-tests before releasing a package of the zope framework. This might find the errors in zcml, maybe. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] Dependencies for ZCML
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hey,
Tres Seaver wrote:
[snip]
Doesn't that in some cases make tests harder to understand, as
lower-level APIs are in use that are not as recognizable as the
equivalent ZCML directives? (say, registering an event) Don't we place a
burden on the test writers to learn these APIs while they could use the
ones abstracted away behind ZCML instead?
No. Relying on real ZCML in testing, as is using the real
components is an anti-pattern: it makes tests fragile, couples the
packages tightly, etc.
Huh? You can't be serious saying there is not extra burden on the test
developers if you require them to learn about the implementation of
various ZCML directives in order to write a test. The burden is in
learning how a view is registered, or how a subscriber is registered, in
order to write a test. You need them to break through the abstraction
that ZCML provides in order to write a test. It will also make it harder
to read the tests as the reader will need to share this understanding as
well.
You can't just go and say it's an anti-pattern without giving an
alternative, otherwise people will continue to use the higher-level of
abstraction for registration (i.e. ZCML).
The alternative is that developers use 'zope.component.provide*' rather
than loading ZCML. The upsides are:
- - They can register stub implementations, some of which may not even be
importable (e.g., local closures).
- - They can avoid testing dependencies on 'zope.configuration' and
friends.
- - The tests run faster.
- - The tests run cleaner.
[snip]
I don't think library packages have ZCML in them at all, except as
examples, because trying to reusing ZCML doesn't actually win
unambiguosly over copying it.
Here's my position on this:
You take a hard-line purist opinion. We may want to take an attitude
like this for the Zope Framework libraries, eventually. We cannot just
do this by throwing out all ZCML from our packages.
Why not? Because the Zope community is in the business of providing an
integrated experience too (Zope 2, Zope 3 and Grok), like it or not.
(hold on, I know you don't care about this. I'm getting to this)
This means that we, as a community on zope-dev care about configuration
(no matter where it is maintained). Since we do, we should maintain and
test it. Since we're a community and care about compatibility it's good
to share the burden of maintaining and distributing this configuration,
instead of just ignoring this and deferring it to the individual projects.
Today, the shared configuration project is scattered over the
individual packages in individual zcml files that refer to each other.
If we want this project elsewhere, we need to take realistic, active
evolutionary steps to get there, package by package. We can't just drop
the ball on this, as we have projects depending on this information.
I know you don't care one bit about such projects yourself. You just
care about the libraries.
Please don't put words in my mouth. I *do* care that the
mega-frameworks succeed. However, I don't think that blessing the
current usage is going to help them succeed in the long run. I think
that moving the shared configuration bits out of library packages
ought to be a fairly high-priority, near-term goal, in order to increase
the quality / reusability of the library packages, which will also
increase the quality / stability of the mega-frameworks, and reduce the
burden of maintaining both.
I think the tight coupling of scattered + required ZCML has turned out
to be a net loss over time, because it forces people to make an
all-or-nothing choice about adopting Zope early on in their
evaluation. Making it attracive and easy to use pieces of Zope, while
deferring that all-in bet, is a big driver for the purism you are
describing.
Fine, but you'll have to acknowledge that other people *do* care about
this project. They have frameworks and applications to maintain that
need the configuration scattered through the Zope Framework code base
right now.
I'll draw a semantic distinction, based on the grammatical ambiguity in
that sentence: those applications need the configuration, but they
don't need the configuration to be scattered through the code base,
except for BBB purposes.
For instance, if we provided for each mega-framework a single
everything {Grok,Zope2,Zope3ZMI} needs from the Zope framework
package, which named all the appropriate dependencies *and* provided the
shared ZCML, and then switched each mega-framework and its
applications to use that package, we could remove the ZCML from all the
other packages (except for BBB). In fact that single package would *be*
the mega-framework at that point.
Once we had such packages, we could look at whether factoring out some
of the common dependencies / ZCML from each of them into one or more
shared Zope Framework ZCML
Re: [Zope-dev] Dependencies for ZCML
Am 11.03.2009 um 21:26 schrieb Dan Korostelev: 2009/3/11 Martijn Faassen faas...@startifact.com: Oh, and on the topic, one more time: can we have a steering group decision on the package requirements for zcml statements? Are we doing extras for them or simply skipping them? Sorry, I wasn't clear that there was an open question and I'm afraid I don't understand this one. :) Could you point me to the appropriate thread that was left in the middle, or could you start a new thread with a description of the open question? I'm too lazy now to search in archives, so I'll just describe again. For example, the zope.password package only requires zope.interface to be functional. But it's configure.zcml contains directives that need zope.component (or repoze.zcml) and zope.security. Also, the zcml thing itself needs zope.configure as well. Should we mention it in extra dependencies somehow or just document it, saying that zcml is intented to be used in more zope3-ish environment that already has needed packages, so others can simply ignore these files. zope.container has a similar problem: its configure.zcml uses zope:view directives. When I'd like to use zope.container in a Zope 3 the application server environment I have to know that zope:view is defined in zope.app..component or I have to find it out. There is no dependency, not test and no documentation mentioning this inside zope.container. I think that's bad as it makes it more difficult to learn Zope for new developers. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] zc.relationship - can't pickle module objects
Gary Poster wrote: Hopefully. Do we know that zc.relationship 1.1 works with both ZODB versions? That would be a significant point of its existence, so I certainly hope so. I'm 80%+ confident that it does, and would regard not supporting 3.7 as a bug that I'd be willing to fix. Right... so I've just fixed the errors Pyflakes found with zc.relationship 1.1 branch. This now works reliably for my ZODB 3.8.1 build. However, it won't install in my ZODB 3.7 environment, because of this line in setup.py: 'ZODB3 = 3.8dev', Was that an intentional minimum? 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] [Fwd: [Bug 343079] [NEW] Broken distribution (2009-03-15)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.03.2009 17:40 Uhr, Hanno Schlichting wrote: Tres Seaver wrote: Andreas Jung wrote: Please look at the getPackages() method taking the version*cfg files into account. So all versions should be pinned. However there is obviously a difference between using buildout with pinned versions and setuptools or a small undetected hole in the process. The issue must be that one of the pinned dependencies (zope.publisher?) has an unpinned dependency (maybe transitively?) which requires a newer version of zope.component. What I think is more likely to have happened here is: An additional package (like one under development) was installed first. This depends on some zope.foo package (maybe zope.publisher) which wants zope.component 3.6. setuptools goes and fetches the latest version of all of these. Now later on the Zope2 egg is put into the environment and requires zope.component 3.5.1 - result VersionConflict. Not sure about this theory - I can reproduce the version mismatch with an almost plain Python 2.5 installation - especially it is reproducable within a virtualenv --no-site-package environment. On the other hand: I can not reproduce this error on my Linux box with a Python 2.4 installation with pretty large site-packages dir :- Setuptools loads packages and puts them into the environment as it finds them. It doesn't build a full tree of dependencies first. This is what pip adds for example. pip produces the same result. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkm+h60ACgkQCJIWIbr9KYypHACcCtI1h5fwXO9RFq1gO28J9rQr Y/4AnifSSIuNRHW6Chim7KRxOvtWZvL3 =fpxY -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] [Fwd: [Bug 343079] [NEW] Broken distribution (2009-03-15)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.03.2009 17:21 Uhr, Tres Seaver wrote: Maybe generating indexes from the varios known good metadata we are already maintaining would be the right path. By index you refer to a KGS or a release-specific directory containing the blessed packages under a well-known URL? Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkm+iAgACgkQCJIWIbr9KYx9xwCeNWqIvhGfMh28R581ATADz/5w 48YAnRQ9Z31JXSYJNkhx7X0e75eQV4v0 =+xc2 -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] zc.relationship - can't pickle module objects
Martin Aspeli wrote: Gary Poster wrote: Hopefully. Do we know that zc.relationship 1.1 works with both ZODB versions? That would be a significant point of its existence, so I certainly hope so. I'm 80%+ confident that it does, and would regard not supporting 3.7 as a bug that I'd be willing to fix. Right... so I've just fixed the errors Pyflakes found with zc.relationship 1.1 branch. This now works reliably for my ZODB 3.8.1 build. However, it won't install in my ZODB 3.7 environment, because of this line in setup.py: 'ZODB3 = 3.8dev', Was that an intentional minimum? Okay... so, if we remove that restriction, and add the following monkey patch to (which is already in plone.relations) to __init__.py, then this works on ZODB 3.7 with Zope 2.10, and the tests pass (save for cosmetic doctest failures on 3.7 which are easy to fix): # A tiny monkey patch due to some re-organization of future BTree modules try: from BTrees.OOBTree import BTree except ImportError: import BTrees.OOBTree import BTrees.IOBTree import BTrees.OIBTree import BTrees.IIBTree import BTrees.IFBTree BTrees.OOBTree.BTree = BTrees.OOBTree.OOBTree BTrees.OOBTree.Set = BTrees.OOBTree.OOSet BTrees.OOBTree.Bucket = BTrees.OOBTree.OOBucket BTrees.OOBTree.TreeSet = BTrees.OOBTree.OOTreeSet BTrees.IOBTree.BTree = BTrees.IOBTree.IOBTree BTrees.IOBTree.Set = BTrees.IOBTree.IOSet BTrees.IOBTree.Bucket = BTrees.IOBTree.IOBucket BTrees.IOBTree.TreeSet = BTrees.IOBTree.IOTreeSet BTrees.OIBTree.BTree = BTrees.OIBTree.OIBTree BTrees.OIBTree.Set = BTrees.OIBTree.OISet BTrees.OIBTree.Bucket = BTrees.OIBTree.OIBucket BTrees.OIBTree.TreeSet = BTrees.OIBTree.OITreeSet BTrees.IIBTree.BTree = BTrees.IIBTree.IIBTree BTrees.IIBTree.Set = BTrees.IIBTree.IISet BTrees.IIBTree.Bucket = BTrees.IIBTree.IIBucket BTrees.IIBTree.TreeSet = BTrees.IIBTree.IITreeSet BTrees.IFBTree.BTree = BTrees.IFBTree.IFBTree BTrees.IFBTree.Set = BTrees.IFBTree.IFSet BTrees.IFBTree.Bucket = BTrees.IFBTree.IFBucket BTrees.IFBTree.TreeSet = BTrees.IFBTree.IFTreeSet Shall I just check that in + the removal of the minimum version pin? If we do that, then we can let plone.relations depend on zc.relationship 1.1.1 explicitly and have support for both ZODB versions, which would be nice. 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] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 1:20 PM, Martin Aspeli wrote: Martin Aspeli wrote: Gary Poster wrote: Hopefully. Do we know that zc.relationship 1.1 works with both ZODB versions? That would be a significant point of its existence, so I certainly hope so. I'm 80%+ confident that it does, and would regard not supporting 3.7 as a bug that I'd be willing to fix. Right... so I've just fixed the errors Pyflakes found with zc.relationship 1.1 branch. This now works reliably for my ZODB 3.8.1 build. However, it won't install in my ZODB 3.7 environment, because of this line in setup.py: 'ZODB3 = 3.8dev', Was that an intentional minimum? Okay... so, if we remove that restriction, and add the following monkey patch to (which is already in plone.relations) to __init__.py, then this works on ZODB 3.7 with Zope 2.10, and the tests pass (save for cosmetic doctest failures on 3.7 which are easy to fix): # A tiny monkey patch due to some re-organization of future BTree modules try: from BTrees.OOBTree import BTree except ImportError: import BTrees.OOBTree import BTrees.IOBTree import BTrees.OIBTree import BTrees.IIBTree import BTrees.IFBTree BTrees.OOBTree.BTree = BTrees.OOBTree.OOBTree BTrees.OOBTree.Set = BTrees.OOBTree.OOSet BTrees.OOBTree.Bucket = BTrees.OOBTree.OOBucket BTrees.OOBTree.TreeSet = BTrees.OOBTree.OOTreeSet BTrees.IOBTree.BTree = BTrees.IOBTree.IOBTree BTrees.IOBTree.Set = BTrees.IOBTree.IOSet BTrees.IOBTree.Bucket = BTrees.IOBTree.IOBucket BTrees.IOBTree.TreeSet = BTrees.IOBTree.IOTreeSet BTrees.OIBTree.BTree = BTrees.OIBTree.OIBTree BTrees.OIBTree.Set = BTrees.OIBTree.OISet BTrees.OIBTree.Bucket = BTrees.OIBTree.OIBucket BTrees.OIBTree.TreeSet = BTrees.OIBTree.OITreeSet BTrees.IIBTree.BTree = BTrees.IIBTree.IIBTree BTrees.IIBTree.Set = BTrees.IIBTree.IISet BTrees.IIBTree.Bucket = BTrees.IIBTree.IIBucket BTrees.IIBTree.TreeSet = BTrees.IIBTree.IITreeSet BTrees.IFBTree.BTree = BTrees.IFBTree.IFBTree BTrees.IFBTree.Set = BTrees.IFBTree.IFSet BTrees.IFBTree.Bucket = BTrees.IFBTree.IFBucket BTrees.IFBTree.TreeSet = BTrees.IFBTree.IFTreeSet Shall I just check that in + the removal of the minimum version pin? Yes, +1. Thank you. I was about to write to your other message that this was quite possibly the only 3.8 dependency. If we do that, then we can let plone.relations depend on zc.relationship 1.1.1 explicitly and have support for both ZODB versions, which would be nice. Sounds great. Would you like access to the PyPI zc.relationship record so you can upload the new version? If so, are you optilude there? 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] setting missing minimum version in setup.py
Wichert Akkerman wrote: Previously Martijn Faassen wrote: Hey, Stephan Richter wrote: [snip] There is a compromise I am willing to take. If package zope.bar depends on a *new feature* or *feature change* in zope.foo 1.3.x, then it should specify the version. In other words specifying open restrictions on the major version levels is okay, but never on the bug fix level. (I just hope this does not bite us later. ;-) Yes, I was thinking in this direction too. I can see this as more of an issue with bug fixes than with feature changes. This means that requirements can only say zope.foo = x.y, and never zope.foo = x.y.z. What do people think? -1 still If I install a package I want to have a guarantee all aspects of that package work correctly. With this compromise that is not possible. Wichert. I am not quite sure what you mean... Are you saying that the proposal does not go far enough, and we should allow the full =x.y.z? Or are you against any and all versions in setup.py? I think the best policy is to use versions specs for base packages (minimum, as well as maximum), but only when it is *known* that not meeting the requirements means the derived package is useless. This is most likely to happen when the API of the base package is changed (which is only allowed in a major version), but could in rare cases happen for other reasons. To me the important thing is not the major/minor version distinction, but rather the degree of uselessness. Of course there may be broad guidelines such as only use major versions, but the way I see it this really calls for a decision on a case-by-case basis. Jacob ___ 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] [Fwd: [Bug 343079] [NEW] Broken distribution (2009-03-15)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: On 16.03.2009 17:21 Uhr, Tres Seaver wrote: Maybe generating indexes from the varios known good metadata we are already maintaining would be the right path. By index you refer to a KGS or a release-specific directory containing the blessed packages under a well-known URL? I mean an index which supplies the 'simple' PyPI interface, such that we could tell people to 'easy_install' from it, e.g.: $ /path/to/bin/easy_install -i http://kgs.zope.org/Zope2/2.1.2 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 iD8DBQFJvo8M+gerLs4ltQ4RAisvAJ9vhbRfcyci7TQ6oqKKVhOdNt5wjwCdG5Y+ Z64Gd55VZmu51eoOnCju0x4= =7hDp -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:view directive
2009/3/16 Michael Howitz m...@gocept.com: zope.container has a similar problem: its configure.zcml uses zope:view directives. When I'd like to use zope.container in a Zope 3 the application server environment I have to know that zope:view is defined in zope.app..component or I have to find it out. There is no dependency, not test and no documentation mentioning this inside zope.container. BTW, what's zope:view was created for? Shouldn't we just move from zope:view to simple zope:adapter and deprecate zope:view to get rid of confusion? -- 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] [Fwd: [Bug 343079] [NEW] Broken distribution (2009-03-15)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: Tres Seaver wrote: Andreas Jung wrote: Please look at the getPackages() method taking the version*cfg files into account. So all versions should be pinned. However there is obviously a difference between using buildout with pinned versions and setuptools or a small undetected hole in the process. The issue must be that one of the pinned dependencies (zope.publisher?) has an unpinned dependency (maybe transitively?) which requires a newer version of zope.component. What I think is more likely to have happened here is: An additional package (like one under development) was installed first. This depends on some zope.foo package (maybe zope.publisher) which wants zope.component 3.6. setuptools goes and fetches the latest version of all of these. Now later on the Zope2 egg is put into the environment and requires zope.component 3.5.1 - result VersionConflict. This error is reproducible in a fresh virtualenv. Setuptools loads packages and puts them into the environment as it finds them. It doesn't build a full tree of dependencies first. This is what pip adds for example. Right: this is what I was calling the incremental dependency discovery bit in setuptlools. Unless you have a KGS or any kind of version restrictions for everything from the start, you will always run into these problems. Managing exact versions inside setup.py doesn't work. A Zope2-specific index supplies the same need. 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 iD8DBQFJvqID+gerLs4ltQ4RApHjAJ9Im+Y3dntzdcBxFj9SIEuBBwrBRACgpnuK D0vVs+7dYWSB+3/My5yeRyg= =wQey -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] Dependencies for ZCML
Hi Tres,
Tres Seaver schrieb:
For instance, if we provided for each mega-framework a single
everything {Grok,Zope2,Zope3ZMI} needs from the Zope framework
package, which named all the appropriate dependencies *and* provided the
shared ZCML, and then switched each mega-framework and its
applications to use that package, we could remove the ZCML from all the
other packages (except for BBB). In fact that single package would *be*
the mega-framework at that point.
zcml contains many useful informations and I often use it as
documentation how things fit together. It would be a loss to detach all
zcml from the implementations into one/few big zcml packages.
Moving them into one dedicated zcml for every package leaves them
logically related to the implementation.
It's also easier to maintain:
- The zcml for an implementation has the same release cycle as the
implementation.
- Every relevant change in an implementation would need changes by a
number of zcml package maintainers (Grok, Zope2, Zope3ZMI) that
don't know the package nearly as good as the package maintainer.
I would prefer to find them inside the implementation packages where
possible. Where it's intended to reduce dependencies a dedicated zcml
package like zope.i18n_zcml is at least more clear.
..Carsten
___
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] zopectl does not terminate
Hi all I run my script foo.zctl with zopectl run foo.ctl param1 param2. This script operates on a large ZODB and catches ConflictErrors accordingly. It iterates over a set, updates data and commits the transaction every 100 iterations. But I've noticed two things: 1. ConflictErrors are never fully caught. The show up in the console (this is acceptable I suppose), but my script stops executing on the conflict and does not continue. The zope process stays alive. 2. In the event of no conflict errors my script executes its last line (print 'done') but the process does not always terminate. If I instruct my script to not update the ZODB at all it terminates without problems. I'm running it on a live site with 7 ZEO clients. I've stopped a client (say client 2) so it is not accessed concurrently and run my script with client2/zopectl. It is in fact a Plone site but that should be irrelevant. Thanks for any help Hedley ___ 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] zc.relationship - can't pickle module objects
Gary Poster wrote: Yes, +1. Thank you. I was about to write to your other message that this was quite possibly the only 3.8 dependency. Cool. Committed. If we do that, then we can let plone.relations depend on zc.relationship 1.1.1 explicitly and have support for both ZODB versions, which would be nice. Sounds great. Would you like access to the PyPI zc.relationship record so you can upload the new version? If so, are you optilude there? That'd be great, yeah. Or else, if you want to tag a release from the 1.1 branch, that should be safe (and even less work for me :-) Cheers, 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 )
