Re: [Zope-dev] traversal: different with and without a request
Previously Jim Fulton wrote: > > On Oct 17, 2008, at 1:13 PM, Stephan Richter wrote: > > > On Friday 17 October 2008, Jim Fulton wrote: > >> It would be nice to deprecate zope.traversing and fold it into > >> zope.app.pagetemplate. > > > > Just skimming the thread, wouldn't this make it harder for us to > > integrate > > z3c.pt, which also needs those traversal APIs? > > > Yup. Actually, this wants to be in zope.tales. Does z3c.pt use > zope.tales? No. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It 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] zope.app.container won't compile
Previously Alexander J Smith wrote: > I just tagged a 3.6.2 version with Sidnei's fix and pushed it to > PyPI. However, the problem of depending on SVN 'trunk' externals is > still present and will have to be addressed at some point. Can you change the externals to use a revision pin? At least that will prevent ongoing work on trunk from breaking the tag. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It 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] ZCatalog caching with memcached
Previously Andreas Jung wrote: > On 25.10.2008 14:37 Uhr, Christian Theune wrote: > >Hi, > > > >On Fri, 2008-10-24 at 15:41 +0200, Hedley Roos wrote: > >>The product is a monkey patch to Catalog.py. I'd love some feedback and > >>suggestions. > > > >I'd love if this wouldn't be a monkey patch. > > > >Also, there is nothing that makes this integrate correctly with > >transactions. Your cache will happily deliver never-committed data and > >also it will not isolate transactions from each other. > > The problem with memcached is that memcached isn't transactional. We > managed to solve this problem by implementing a cache tool (for CMF) > where where the set/get methods for the memcached participate in the > Zope transaction using a DataManager. I can provide the code if someone > should be interested. If I remember correctly memcached is transactional internally but the python bindings don't expose that. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It 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] Zope 2.12 features
Previously Hanno Schlichting wrote: > Still I'd put my list out here. Maybe there are others who have been > thinking into the same direction. Here's a list of things I'd like to > see in a 2.12 release: > > - Reconsider getting rid of ZClasses > > I know this one is not popular, but from what I can see, the number of > supporters of ZClasses are in a minority and the community at large has > moved on into a different direction. Removed ZClasses would allow us to > get rid of much weird code that is only written to support them, in both > product initialization and things like the persistent product registry. +1 In addition I would like to see some hooks to make plone.validatehook and plone.postpublicationhook obsolete. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It 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] [ZODB-Dev] SVN woes.
On 11/11/08 4:10 PM, Izak Burger wrote: Jim Fulton wrote: I'm going to restore svn from a backup and see where that leaves us. I'm going to disable svn access while I work on this. Good luck :-) I know a little something about the hard work involved in recovering subversion repos, in the last year we had TWO cases of corrupted revisions in an svn repo we were managing. It had something to do with concurrent commits and the fact that we were running apache-mpm-worker (instead of prefork). FWIW, the setup we have for svn.plone.org may be useful for others as well: we have two servers (svn.plone.org and svn-mirror.plone.org) with a svnsync setup to keep the mirror (almost) realtime in sync with the main server. There is an LDAP database which is replicated between the two servers as well which we use for authentication. This setup allows us to swich svn.plone.org to the other server in minutes if it dies, without any loss of data. Wichert. ___ 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] deprecate http://download.zope.org/distribution
Previously Tres Seaver wrote: > Anybody who really needs such an egg should be competent to rebuild it > from SVN (since the revision ID or tag is implied by the name), and > should certainly be willing to host that egg in a private index / > location for their project: in fact, they should take this discussion > as notice to copy the egg to such a location *now*. download.zope.org/distribution/ appears to be the only location for the PILwoTK egg. Is there another place where one can get that? Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It 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] zope.index
Previously Marius Gedminas wrote: > On Tue, Dec 02, 2008 at 02:04:39AM +0300, Dan Korostelev wrote: > > I just removed zope.testing from the zope.index dependency and > > replaced zope.testing.doctest imports with plain python doctest and it > > seems to work with python 2.4 and 2.5 here. Now, it only depends on > > ZODB3 and zope.interface, which is nice :) Is there any objections on > > this? > > Yes. > > Using 'import doctest' rather than 'from zope.testing import doctest' > was a pretty reliable way to break test.py --coverage, at least on > Python 2.4. Isn't that a bug in test.py that should be fixed then? Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It 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: Zope Tests: 4 OK, 2 Failed]
Previously Tres Seaver wrote: > As an aside / vent: the reason for the now-removed EXTERNALS.txt files > was to keep the canonical information about the externals in a diffable > file: why subversion can't do a proper diff on its own line-oriented > property is beyond me. Another benefit of an EXTERNALS.txt file was > that it could be inspected in the web view of a directory, which isn't > true for the svn:externals property itself. If only svn.zope.org had a trac-based browser, which does show those properties properly... Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It 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: Zope Tests: 4 OK, 2 Failed]
Previously Godefroid Chapelle wrote: > Tres Seaver wrote: > > > > > As an aside / vent: the reason for the now-removed EXTERNALS.txt files > > was to keep the canonical information about the externals in a diffable > > file: why subversion can't do a proper diff on its own line-oriented > > property is beyond me. Another benefit of an EXTERNALS.txt file was > > that it could be inspected in the web view of a directory, which isn't > > true for the svn:externals property itself. > > > > > > Tres. > > I want to support this. The noise made by keeping EXTERNALS.txt in svn > is very low compared to the signal it provides. I don't. EXTERNALS.txt is only useful if your tools suck. There are perfectly capable svn commit mailers and web browsers that show property changes correctly. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It 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] Dependencies question
Previously Dan Korostelev wrote: > I was looking at dependencies of various zope.* packages and see that > some packages depend on other because of ZCML directives and some are > not. For example: > > The zope.app.catalog package depends on zope.app.component, but > doesn't use it anywhere in non-testing code, however it does use the > ``class`` directive, registered in zope.app.component. > > While the zope.app.keyreference doesn't depend on zope.app.component > at all, but uses ``class`` directive as well. > > So, the question is: what's the common policy for that? Should we > depend on packages that is used in ZCML or not? Or maybe ZCML-related > dependencies should be in some extras_require, say "zcml"? There is certainly precendence for that (zope.component and zope.i18n iirc). > Personally, I think, that extras_require way is a nice compromise for > that. Because many of packages can be used greatly without ZCML > configuration, but getting ZCML-reqired dependencies should be easy. +1 Those zcml dependencies make it a lot more painful to use zope.* packages in other environments. Wichert. -- Wichert Akkerman It 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] Salt-weakness in zope.app.authentication passwordmanagers?
Previously Dan Korostelev wrote: > Yeah, that's definetely a mistake! The hash needs to be generated > using both salt and password. > > Also, I saw a technique when you generate a hash using double hashing, > like this: sha(sha(password) + salt).hexdigest(). It looks even more > secure :) Why would it make things more secure? Wichert. -- Wichert Akkerman It 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] Salt-weakness in zope.app.authentication passwordmanagers?
Previously Uli Fouquet wrote: > Hi Dan, > > thanks for your quick response. > > Dan Korostelev wrote: > > Yeah, that's definetely a mistake! The hash needs to be generated > > using both salt and password. > > > > Also, I saw a technique when you generate a hash using double hashing, > > like this: sha(sha(password) + salt).hexdigest(). It looks even more > > secure :) > > Hm, not sure. Building the hash of a hash doesn't give a more equal > distribution, does it? Therefore it doesn't look 'more secure' to me. It would not surprise me if it would in fact not be considerably weaker. The cleartext space for the second hash is a lot smaller and very predictable (you know the exact string length and that is only consists of digits and lowercase letters), making an attack simpler. Wichert. -- Wichert Akkerman It 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] zope.globalrequest?
Previously Tres Seaver wrote: > I don't actually know how this package fits in with either Z2 or Z3: Z2 > apps are always able to acquire the request, while Z3 apps use the > "separation of concerns" pattern I just outlined. I've never wanted a > 'get_request' method in "production" code: I would consider the need > for it a sign that something in the application is factored wrongly. Z2 apps are increasingly not able to acquire the rest due to the use of utilities, and utilities trying to use Zope2 code that assumes the request can be acquired. This is very noticable in CMF with the GenericSetup setup tool. Wichert. -- Wichert Akkerman It 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] Plans for Zope 2.12
Previously Tres Seaver wrote: > Andreas Jung wrote: > > - removing ZClasses completely > > - -0. I don't want to invest effort in maintaining them, but if they are > still working for people in 2.11, I don't think we need to rip them out. +1 There is a whole lot of legacy code surrounding Zope startup and the persistent control panel that is only there to support ZClasses. Removing them would allow for a lot of further cleanups in a particularly crufty part of the Zope2 codebase. > > - how do to a "traditional" SVN checkout of the Zope 2 and the related > > Zope 3 modules? The Zope2.buildout maintains its dependencies through > > a KGS - the old-style SVN checkout uses svn:external. I think there > > is a need for having both and don't know of a save way for keeping > > the svn:externals and the KGS in sync (without additional manual > > effort). > > I'm actually willing to abandon the "big tree" altogether, unless > somebody comes up with a clever way to automate it from some Z2-specific > KGS index. I think the canonical "source install" would be something > like a tarball of a buildout tree, with the 'download-cache' directory > already populated (maybe). Judging by the awesome lack of interest in a Zope 3 big tree release, and observing that Zope 2 is going down a similar eggification path I see no reason to keep a big tree for Zope 2 long term. Wichert. -- Wichert Akkerman It 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] Plans for Zope 2.12
Previously Laurence Rowe wrote: > It's possible to have egg dependencies on development versions of other > eggs so long as there is an svn egg link on the pypi page. > > For example in zope.sqlalchemy's pypi page I include a link like to: > > svn://svn.zope.org/repos/main/zope.sqlalchemy/trunk#egg=zope.sqlalchemy-dev > > And in the past I have had the trunk setup.py instal_requires include: > > 'SQLAlchemy>=0.5.0beta3dev-r4954', or 'SQLAlchemy>=0.4.7dev', Which also shows that using a setup.cfg to put revision numbers in dev versions is extremely useful :) Wichert. -- Wichert Akkerman It 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] ZCML implementations: where should they go
Previously Martijn Faassen wrote: > We have several ways to go: > > a) continue with the current extra dependencies situation like in > zope.component, and in fact clean up other packages that define ZCML to > declare ZCML extra dependencies. +1 I'ld rather not see a whole slew of extra packagse appear. I also wonder how the extra number of packages and increasing size of sys.path influence performance and restrictions on environments like GAE. > b) pull out all ZCML implementations from where they are now and put > them in special ZCML implementation packages. We could for instance have > zcml.component, or zope.component_zcml, or zope.configuration.component. > We had a bit of a side-tracked discussion about naming and namespace > packages here. +0.5 It solves the problem in a consistent way > c) pull out only those ZCML implementations that cause extra > dependencies beyond zope.configuration. So, we extract the bits of > zope.component into a new package, but we don't extract bits from > zope.security. +0.1 This introduces inconsistencies that might be confusing. Wichert. -- Wichert Akkerman It 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] SVN: zope2book/trunk/ Lot's of updates over the weekend!
Previously Martijn Pieters wrote: > On Tue, Feb 17, 2009 at 12:08, Tino Wildenhain wrote: > > You should really not generate CSS ;) And JS is best generated with > > Jason :-) > > You need to generate CSS when you want to use absolute paths for > images referred to in your CSS. This can easily be done with ZPT: Very often you don't need to do that though, and it actively breaks the ability to do prototyping with your html and css outside of the application. Wichert. -- Wichert Akkerman It 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] Single Sign On
Previously Shane Hathaway wrote: > Alternatively, I have wondered if we actually need full-blown SSO; > perhaps a carefully constructed domain-wide cookie would do the trick. > Any experiences with that? auth_tkt based cookies sounds like a good option, possibly combined with something like SQL or LDAP for shared member properties. It has the advantage of being very widely supported as well as bwing very simple. CAS appears to be a common SSO system used for Plone sites and should work as well. Wichert. -- Wichert Akkerman It 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] Coding style clarifications
Previously Christian Theune wrote: > Hi, > > while gathering, cleaning and consolidating the various statements that > float around about the coding style for Zope 3, I found a couple of > issues that I'd like to get clarification for. > > What I found is currently gathered at > http://svn.zope.org/zope3docs/source/codingstyle/python-style.rst?rev=96729&view=auto > > Which attribute naming is current? > == > > Do we use under_scores or mixedCaseNames? > > I think I remember that we decided to follow PEP 8 for new code and > invoke the "local consistentency" rule on old code. Is that correct? That would make the end result inconsistent. I seem to remember camel case being declared 'the zope standard'. Wichert. -- Wichert Akkerman It 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] Retiring dev.zope.org aka /devhome wiki
Previously Reinout van Rees wrote: > Could someone chime in with a bit of an overview: > > http://docs.zope.org/ > Where is the svn source? svn.zope.org/zope2docs and /zope3docs > http://zode01.lovelysystems.com/ > That's the now-stopped zope.org refactoring, right? Right. It's the internal hostname for the machine that run/ran new.zope.org. Wichert. -- Wichert Akkerman It 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: zope.app.openidconsumer/ New library for OpenID auth in Zope 3
Previously Dan Korostelev wrote: > 2009/2/24 Shane Hathaway : > > Log message for revision 97183: > > New library for OpenID auth in Zope 3 > > > > > > Changed: > > A zope.app.openidconsumer/ > > Wow, that's great! Finally an OpenID auth plugin is being developed! plone.openid has been out since August 2007, so it's hardly the first OpenID auth implementation for Zope.. Wichert. -- Wichert Akkerman It 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] setup.py "extra" dependencies
Previously Martijn Faassen wrote: > I therefore think zope.app.testing is one package we should be looking > to get rid of eventually by splitting it up among a lot of 'testing' > modules in individual packages. This way we won't have zope.app.testing > sitting at an edge against our whole dependency tree. Since this is a > lot of work this will be an ongoing project but we could at least agree > we *want* to do this. > > Opinions? I would like to see a move away from zope testing frameworks to a more standard testing infrastructure: setup.py test, possibly combined with using nose. Wichert. -- Wichert Akkerman It 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] setup.py "extra" dependencies
Previously Sidnei da Silva wrote: > On Thu, Mar 5, 2009 at 5:20 PM, Wichert Akkerman wrote: > > I would like to see a move away from zope testing frameworks to a more > > standard testing infrastructure: setup.py test, possibly combined with > > using nose. > > > > Wichert. > > Be aware of nose issue #102: > > http://code.google.com/p/python-nose/issues/detail?id=102 Is there a particular reason to keep using the test_suite convention? Personally I much prefer nose's habit of automatically picking up tests. Wichert. -- Wichert Akkerman It 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] z3c.form: nested group
Previously Laurent Mignon wrote: > Martin Aspeli wrote: > > Laurent Mignon wrote: > >> Hi, > >> > >> 2 weeks ago, I've implemented a support for nested group into the > >> branch svn://svn.zope.org/repos/main/z3c.form/branches/sagblmi-nestedgroup > >> > >> All test pass and no compatibility issue. > >> > >> Can I merge it to the trunk? > > > > What's the use case for this? > > > > Martin > > > By nesting groups I can define fiedlsets inside tab inside fieldset > inside tab +1 Nested fieldsets are very useful when designing forms. Wichert. -- Wichert Akkerman It 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] [Zope3-checkins] [Checkins] SVN: zope.app.component/trunk/setup.py set missing minimum version
Previously Stephan Richter wrote: > On Saturday 14 March 2009, Michael Howitz wrote: > > Log message for revision 98113: > > set missing minimum version > > > > > > Changed: > > U zope.app.component/trunk/setup.py > > > > -=- > > Modified: zope.app.component/trunk/setup.py > > === > > --- zope.app.component/trunk/setup.py 2009-03-14 19:56:47 UTC (rev 98112) > > +++ zope.app.component/trunk/setup.py 2009-03-14 20:14:47 UTC (rev 98113) > > @@ -78,7 +78,7 @@ > > 'zope.interface', > > 'zope.lifecycleevent', > > 'zope.location>3.4.0b1', > > - 'zope.publisher', > > + 'zope.publisher>=3.6.0', > > 'zope.schema', > > 'zope.security', > > 'zope.traversing', > > Please, please, please no versions in setup.py. If the package does not work with an older version of zope.publisher than imho that version restriction *has* to be in setup.py. Wichert. -- Wichert Akkerman It 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] [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 It 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] 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 It 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] setting missing minimum version in setup.py
Previously Jacob Holm wrote: > 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 see no useful different between x.y and x.y.z here. All I want is if someone installs one of our packages that package will work as expected. If a package will only work with a certain revisions of a dependent package it has to state say. If we do not do that we are making it very hard for people to use Zope packages: we are effectively telling them that we make no guarantee about package stability and they will have to either use one of our many KGS or figure out all dependencies by hand. I do not think that is an acceptable message, and it certainly will not encourage people to use Zope packages. Wichert. -- Wichert Akkerman It 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] setting missing minimum version in setup.py
Previously Martijn Faassen wrote: > Wichert Akkerman wrote: > [snip] > > I see no useful different between x.y and x.y.z here. All I want is if > > someone installs one of our packages that package will work as expected. > > If a package will only work with a certain revisions of a dependent > > package it has to state say. > > I do see a useful difference between the two. > > x.y is a feature release that might have changed the API or behavior. If > you rely on this in a version of your package, you will have to indicate > that this is so. > > x.y.z is a bugfix release. If we do it right, there will be no change in > the API and only small changes in misbehavior. Therefore it seems far > less likely to me that a package ends *needing* to depend on a minimum > version. In addition, porting back bugfix releases is far harder. If version x.y of package A adds a new feature which requires a feature in package B, but was broken in B until version d.e.f of that package, I would expect version x.y of package A to have a dependency on version d.e.f of package B. Do you agree with that? Wichert. -- Wichert Akkerman It 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] setup.py "extra" dependencies
On 3/23/09 12:57 PM, Chris Withers wrote: > Christian Theune wrote: > Wichert. Be aware of nose issue #102: http://code.google.com/p/python-nose/issues/detail?id=102 >>> Is there a particular reason to keep using the test_suite convention? >>> Personally I much prefer nose's habit of automatically picking up >>> tests. >> >> I think there is not. One of the reasons I refactored the test runner a >> while ago was to make it possible to support a less-boilerplate-heavy >> scheme of getting tests set up. > > Well okay, but without test_suite, how do you quickly and easilly > disable a class full of tests while you work on something else that > will break them but that you don't want to deal with just yet? nose has a --exclude option Wichert. ___ 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 Chris Withers wrote: > Benji York wrote: > > 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. > > I don't think that's your call to make, it's the maintainer of > zope.foo's call. > > > 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. > > WRONG! If you use a package, you need to accept that its dependencies > are decided by its author. Guessing that you know better than its author > is a very dangerous game and leads to a path where you might as well not > bother using a package manager at all and just go back to hit'n'hope... > > > If there were a way to ignore setup.py version requirements I'd be happy > > to have them and ignore them. > > Wow... > > > Alternatively (my preference) the package would set versions in its > > buildout using the KGS against which it works (plus any exceptions). > > KGS will be a zope dead-end imnsho... It's useful, but I don't see > anyone outside the Zope community caring about it... This is an important point. As I see it the KGS is a Zope-only thing, and is just a workaround for the mindless behaviour of setuptools. I do not see it gaining acceptance outside of the Zope community, and imho effort is better spent on improving the packaging tools. Wichert. -- Wichert Akkerman It 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] setting missing minimum version in setup.py
Previously Andreas Jung wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 23.03.2009 14:26 Uhr, Wichert Akkerman wrote: > > > > > This is an important point. As I see it the KGS is a Zope-only thing, > > and is just a workaround for the mindless behaviour of setuptools. I do > > not see it gaining acceptance outside of the Zope community, and imho > > effort is better spent on improving the packaging tools. > > > > Are there other Python projects that have to deal with such a huge > amount of packages and dependencies? I don't know any similar project. > So the solution must come from the Zope world (which does not mean that > we participate in the packaging toolchain development as Tarek does). I don't know. I just feel quite strongly that improving the packaging tools would be a better use of manpower than working on the KGS in its current form. Wichert. -- Wichert Akkerman It 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] Please use launchpad bugtracking/blueprints more
Previously Christian Theune wrote: > We need to start using Launchpads tracking mechanisms for issues, filing > bugs or blueprints much earlier and much more often than having threads > just sit around in the zope-dev archive and *maybe* get picked up. Can someone document how they work? I have never been able to understand what blueprints do from browsing the launchpad docs. Wichert. -- Wichert Akkerman It 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] trying out the buildout-based Zope 2.12...
Previously Chris Withers wrote: > Paul Winkler wrote: > > Well, yeah. The point of the suggestion was specifically to help you > > get more info about the dependency chain, since pip is more verbose > > about that than easy_install is. > > Well, running buildout -v gives some good clues, a piece of which is > this: > > Getting required 'zope.app.security' >required by zope.app.publication 3.5.1. >required by zope.app.component 3.6.0. >required by zope.app.testing 3.6.0. > We have the best distribution that satisfies 'zope.app.security'. > Picked: zope.app.security = 3.7.0 > > > Okay, cute, but WHY is 3.7.0 being picked, rather than the 3.6.0 that's > nailed down in zope2 2.12.0a1's setup.py?! Because buildout is not installing the Zope2 at that point, so it is not using any version pins defined by the Zope2 egg. That is a design flaw in setuptools at the moment: it works package-by-package instead of trying to figure out what the final target working set should look like. Wichert. -- Wichert Akkerman It 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] trying out the buildout-based Zope 2.12...
Previously Chris Withers wrote: > If you're proposing fixing it in buildout because getting changes made > to setuptools and then getting a release of setuptools made is damned > near impossible, then that's sad state of affairs for the whole python > community :-( You can compare this with dpkg and apt on Debian and Ubuntu systems: dpkg is the lower level install that installs one or more packages. It only checks if the packages you install break any package conflicts and if their dependencies are met. It is simpler than easy_install: it will not look for or download packages itself. Python does not have a such a low level tool - I think it would be useful to factor that out of setuptools into a separate package. Apt is the higher level tool: you give it a list of places where it can find packages (similar to pypi indices, except it does not have a download url concept (which tends to only hurt you anyway) and it figures out what should be done to install a set of packages without violating any constraints. Once it knows how to do this it downloads the packages and calls dpkg to do the actuall installation. I think it makes sense to have a similar approach in python: have a pure installation tool (a subset of easy_install) as well as higher level tools such as zc.buildout which have all the logic necessary to find packages to install and figure out a strategy to get to a target working set. Wichert. -- Wichert Akkerman It 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] trying out the buildout-based Zope 2.12...
On 3/30/09 4:04 PM, Jim Fulton wrote: > > On Mar 29, 2009, at 4:10 PM, Wichert Akkerman wrote: > ... >> You can compare this with dpkg and apt on Debian and Ubuntu systems: >> dpkg is the lower level install that installs one or more packages. It >> only checks if the packages you install break any package conflicts >> and if their dependencies are met. It is simpler than easy_install: it >> will not look for or download packages itself. Python does not have a >> such a low level tool > > Yes it does, the setup install command. That's not quite the same. If you give someone a .egg, .zip or a .tar.gz file they can't install it with a single command. For an egg you will need easy_install, for the other two it is a two step process of unpacking and calling setup.py. Wichert. ___ 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 Source Code Repository
Previously Marius Gedminas wrote: > BTW I've yet to see a firewall that blocks SSH. Am I lucky? Yes. Blocking ssh is very common in larger companies in me experience. Wichert. -- Wichert Akkerman It 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] Constant values defined in interfaces
Previously Chris Rossi wrote:
> I was wondering if the Zope collective had given any consideration to
> allowing constants to be defined in interfaces. To be clear, these are
> constant values that make up the protocol defined by the interface. Just to
> have a concrete example, let's say we're modeling an http response:
>
> class IHttpResponse(Interface):
> """Models an HTTP 1.1 response.
> """
> status = Attribute("HTTP status code for this response.")
>
> It might be useful to include in our interface spec what some proper values
> for status code might be and make them available to applications as static
> constants on the interface class. A naive implementer might do something
> like this:
>
> class IHttpResponse(Interface):
> """Models an HTTP 1.1 response.
> """
> HTTP_OK = "200 Ok"
> HTTP_NOT_FOUND = "404 Not Found"
>
> status = Attribute("HTTP status code for this response.")
This looks like a poor man's enum. I'ld prefer to have a proper enum
like thing.
Wichert.
--
Wichert Akkerman It 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] Zope Source Code Repository
Previously Martijn Pieters wrote: > On Mon, Apr 6, 2009 at 10:32, Chris Withers wrote: > > Just beware, 1.5 sucks: > > > > http://subversion.tigris.org/issues/show_bug.cgi?id=3242 > > http://thread.gmane.org/gmane.comp.version-control.subversion.user/84308/focus=84019 > > http://thread.gmane.org/gmane.comp.version-control.subversion.user/87346/focus=87525 > > It sucks for very specific cases, namely tight access control on > sub-paths. I don't see such cases, and I see speed improvements > instead. > > Note that we are now up to svn 1.6. Which still does not fix this, and is preventing people from upgrading to the 1.5 client, and thus from using checkouts using relative paths. Wichert. -- Wichert Akkerman It 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] setting missing minimum version in setup.py
Previously Chris Withers wrote: > Tres Seaver wrote: > >>>> KGS the > >>>> concept is very easy to implement; you just make available on some URL a > >>>> buildout versions.cfg, or you run your own package index. > >>> OK, the former I can see happening on an end-user project, the latter is > >>> just too much work. > > > > Not really. Collect the tarballs, run a script, configure Apache to > > serve that diretory. > > Hmm, too much... but is it needed? > Can you not point index at just a local folder on disk? > I'm sure the Plone folks did something like this, maybe Hanno can chime in? What we do is: collect the tarballs, serve the resulting directory. I have not seen a need to run a script. Wichert. -- Wichert Akkerman It 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] setting missing minimum version in setup.py
Previously Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Wichert Akkerman wrote: > > Previously Chris Withers wrote: > >> Tres Seaver wrote: > >>>>>> KGS the > >>>>>> concept is very easy to implement; you just make available on some URL > >>>>>> a > >>>>>> buildout versions.cfg, or you run your own package index. > >>>>> OK, the former I can see happening on an end-user project, the latter > >>>>> is > >>>>> just too much work. > >>> Not really. Collect the tarballs, run a script, configure Apache to > >>> serve that diretory. > >> Hmm, too much... but is it needed? > >> Can you not point index at just a local folder on disk? > >> I'm sure the Plone folks did something like this, maybe Hanno can chime in? > > > > What we do is: collect the tarballs, serve the resulting directory. I > > have not seen a need to run a script. > > If you want to an index, rather than just a directory for 'find-links', > you need to create the 'PyPI simple format' directory structure. What is the advantage of creating an index? Wichert. -- Wichert Akkerman It 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] setting missing minimum version in setup.py
Previously Chris Withers wrote: > Wichert Akkerman wrote: > > What we do is: collect the tarballs, serve the resulting directory. I > > have not seen a need to run a script. > > How do you collect the tarballs? buildout download cache > How do you serve the resulting directory? standard apache directory listing: http://dist.plone.org/release/ Wichert. -- Wichert Akkerman It 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] naming Zope
Previously Martijn Faassen wrote: > I think renaming Zope 2 to Zope Classic will be easy. If the Zope 2 > developers are okay with this, let's go right ahead. Not much discussion > needed. Zope 2.11 becomes Zope Classic 11. It's a huge version number, > but Zope Classic is over a decade old anyway. Nobody's going to mind. It > looks impressive and it should be impressive; Zope Classic has been > maintained for a long time by the community. -1 The term `classic' is associated with things like old, ancient and obsolete to me and immediately makes me want to figure out what the new thing is. I do not think that is desired here: Zope 2 is just as hip and modern as Zope 3 and deserves just as much attention. Wichert. -- Wichert Akkerman It 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] naming Zope
Previously Martijn Faassen wrote: > How to get out of that bind? We could consider renaming Zope 3. Is there > any potential for this? I doubt many see Zope 3 as a finished product - I get the impression everyone is using it as a grab bag if tools to build their own applications. It certainly has not seen any marketing push in that direction, unlike Zope 2. This suggests that renaming Zope 3 is not problematic. > If we don't call Zope Framework "4.0", we'll be fine. We should call its > first release 1.0 and there's no implication of a progression. +1 To stir things up: I would like to suggest renumbering the next Zope 2 release to Zope 4. That reflects the large refactoring that is being done to clean up the codebase and fully eggify Zope. There are enough changes to warrant a new major version bump. Wichert. -- Wichert Akkerman It 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] naming Zope
Previously Jim Fulton wrote:
> 3. I think the word "Zope" should refer to both the application
> currently called Zope 2 and the Zope ecosystem, depending on context,
> although I'm also fine with coming up with another name as long as it
> doesn't imply obsolescence. :)
I am somehow reminder of X, which goes under many names. From its
manpage:
The X Consortium requests that the following names be used when refer-
ring to this software:
X
X Window System
X Version 11
X Window System, Version 11
X11
Wichert.
--
Wichert Akkerman It 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] naming Zope
Previously Martin Aspeli wrote: > Wichert Akkerman wrote: > > > To stir things up: I would like to suggest renumbering the next Zope 2 > > release to Zope 4. That reflects the large refactoring that is being > > done to clean up the codebase and fully eggify Zope. There are enough > > changes to warrant a new major version bump. > > -100 again. We need to stop confusing people! > > The only way we could do this would be if we definitely, 100%, > with-an-axe killed off any notion of Zope 3 as an app server or > application development framework and told everyone "the thing you need > to be using if you like Zope, is this Zope thing that's basically Zope > 2.14). > > We won't do that. Actually, we have already done that. Wichert. -- Wichert Akkerman It 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] naming Zope
Previously Shane Hathaway wrote: > > > Tres Seaver wrote: > > WRT the "Framework" name: "framework" is a misleading name for the > > collection of packages salvaged from the "new Coke" effort: it is > > actually a *bunch* of frameworks, in the classic software engineering > > sense, along with some "pure" libraries. > > Zope Toolkit, perhaps? (No relationship to Portal Toolkit. :-] ) +1 Cute. Wichert. -- Wichert Akkerman It 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] who wants to maintain Zope 3?
Previously Martin Aspeli wrote: > Hermann Himmelbauer wrote: > > > -1 from my standpoint. Two of my projects are fully based on the Zope 3 > > server, and switching to something else would be quite some pain. > > FWIW, I think you're absolutely right. We can't just declare it "dead" > because it is convenient to our goal of having clearer definitions about > what we're working with. We can effectively not maintain it anymore and stop making release. Which would not be a major change from Zope 3 releases the last few years :) Wichert. -- Wichert Akkerman It 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 )
[Zope-dev] Release management proposal
I want to suggest two changes to the standard release process: 1. use "sdist --formats=zip". This works around a nasty bug in the python 2.4 tarfile module which makes it skip files with a path of a specific length. This can make a release impossible to use. 2. forbid the use of __file__ in setup.py. This breaks on systems which do not have setuptools installed globally but rely on a (zc.buildout-created) wrapper script. __file__ will point to the wrapper script in those instances, which breaks setup.py. Wichert. -- Wichert Akkerman It 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] Release management proposal
Previously Benji York wrote: > On Wed, Apr 22, 2009 at 10:06 AM, Wichert Akkerman wrote: > > I want to suggest two changes to the standard release process: > > > > 1. use "sdist --formats=zip". This works around a nasty bug in the > > python 2.4 tarfile module which makes it skip files with a > > path of a specific length. This can make a release impossible to use. > > The bug you refer to is indeed nasty, but (IIRC) was fixed in later > releases of 2.4. I'd rather not add yet another thing people have to > remember to do to make a release for the benefit of such a small > minority of end-users. It was introduced in the last release of 2.4. As far as I know there are no plans to make a new 2.4 point release. > > 2. forbid the use of __file__ in setup.py. This breaks on systems > > which do not have setuptools installed globally but rely on a > > (zc.buildout-created) wrapper script. __file__ will point > > to the wrapper script in those instances, which breaks setup.py. > > Is there something zc.buildout or setuptools can do differently that > will mitigate this? I don't know I'm afraid. Wichert. -- Wichert Akkerman It 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] Release management proposal
On 4/22/09 4:57 PM, Jim Fulton wrote: > Perhaps you could provide (or point to) an example that illustrates > this problem. I want to keep my python install clean, so I do not have setuptools installed system-wide. Instead I have a small bin-directory managed by buildout which creates a python interpreter with setuptools, using this snippet: [setuptools] recipe = zc.recipe.egg interpreter = spython eggs = setuptools scripts = spython That allows me to use "spython setup.py sdist register upload". setup.py is invoked with __file__ pointing to the spython wrapper script, so any attempt in setup.py to use __file__ to found files will fail. Wichert.= ___ 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] Release management proposal
Previously Benji York wrote: > On Wed, Apr 22, 2009 at 10:55 AM, Wichert Akkerman wrote: > > Previously Benji York wrote: > >> On Wed, Apr 22, 2009 at 10:06 AM, Wichert Akkerman > >> wrote: > >> > I want to suggest two changes to the standard release process: > >> > > >> > 1. use "sdist --formats=zip". This works around a nasty bug in the > >> > python 2.4 tarfile module which makes it skip files with a > >> > path of a specific length. This can make a release impossible to use. > >> > >> The bug you refer to is indeed nasty, but (IIRC) was fixed in later > >> releases of 2.4. I'd rather not add yet another thing people have to > >> remember to do to make a release for the benefit of such a small > >> minority of end-users. > > > > It was introduced in the last release of 2.4. As far as I know there are > > no plans to make a new 2.4 point release. > > That is most unfortunate. > > Maybe we should officially drop 2.4 support instead. Unfortuantely there is a large group of people using Plone on Zope 2.10 who can not upgrade to a newer python version, and they are very interesting in the Zope Toolkit candy. Wichert. -- Wichert Akkerman It 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] Release management proposal
Previously Martijn Faassen wrote: > Wichert Akkerman wrote: > > > 2. forbid the use of __file__ in setup.py. This breaks on systems > >which do not have setuptools installed globally but rely on a > >(zc.buildout-created) wrapper script. __file__ will point > >to the wrapper script in those instances, which breaks setup.py. > > This will break many setup.py scripts that use __file__ to integrate > README.txt and such for publication on pypi. I think that's a useful > feature we cannot just drop, so hopefully there's another solution. Can we assume that the cwd is the root of the package? Do you ever invoke setup.py from somewhere else? All Plone packages make that assumption and we've never seen any problems with it. Wichert. -- Wichert Akkerman It 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] Release management proposal
On 4/22/09 5:05 PM, Jim Fulton wrote: > > On Apr 22, 2009, at 11:01 AM, Wichert Akkerman wrote: > >> On 4/22/09 4:57 PM, Jim Fulton wrote: >>> Perhaps you could provide (or point to) an example that illustrates >>> this problem. >> >> I want to keep my python install clean, so I do not have setuptools >> installed system-wide. Instead I have a small bin-directory managed >> by buildout which creates a python interpreter with setuptools, using >> this snippet: >> >> [setuptools] >> recipe = zc.recipe.egg >> interpreter = spython >> eggs = setuptools >> scripts = spython >> >> >> That allows me to use "spython setup.py sdist register upload". >> setup.py is invoked with __file__ pointing to the spython wrapper >> script, so any attempt in setup.py to use __file__ to found files >> will fail. > > > This sounds like a bug in interpreter-script's handling of scripts > passed to it. I'll look into that. Thanks > BTW, did you realize that buildout has a setup command that does what > your spython script does (and a little more)? I was not aware of that. I can see that being useful. Most of my packages do not have their own buildout, so this won't help much for this particular issue I'm afraid. Wichert. -- Wichert AkkermanIt 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] Zope 2.12.0a4 easy_installable - please test
Previously Hanno Schlichting wrote: > Andreas Jung wrote: > > Please give feedback. > > Cool! > > Would you mind adding the versions.cfg from the Subversion tag to > http://download.zope.org/Zope2/index/2.12.0a4/versions.cfg ? > > Makes for a bit more sensible URL compared to > http://svn.zope.org/*checkout*/Zope/tags/2.12.0a4/versions.cfg This works just as well: http://svn.zope.org/repos/main/Zope/tags/2.12.0a4/versions.cfg Wichert. -- Wichert Akkerman It 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] zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues
Hi Gary,
Previously Gary Poster wrote:
> Thanks Uli, Wichert, and Hanno for working out the legal bits! And
> thanks to Martijn and Martin for the other replies.
>
> On Friday I had moved to z3c.recipe.filetemplate, for the reasons I
> had described then. Philipp said I could run with that package.
> However, I'd prefer to work with a more active project. If there's
> quick agreement on my additions to the collective recipe, and I'm
> given commit access, I'll switch. I don't have time for a bikeshed
> discussion though, so if it descends much into that I'll stick with
> extending Philipp's recipe for now, and maybe switch over later when
> things settle down.
Commit access to the collective is very liberal and generally arranged
within 24 hours. Uli has both commit and pypi access for the package and
has already done a lot of work on it. Your contributions are very
welcome as well!
> If I built on collective.recipe.template, I'd make the following
> changes.
>
> REQUIRED
>
> - verify that the BSD licensing rules are followed (headers, license
> inclusion, copyright statement, etc.), and fix if not. I'd prefer if
> a foundation (e.g., the Plone Foundation) had the copyright. (TBH,
> I'm more comfortable with the Zope Foundation repository because the
> rules for copyright assignment are clearer AIUI, even if they are
> breached sometimes, as was this case here. But this isn't critical
> for my usage or contribution.)
The BSD license has very little restrictions. It certainly does not
require licens statementsin every source file or so. Personally I find
those to be clutter. If there is a missing license file that should be
fixed.
> - Add the ability to specify "eggs" and "extra-paths" the way you can
> for scripts. These supply the values for three predefined options
> (available to the template). If "paths" are the non-zip paths, and
> "all_paths" are all paths, then the options woud be defined roughly as
> given here:
>
> os-paths: (os.pathsep).join(paths)
> string-paths: ', '.join(repr(p) for p in all_paths)
> space-paths: ' '.join(paths)
I can see that being useful.
> - I have a directory of *.in files that will need to be processed,
> with shared options, and put in another directory. Therefore, I'd
> like to be able to just specify the input directory and optionally the
> output directory. globs, for filters, might be a nice-to-have. I came
> up with a spelling for all this that appealed to me for Philipp's
> package (which has a constraint of "I only use *.in inputs, and always
> strip ".in" for the output). WIth my variant of his spelling, I could
> do everything I wanted with a line like
>
> files = *
> source-directory = templates
>
> Then in ``templates`` you would arrange the directory structure you
> wanted, and make sure that your template files end with ".in".
>
> I don't have a spelling I like as much for the "input" "output"
> pattern of the collective recipe. I'd be OK with "input" and "output"
> being able to take multiple files:
>
> input = templates/etc/foo.in
> templates/etc/bar.in
> output = etc/foo
> etc/bar
>
> That seems like it rocks the boat least for collective.recipe.template
+1
>
> NICE-TO-HAVE
>
> Unless I discover I need this, these are just ideas that I might do on
> hobby time.
>
> - Extend/override other buildout sections. Here's an example, with
> Philipp's package. Consider the following buildout::
>
> >>> write(sample_buildout, 'buildout.cfg',
> ... """
> ... [buildout]
> ... parts = message
> ...
> ... [template_defaults]
> ... mygreeting = Hi
> ... myaudience = World
> ...
> ... [message]
> ... recipe = z3c.recipe.filetemplate
> ... files = helloworld.txt
> ... extends = template_defaults
> ...
> ... myaudience = everybody
> ... """)
>
> The "message" section now has values extended from the
> "template_defaults"
> section, and overwritten locally. A template of
> ``${mygreeting}, ${myaudience}!`` would thus result in ``Hi, everybody!
> ``.
This feels more like a feature for buildout: I can see this being useful
for other recipes as well.
> - Define option values in Python. This would have the os and sys
> modules in the namespace, and would also have the buildout
Re: [Zope-dev] Release management proposal
Previously Martijn Faassen wrote: > Hey Jim, others, > > Jim Fulton wrote: > > [__file__ in setup.py] > > > Stop talking about this. :) > > > > This is almost certainly a buildout bug that I'll fix. > > Just making sure we have some clear conclusions in this thread... > > Do we have a buildout bug id we can track so we make sure we don't > forget about it? (if it wasn't already fixed?) There is now: https://bugs.launchpad.net/zc.buildout/+bug/368447 Wichert. -- Wichert Akkerman It 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] dropping Python 2.4 support in the Zope Toolkit?
Previously Lennart Regebro wrote: > On Tue, May 5, 2009 at 11:55, Martin Aspeli wrote: > > We've had some more discussions about this and the Plone release > > schedule. The upshot is that if Zope 3/Toolkit drops Python 2.4 support, > > it will effectively render it inaccessible to Plone users for the next > > 12-18 months. We're not comfortable moving to Zope 2.12 for the 3.x > > series. We may be able to move to Zope 2.11, which *may* work with > > Python 2.5, but this is not clear. > > Can you expand on this argument, because I don't understand it. Zope > 2.10 doesn't stop working because Zope 2.12 no longer supports Python > 2.4. And you are not expected to use Zope Toolkit with Zope 2.10, as > Zope 2.10 uses Zope 3.3 rather than Zope Toolkit. But you can use a lot of the Zope Toolkit with Zope 2.10, which is an enormous benefit. If that was not possible a lot of the things people want to do with Plone would not be possible. Wichert. -- Wichert Akkerman It 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] dropping Python 2.4 support in the Zope Toolkit?
Previously Martijn Faassen wrote: > This is a component developed in the context of the Zope Toolkit (or at > least post-Zope 3.4). It depends on zope.container, also new. We > released a backwards compatible zope.app.container (not in the Toolkit) > which relies on zope.container now for its implementation. The previous > version didn't, so you'll need to use this newer version of > zope.app.container too, otherwise you'll end up with two implementations > of Container in a single codebase, which seems dangerous. There's also a > similar issue with zope.app.component (where some of the functionality > moved to zope.site, some to other places). Looking at a project I'm working on I use the following zope packages: zope.sqlalchemy trunk zope.location 3.4.0 zope.component 3.4.0 zope.security 3.5.2 zope.testing 3.7.1 zope.i18n 3.4.0 zope.proxy 3.5.0 zope.intid 3.7.0 zope.app.zcmlfiles 3.5.3 zope.securitypolicy 3.4.0 zope.container 3.8.1 zope.app.publisher 3.5.2 zope.keyreference 3.6.1 zope.broken 3.5.0 zope.browser 0.5.0 This works today in Plone 3.3. It's a bit painful to find a set of versions which work well together with all the current refactoring, but as you can see it is possible, and extremely valuable for us. > But it does mean replacing huge parts of the Zope 3 underneath of a > release of Plone just so people can install a new version of z3c.form... > And hoping that the zope.app.* packages (not in the toolkit) will > continue to work. > > What I'm trying to point out that using the Zope Toolkit with an > existing release of Plone is risky. In general, I don't think we can > realistically support existing releases of complicated applications of > Plone with new releases of our libraries. Of course we try to stay > compatible, but you'd expect those applications to do some testing > before they can upgrade to the new versions in a new release. > > Anyway, if I'm correct, the argument in favor of Python 2.4 support in > the Zope Toolkit is as follows: > > * Plone is still on Python 2.4 and Zope 2.10 > > * Plone would like to use libraries like z3c.form 2.0 that already are > on the Zope Toolkit > > * in order to do this, Plone developers will tell users of > z3c.form-based code on Plone to replace vast amounts of libraries in > their Plone install with Zope Toolkit libraries. > > * the Plone developers will make sure that this works so that the Zope > Toolkit developers don't have to worry about it. We do expect some help. If we end up in a situation where people can not use Plone with more recent ZTK goodness, and they can't use ZTK without all the benefits of Plone we will loose them to non-zope systems. > * the Plone developers are asking not to drop Python 2.4 support in the > Zope Toolkit now because they want to do such a thing. > > The question now is whether this is realistic from the Plone > perspective. To some degree I consider it essential even. At the moment we are in a position were we have to deal with the fact that Plone runs on Zope 2.10 while we want to be able to use ZTK components in order to be productive and have a modern environment. Just like Hanno almost all my Plone projects over the last year have had to do this. Wichert. -- Wichert Akkerman It 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] Zope 2.12.0 beta 1 released
Previously Chris Withers wrote: > Hanno Schlichting wrote: > > Maybe: > > > > port deactivate subversion > > > > port install -f subvers...@1.5.6 > > I seem to remember on my Macs I just built from source. > > /me hates svn more and more as time goes on... The problem here is setuptools, not subversion. setuptools changes its behaviour based looking at internal datastructures for a specific source control system. You can't blame that on svn. Wichert. -- Wichert Akkerman It 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] dropping Python 2.4 support in the Zope Toolkit?
Previously Lennart Regebro wrote: > On Tue, May 5, 2009 at 13:27, Wichert Akkerman wrote: > > But you can use a lot of the Zope Toolkit with Zope 2.10, which is an > > enormous benefit. If that was not possible a lot of the things people > > want to do with Plone would not be possible. > > Let's be clear here: Do you mean that you need, in Plone, to use the > latest versions of many zope.* packages? No, I need to use some later versions of some packages than included in Zope 2.10 to be able to use things like z3c.form and dexterity. Wichert. -- Wichert Akkerman It 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] Publishing our company internal Zope extensions and fixes
Previously Andreas Jung wrote: > A subset of our changes landed on the current 2.12 trunk: > > http://svn.zope.org/Zope/trunk/doc/CHANGES.rst?rev=99866&r1=99853&r2=99866 > > Most of the stuff are bugfixes and minor improvements. The only major > new feature is the introduction of publication events. Can you document for the post-traversal-pre-publication event if that happens before or after validation? Wichert. -- Wichert Akkerman It 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] zope.container analysis
Previously Martijn Faassen wrote: > If we wanted to make zope.container agnostic about traversal and the > publisher, we'd need to move this code somewhere else. I cannot think of > an existing package for this (anyone?). Lacking that, I'd suggest a new > package, zope.containertraversing or something like that. It could be an extra ;) Wichert. -- Wichert Akkerman It 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] Mailinglist for Zope 2 bugs!?
Previously Sidnei da Silva wrote: > Now for another question: how do people feel about moving Zope 3 and > CMF bugs to a similar setup. That is, bug mail goes to a separate > mailing list instead of directly to everyone that's a member of the > teams in Launchpad. -0 I am happy with how CMF bugs are handled right now, so no reason to change a working system. Wichert. -- Wichert Akkerman It 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] zope.app.publication dependencies (volunteersneeded!)
Previously Shane Hathaway wrote: > Martijn Faassen wrote: > > It might actually be the best to move these ZCML directives *down* into > > zope.component. That won't affect the dependencies of zope.component at > > all in fact; the [zcml] dependencies of zope.component already need all > > the dependencies that zope.app.component's view and resource directives > > implement. > > I see that zope.component now relies fairly heavily on the setuptools > "extras_require", which makes the proposed move possible. At what point > did we decide extras_require is good? Just curious. I think it was grandfathered in. Wichert. -- Wichert Akkerman It 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] RFC: Site -> Locus
Previously Martijn Faassen wrote: > I propose we use the word 'Locus' instead of 'Site'. This word doesn't > have a lot of connotations in the web programming world, and people can > guess by simply looking at the word it might have something to do with > *local* components. It's also short. I don't see short as a very important quality here. It is not a name you have to type in often, so I would prefer something more descriptive. How about "componentroot" or "componentcontainer".. Wichert. -- Wichert Akkerman It 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] RFC: Site -> Locus
Previously Martijn Faassen wrote: > Wichert Akkerman wrote: > > Previously Martijn Faassen wrote: > >> I propose we use the word 'Locus' instead of 'Site'. This word doesn't > >> have a lot of connotations in the web programming world, and people can > >> guess by simply looking at the word it might have something to do with > >> *local* components. It's also short. > > > > I don't see short as a very important quality here. It is not a name you > > have to type in often, so I would prefer something more descriptive. How > > about "componentroot" or "componentcontainer".. > > I do find short an important quality here, because I find myself typing > "getSite()" frequently, and in tests, "setSite" as well. It's also > something one talks about. People also talk about www which is horrible to pronounce in English :) > A site isn't a container, I'll note. A site is something that has local > components registered but doesn't need to be implemented as a container > at all. A site contains component registraties and possible persistent components. That makes it a container to me. Perhaps componentRegistry works better for you? Wichert. -- Wichert Akkerman It 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] refactoring site functionality
Previously Martijn Faassen wrote: > * often it is nice to have application configuration to have a user > interface, so that end users can configure aspects of the application. > This may be filling in an email address or customizing a template or > adding a user, etc. Local utilities are a nice solution for this, even > if there is just a single application installed. That sounds like a complicated workaround for not having a mutable global configuration. Wichert. -- Wichert Akkerman It 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] HA storage for zope
Previously Miles Waller wrote: > Hi, > > I'm looking at a HA setup for a project, and was wondering what the current > best way forward would be. There seem to be a few potential options around > for the storage end of the setup, and I'm wondering what's now considered > the current "best practice" for this sort of setup. Specifically, I've come > up with three options: > > 1. RelStorage > Using this, I think I can then take care of replication/mirroring as I have > access to a database that is already clustered in a HA environment. My > questions are: > + Are the connections opened only when zope is started? Say I unplugged a > network cable and then plugged it back in again (breaking the database > connection) - will it be re-opened? > + How does RelStorage take care of the blob storage? > + Are there any details of big sites out there that use RelStorage > (particularly on Oracle)? The initial RelStorage development was sponsored by Jarn and Elkjøp for exactly that purpose: Elkjøp (a chain of Scandinavian electronics stores) uses an Oracle cluster for storage of all their Zope data. > 2. ZeoRAID > I could use ZeoRAID to write to maintain several independent storages > subject to stopping the ZeoRAID server being the single point of failure (I > posted some questions about this separately). If I remember correctly the ZeoRAID server is stateless, so you can use a standard redundant setup to remove the single point of failure. > 3. ZRS > If I'm right, ZRS still has a limitation in that there is a single server > for writes. Also, budget may be an issue. Having read the factsheet, I'm a > bit unsure as to how it is functionally different from ZeoRAID - can anyone > explain? >From what I hear ZRS is also fairly expensive, especially compared to the other two options which are free. Wichert. -- Wichert Akkerman It 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] refactoring site functionality
Previously Chris McDonough wrote: > On 6/4/09 11:59 AM, Martijn Faassen wrote: > > Wichert Akkerman wrote: > >> Previously Martijn Faassen wrote: > >>> * often it is nice to have application configuration to have a user > >>> interface, so that end users can configure aspects of the application. > >>> This may be filling in an email address or customizing a template or > >>> adding a user, etc. Local utilities are a nice solution for this, even > >>> if there is just a single application installed. > >> That sounds like a complicated workaround for not having a mutable > >> global configuration. > > > > I don't think it's complicated. It's nice to install an object somewhere > > that stores data and has a UI and also be able to register it as a local > > utility. If you were to have mutable global configuration, you'd need > > some way to expose it to the UI and content-space too. > > This is true. OTOH, I've never really been keen on the idea that the CA API > should be bent around the idea that you're going to often want to find a > persistent registry. It seems just as reasonable to: > > - put a persistent object someplace (with its own UI) that isn't registered as >a CA utility. > > - find it via the location API when you need it in your code. > > - *Pass* it to global utilities (or adapters) when you need to vary behavior >based on location. > > Maybe CMF tools weren't such a bad idea. For Plone we regret that we used persistent utilities to store configuration: they have made Plone instances much more fragile (removing a utiliy's implementation breaks the whole site) and forces you to write a UI for the stored configuration again and again. To move forwards we have come up with plone.registry (see http://pypi.python.org/pypi/plone.registry), which gives you a nice central storage system for configuration. Wichert. -- Wichert Akkerman It 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] Hg mirror available
On 6/19/09 6:28 AM, Balazs Ree wrote: > - afaik svn does _not_ show this, what's more, it does not store any > metadata about the merges or changesets involved. When doing the merge > you really select a diff of the branch by specifying which changesets you > want to include back in trunk. This is why it's so important with svn to > note in the commit message, which revisions from which branch you merged. > Otherwise you would not know at all what has been merged. Subversion 1.5 and later do store that data in a svn:mergeinfo property. Wichert. -- Wichert AkkermanIt 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] [action required] Zope Contributor Agreement change
On 6/19/09 2:25 PM, Jens Vagelpohl wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > This is a last reminder for those current contributors to the Zope > software repositories on svn.zope.org who have not sent in the new > contributor agreement as outlined below. Please do so before June 26, > otherwise your write access will be removed. Are you sending receipt confirmations? I submitted an updated agreement a while ago, but never got a response, so I am unsure at the moment if it was received or if I still need to take further action. Wichert. ___ 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] ZCatalog and indexes cleanup
On 6/29/09 12:48 PM, yuppie wrote: > Hi! > > > I did plan to work on a small catalog improvement, but after looking at > the code I'd like to do some cleanup first: > > > 1.) remove the deprecated TextIndex > > The deprecation warning says: > 'Using TextIndex is deprecated (will be removed in Zope' > '2.12). Use ZCTextIndex instead.' > > > 2.) remove CHANGES.txt, README.txt and version.txt from Products/ZCatalog > > These files seem to be obsolete. > > > 3.) remove security declarations from ZCTextIndex and DateRangeIndex > > All the other indexes don't have security declarations. AFAICS there is > no way to access indexes from untrusted code without having the 'Manage > ZCatalogIndex Entries' permission. > > > 4.) add 'indexSize' to IPluggableIndex and implement it where missing > > ZCatalog uses that method and most indexes implement it already. An API to both get and set 'extras' would be very useful for GenericSetup as well :) Wichert. ___ 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] How to test changes to ZTK packages?
On 6/30/09 7:03 PM, Stephan Richter wrote: > It is needed for the "latest-versions" script as this parses XML. I consider > lxml pretty much the standard tool to do XML in Python these days. Who is not > using lxml? I suspect the majority of people who use OSX as their main platform try to stay as far away from lxml as possible. Not because lxml is bad, but because unless you use special magic it will make your python randomly segfault. This is very sad, and it is not lxml's fault but I see no good solution at this moment. Using z3c.recipe.staticlxml recipe helps a bit for people using buildout, but that is not everyone and even then I have seen random segfaults. Wichert. ___ 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: mkzopeinstance, runzope and zopectl - a small proposal
On 7/23/09 12:10 PM, yuppie wrote: > Hi! > > > SOFTWARE_HOME no longer exist in Zope 2.12, all the software is now > somewhere on sys.path. > > So this no longer works in zopectl: > > ZDCTL="$SOFTWARE_HOME/Zope2/Startup/zopectl.py" > exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@" > > Therefore mkzopeinstance now creates something like this: > > ZDCTL="/path/to/eggs/Zope2-2.12.0b3-py2.5-linux-i686.egg/Zope2/Startup/zopectl.py" > exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@" > > > Problem: > > > - the code in mkzopeinstance.py that looks up the Zope2 path fails on > some platforms > > - if the software is updated, you have to change the paths in runzope > and zopectl of each instance > > > Solution: > - > > 1.) Add two new entry points in setup.py: > > runzope=Zope2.Startup.run:run > zopectl=Zope2.Startup.zopectl:run > > If the software is installed, executable runzope and zopectl files are > created in the bin directory. That should work with zc.buildout and with > easy_install. > > 2.) Modify the runzope and zopectl files created by mkzopeinstance: > > The result should look like this: > > ZDCTL="/path/to/install/bin/zopectl" > exec "$ZDCTL" -C "$CONFIG_FILE" "$@" > > mkzopeinstance would make the assumption that executable runzope and > zopectl files exist in the same directory as mkzopeinstance itself. > > > Risks: > -- > > - mkzopeinstance has a --python option. The specified Python interpreter > will no longer be used to execute runzope or zopectl. > > - uses cases might exist that no longer work after that change > > > > Any thoughts? Is the 2.12 branch still open for changes like that? +1 Wichert. ___ 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] List of packages in the ZTK
On 8/6/09 11:35 , Fabio Tranchitella wrote: > I propose a (very) simple policy, which we can use to improve the current > situation: > > * a package is part of the ZTK if the following criteria are met: > > - It has at least N zope developers (with commit rights) who > explicitly expressed interest in maintaining the package (because they > use it in their projects, for example); N> 1, at least; > > - All its dependencies (excluding testing dependencies) are part of the > ZTK; > > * we have to ensure, using automated testing, that each package: > > - has no test failures; > > - does not introduce test failures in any of the other ZTK packages; > > * the ZTK KGS only includes the packages that are part of the ZTK; we will > provide an extended KGS (which uses the ZTK KGS) with more packages if > needed. How about another one: * the package has to be usable with all of Zope 2, grok and the Zope 3 application server That guarantees the stated goal that ZTK is reusable. Wichert. ___ 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] List of packages in the ZTK
On 8/6/09 17:44 , Fred Drake wrote: > 2009/8/6 Fabio Tranchitella: >> Am I correct saying that your idea is to restrict the ZTK to the packages >> defined as the intersection of the dependencies of zope2, zope3 and grok? >> >> ZTK = intersection ( zope2-dependencies , zope3-dependencies, grok ) > > That's my understanding of what Tres wrote. > >> I don't think this definition fits our needs, but my skills on gron and >> zope2 are too limited to bring counterexamples. > > This, however, is more readily achievable, and provides a good > foundation for each of the other projects mentioned to build from. > > This sounds like the right starting point to me. +1 Wichert. ___ 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] Subversion externals versus mirroring
On 2009-9-9 14:54, Hanno Schlichting wrote: > On Wed, Sep 9, 2009 at 2:40 PM, Martijn Faassen > wrote: >> Christian Theune wrote: >>> However, this requires Subversion 1.5 which we are using on the server >>> already, but I don't know whether we assume clients are 1.5 or higher. >> >> I certainly still use a SVN 1.4.x client, being on Ubuntu 8.04 LTS >> (released just last year). I don't think SVN 1.5 is common enough yet to >> make such a move possible. > > We moved all the Plone repositories (including the rather massively > used collective) to Subversion 1.5.6 a while ago. So far there have > been no complaints by anyone. And as Robert noted you can use a > Subversion 1.4 client with a 1.5 server just fine. > > I think doing the server upgrade very soon (tm) shouldn't be a problem. Relative externals are handled on the svn client, not the svn server. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] how do I only run test from one doctest .txt file?
On 9/10/09 11:40 , Chris Withers wrote: > Hi All, > > I'm doing some development of zc.buildout, and I'm down to a couple of > test failures. The test suite takes quite a long time to run. > > Using zc.recipe.testrunner, how can I limt the run to just one file? > > eg: > File "...src/zc/buildout/bootstrap.txt", line 23, in bootstrap.txt > > How do I just run the tests in bootstrap.txt? With Zope2 you can do this: bin/instance test -t bootstrap.txt Perhaps -t works here as well? Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Needed: zc.recipe.cmmi release
The latest zc.recipe.cmmi release started using the zc.buildout download API but does not depend on zc.buildout 1.4 or later, which broke several buildouts for me. I've fixed the dependency in r103703. Can someone make a new release? Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] broken zope.schema dependency in z3c.form 2.1.0
z3c.form uses zope.schema.interfaces.IDecimal, which is not present in early versions of zope.schema as used by Zope 2.10. As far as I can tell z3c.form must have a versioned dependency on zope.schema >= 3.3.0. Regards, Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On 2009-9-10 22:23, Benji York wrote: > On Thu, Sep 10, 2009 at 4:12 PM, Hanno Schlichting wrote: >> On Thu, Sep 10, 2009 at 9:46 PM, Alex Chapman wrote: >>> Log message for revision 103721: >>> keep trunk version at 0. Update changes >> >> I think I've seen the practice of denoting the version on trunk as >> "zero" from Jim already. >> >> It is in conflict with >> http://docs.zope.org/zopetoolkit/process/releasing-software.html >> though. >> >> The majority of packages still uses the "version='3.4.2dev'" scheme >> for trunk or branches. Pointing to the next release to be made with a >> dev marker. >> >> Are there any particular reasons, why this policy should be changed? > > I like "0" for two reasons: > > 1) it doesn't require predicting what the next release will be, > > 2) if you accidentally make a trunk release no one will accedentally use it > because it will be the "oldest" release on PyPI instead of the newest, Doesn't it break all versioned dependencies on that package? Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On 2009-9-10 23:24, Benji York wrote: > On Thu, Sep 10, 2009 at 5:20 PM, Wichert Akkerman wrote: >> On 2009-9-10 22:23, Benji York wrote: >>> 2) if you accidentally make a trunk release no one will accedentally use >>> it >>> because it will be the "oldest" release on PyPI instead of the newest, >> >> Doesn't it break all versioned dependencies on that package? > > I don't understand the question, so I'll say "no". ;) Suppose you are working on an app which includes a package that depends on A >= 2.1 to make sure it can use a new API introduced in A 2.1. If you then add a develop egg for A to do some work on it things break with this policy because it will have version 0 and can no longer satisfy the >= 2.1 requirement. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
On 9/15/09 10:33 , Reinout van Rees wrote: > On 2009-09-11, Sebastien Douche wrote: >> >> Caution with the actual workflow, 2 differences between SVN and Hg : >> - you cannot check out partial repository >> - external does not exist > > Missing externals has been a pain point for me. > > There are however buildout recipes that can pull in "externals" for you from > buildout. infrae.subversion does it (and can turn the downloaded stuff into a > development egg at the same time), Balasz Ree has a bzr recipe. I'm betting > there's a mercurial one, also (and otherwise I'll build one if needed) :-) And mr.developer can handle them all. This only solves the problem partially though: most of my projects use svn externals to pull in CSS, javascript and other resources from an external prototype. That is not supported by those zc.buildout recipes: they can only checkout a whole package. In my experience distributed SCMs add bottlenecks to development that we currently do not have in the Zope community: with both our shared svn repository and distributed SCMs everyone can branch everything, but with distributed SCMs you have to ask a maintainer to merge any changes, something everyone can do directly right now. For that reason I am still -1 on switching to git/bzr/hg/etc. Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
On 9/15/09 13:56 , Gary Poster wrote: > > On Sep 15, 2009, at 4:56 AM, Wichert Akkerman wrote: >> >> In my experience distributed SCMs add bottlenecks to development that we >> currently do not have in the Zope community: with both our shared svn >> repository and distributed SCMs everyone can branch everything, but with >> distributed SCMs you have to ask a maintainer to merge any changes, >> something everyone can do directly right now. > > FWIW, this is some variable degree of wrong. > > 1) "Everyone" cannot merge changes right now: only developers that have > commit privileges can do that. That's what you meant, I expect. Indeed. > 2) Our current arrangement, as well as many others, can be accomplished > with a DVCS. Launchpad + Bzr definitely support this. You would have a > Launchpad team of committers, with managed membership; and have the > official branches owned and controlled by this team. Indeed, but most people do not do that. With our current setup once you get commit privileges you immediately have access to an entire world of things. With DVCS hosting systems that people use you have would have to request access for every single package. That is cumbersome and adds a lot of delay so people don't do that and fork instead. The end result is a lot more forks, half of which will probably never be merged back or seen by others. Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Apache rewrite - HTTP_Host redirect issue
On 2009-9-16 01:15, Roger Ineichen wrote:
> Hi Dan
>
> I have an issue with the latest changes in
> zope.publisher.http.py
>
> The redirect method in HTTPResponse http.py line: 880
> forces a ValueError. Because the Apache HTTP_HOST
> and the target_host to not compare.
>
> def redirect(self, location, status=None, trusted=False):
> location = str(location)
> if not trusted:
> scheme, target_host, path, query, fragment = (
> urlparse.urlsplit(location))
> if target_host and target_host != self._request.get('HTTP_HOST'):
> raise ValueError(
> "Untrusted redirect to host %r not allowed." % target_host)
>
> Apache uses in HTTP_HOST like expected
> and the method used with urlparse.urlsplit(location)
> returns as target_host value.
I suspect Apache does use DOMAIN:PORT if the port is a non-standard
port, ie http over anything other than port 80 or https over something
other than port 443.
Wichert.
--
Wichert AkkermanIt is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: Determining packages which are in the ZTK
On 2009-9-21 17:19, Martijn Faassen wrote: > Hey, > > Generally I believe that these rules if strictly applied wouldn't result > in a usable ZTK. Hanno already mentions the testing dependencies, which > we've barely started analyzing. Documentation in 'docs' would disqualify > just about any package (and Reinout brings up a few objections). > > A number of thoughts: > > * even without radically pruning the ZTK particular subsets of the ZTK > are becoming a lot more useful than when we started, due the dependency > refactoring. This refactoring is ongoing. > > * we need some stability for those apps that already are built on top of > Zope 3. These will still be using zope.app* packages for some time. > Right now we can test lots of breakages of zope.app* packages by using > the ZTK compattests. If we removed them from the ZTK soon, we'd need an > equivalent testing infrastructure for an expanded ZTK, and management > policy will be harder. > > I think we could translate these rules from "not be part of the ZTK" to > goals for the ZTK packages: > > - we should aim for ZTK packages to be used by Zope 3 apps, Zope 2 and > Grok. The code in the ZTK should be *used*. > > - ZTK packages should have narrative documentation. We should actively > work to create such narrative documentation. How do you define narrative documentation? Do you consider z3c.form to have narrative documentation for example? Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.password
On 2009-9-22 18:59, Daniel Holth wrote: > At least on Python 2.6, SSHAPasswordManager().checkPassword(hash, > password) fails if hash is unicode, which it always is if stored in some > databases. SSHAPasswordManager should encode the hash to utf-8 before > trying to un-base64. Isn't that a bug in those databases. The hash is not a unicode string but a bytestring. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.password
On 2009-9-23 13:29, Daniel Holth wrote:
> sqlite for example will always return strings as unicode strings, or
> it will always return strings as byte strings. It doesn't know how to
> return the username colum as one kind of string and the hash column as
> another kind of string.
SQLite is an extremely minimal database. This is just one of the
situations where you need to massage its output. If you use SQLAlchemy
on top of SQLite this will work properly.
> I think this is really a bug in the urlsafe base64 module. This works:
> unicode(u"foobar".encode('base64')).decode('base64')
That generates something entirely differently than standard SSHA1
implementations, which will break interop.
Wichert.
--
Wichert AkkermanIt is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.site.hooks
On 10/12/09 01:22 , Fabio Tranchitella wrote: > Hello, > > * 2009-10-09 15:37, Martijn Faassen wrote: >> I'm okay with *not* doing the split up and going with your idea, but I >> think eventually such a split up would simplify things. One advantage >> would be that someone could examine repoze.zcml and not see distracting >> ZCML implementations in zope.component *too*. > > I may be wrong, but I suppose the dependency on zope.security in > zope.component is the only reason why repoze.zcml is around. Perhaps it is an idea to make zope.component an extension for repoze.zcml? repoze.zcml already exists and works well, and people who want the extra zope magic can keep using zope.component. I suspect that is less work than trying to split up zope.component. Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] proposal: Custom schema properties
On 10/25/09 15:08 , Adam GROSZER wrote: > Hello, > > Custom schema properties proposal > = > > The problem > > is that we have a "baseline" project. This baseline project gets > customized for each client. Each client has different (usually just a > little bit) needs in terms of field titles and field required. > > The real problem is, to achieve this we have to create a new interface > with the overridden field. This starts the domino effect, we have to > create a new class, this new class needs to be instantiated, new add > form, new edit form and register those. A hell lot of code to support > that tiny change. Doesn't http://pypi.python.org/pypi/plone.behavior provide exactly that feature? I'm pretty sure we can get that BSD licensed if it's helpful. WIchert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Relative path support for z3c.recipe.paster?
On 11/5/09 14:18 , Jonathan Ballet wrote: > Hi Adam, > > On Wed, Nov 4, 2009 at 7:11 PM, Adam GROSZER wrote: >> Hello Jonathan, >> >> bin/buildout -N does not fit you? > > In fact, we have very strong constraints where our buildout's results > are ran : most of our customers deploy this package on host which > don't have freely access to outside. Running "bin/buildout -N" is out > of the question since this will certainly fail. Maybe "bin/buildout > -o" could work for us. Isn't zc.sourcerelease is designed for exactly those types of situations? Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] make zope.component.registry.Components inherit from dict?
On 2009-11-24 05:57, Martin Aspeli wrote: > I whole-heartedly agree, and I think it's important that we use the > momentum behind BFG (and other consumers of the ZTK) to drive the ZTK > forward. Anything else would be stupid. I don't think BFG can be considered to be a 'consumer of the ZTK'. It uses the ZCA (and zope.i18n currently), but that's about it. The ZTK as it currently is implies a whole lot of Zopisms that BFG does not subscribe to. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] make zope.component.registry.Components inherit from dict?
On 2009-11-24 17:26, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Wichert Akkerman wrote: >> On 2009-11-24 05:57, Martin Aspeli wrote: >>> I whole-heartedly agree, and I think it's important that we use the >>> momentum behind BFG (and other consumers of the ZTK) to drive the ZTK >>> forward. Anything else would be stupid. >> >> I don't think BFG can be considered to be a 'consumer of the ZTK'. It >> uses the ZCA (and zope.i18n currently), but that's about it. The ZTK as >> it currently is implies a whole lot of Zopisms that BFG does not >> subscribe to. > > BFG uses the "under the bicycle seat" subset of the toolkit. ;) Doesn't that hurt? ;) Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Releasing zope.browserresource
On 2009-11-26 08:43, Michael Howitz wrote: > Am 25.11.2009 um 15:49 schrieb Chris Withers: > [...] >> Yes, PyPI is broken if you're an admin of many packages, feel free to >> "me too" on this issue: >> >> http://sourceforge.net/tracker/?func=detail&aid=2793544&group_id=66150&atid=513503 > > It's fixed since yesterday. That's not a fix, it just replaced one problem with another one: it is now impossible to get your full list of packages. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On 11/30/09 13:43 , Hanno Schlichting wrote: > On Mon, Nov 30, 2009 at 1:21 PM, Martin Aspeli > wrote: >> Martijn Faassen wrote: >>> This implies we don't want to release zope.component 4.0 for a long time >>> yet. >> >> I think the answer should be "never". :) > > I think never is a rather long time. I'd suggest we think about these > changes more in the timeline of years. > > Looking at Python itself or Zope's own former deprecation policies, it > seems that policies where we deprecate / warn about API changes in one > release and change behavior it one or two releases after that seem to > work. They do rely on their being something like a coherent release of > some language / framework / toolkit though. And they rely on these > releases being made at an interval of at minimum a year or preferably > 18 months (as in Python's case). > > I think that once we get a ZTK 1.0 release out that promises to be > maintained for at least three years, we can start working on a ZTK 2.0 > which introduces deprecation warnings about the changed behavior and a > 3.0 that will change the default. If released at an interval of 18 > months like Python, that puts these changes about 3 years into the > future with a lot of time in between to adjust. We could also say that we will clean up the API when we move to Python 3. That is a natural breaking point anyway, so it will not any extra pain for users of the ZCA. Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On 11/30/09 14:45 , Hanno Schlichting wrote: > On Mon, Nov 30, 2009 at 2:39 PM, Wichert Akkerman wrote: >> We could also say that we will clean up the API when we move to Python >> 3. That is a natural breaking point anyway, so it will not any extra >> pain for users of the ZCA. > > Except that is precisely what the Python developers have asked > everyone not to do. So far the story is that the upgrade to Python 3 > can be done largely automatic and a codebase for 2.x and 3.x can be > maintained automatically and kept in sync. In theory. I am convinced that in practice you well end up with code that is un-pretty in both python 2.x and 3.x, and harder to debug. Python 3 also introduces changes that warrant API changes, so not making them could lead to awkward APIs. Personally I will take the liberty to change the API of any of my packages if and when I port them to Python 3. Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.testrunner.debug.post_mortem and try/finally
On 2009-12-2 23:06, Marius Gedminas wrote: > On Wed, Dec 02, 2009 at 01:36:37PM -0500, Benji York wrote: >> Here's another idea: a testrunner option that takes a file name and line >> number and inserts a breakpoint at that position. That way you can get >> the same effect as editing the code without actually having to do so. > > Is that possible? I once spent hours studying pdb docs and found no way > to set a breakpoint in advance, without modifying the source file in > question, and without having the user to do manual interaction at the > beginning. I think mr.freeze (see http://pypi.python.org/pypi/mr.freeze ) can do this. Perhaps there is some code there you could borrow. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Tests: 4 OK, 2 Unknown
On 12/6/09 02:45 , Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Zope Tests Summarizer wrote: >> Summary of messages to the zope-tests list. >> Period Fri Dec 4 12:00:00 2009 UTC to Sat Dec 5 12:00:00 2009 UTC. >> There were 6 messages: 6 from Zope Tests. >> >> >> Unknown >> --- >> >> Subject: UNKNOWN : Zope-2.12 Python-2.6.4 : Linux >> From: Zope Tests >> Date: Fri Dec 4 20:48:07 EST 2009 >> URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013139.html >> >> Subject: UNKNOWN : Zope-2.12-alltests Python-2.6.4 : Linux >> From: Zope Tests >> Date: Fri Dec 4 20:50:07 EST 2009 >> URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013140.html > > These failures are both due to the following: > > Getting distribution for 'zc.buildout==1.4.1'. >Error: Couldn't find a distribution for 'zc.buildout==1.4.1'. > > Has somebody been doing nasty stuff like removing releases on PyPI? zc.buildout 1.4.1 is still on http://pypi.python.org/simple/zc.buildout Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Generations in Zope 2
On 12/15/09 11:02 , Christian Zagrodnick wrote: > Hi, > > to get generations working in Zope 2 the following subscriber is needed: > > @zope.component.adapter(zope.app.appsetup.IProcessStartingEvent) > def evolve_minimum(event): > zope.app.generations.generations.evolve( > Zope2.DB, zope.app.generations.generations.EVOLVEMINIMUM) > > > I think should become part of Zope 2 / Five. Objections? -1, this would add a needless dependency on zope.app.generations to Zope 2 as far as I can see. Why not move include this in zope.app.generations itself in a [zope2] extra ? Or create a tiny five.generations package to do this. Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
