Re: [Zope-dev] Forcing buildout to download sdist packages only
On Thu, May 30, 2013 at 1:26 PM, Andreas Jung li...@zopyx.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I have a buildout where I am using the 'pyamp' module. https://pypi.python.org/pypi/pyamp zc.buildout on my Raspberry PI tries to download and install the binary release package for Linux. Fair enough, (as I assume you run Linux on it) but the only binary release is for i686 Linux, and that's wrong, since it's an ARM. This must be a bug somewhere. //Lennart ___ 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] ZCA for javascript
On Wed, May 22, 2013 at 1:52 AM, Christopher Lozinski lozin...@freerecruiting.com wrote: ZCA is very interesting stuff. I got a call today from a client who wants to do an extensible application in Javacript. I instantly thought, we could do ZCA in Javascript. And while not many people likes ZODB servers, they all love Javascript clients. Has anyone done something like this? Is anyone interested in doing something like this? What do you think Although I'm sure it is possible to make a generic component architecture in Javascript I highly doubt that it makes sense. JS is almost all about UI and DOM manipulation, and having something as abstract as a generic component framework for that may be an abstraction too far. So what you want is a framework for making modular JS clients. And there are tons and tons of modular frameworks for making front-end apps in Javascript already. Creating another one probably doesn't make any sense, at least not until you can explain exactly why you can't use anyone of those that exist. //Lennart ___ 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] Success at porting ZTK to Python 3!
On Mon, Apr 8, 2013 at 4:36 PM, Albertas Agejevas a...@pov.lt wrote: Subject: Success at porting ZTK app to Python 3! Awesome! ___ 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] ZTK 2.0: Deprecate zope.sequencesort
On Fri, Mar 1, 2013 at 4:04 AM, Tres Seaver tsea...@palladion.com wrote: Assuming an unsorted list of news stories, how would you use sorted to get them ordered by category (ascending) + publication date (descending)? This is the easiest, most obvious way: sorted(sorted(news_stories, lambda x: x.publication_date, reverse=True), lambda x: x.category) And yes, I have made performance analysis, and it is often faster two do two sorts than trying to compute a complex key. If you spend more than a minute on it (e.g., trying to come up with a bug-free way to compute negative dates) you've proved my mpoint. :) I haven't got a clue what negative dates are, unless you mean BC. But the above works (unless I got ascending and descending mixed up as usual). //Lennart ___ 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] ZTK 2.0: Deprecate zope.sequencesort
I'm sorry, it's early in the morning. It is of course: sorted(sorted(news_stories, key=lambda x: x.publication_date, reverse=True), key=lambda x: x.category) I forgot the key= bit. ___ 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] ZTK 2.0: Deprecate zope.sequencesort
On Fri, Mar 1, 2013 at 7:06 PM, Suresh V. suresh...@yahoo.com wrote: On Friday 01 March 2013 02:15 PM, Lennart Regebro wrote: I'm sorry, it's early in the morning. It is of course: sorted(sorted(news_stories, key=lambda x: x.publication_date, reverse=True), key=lambda x: x.category) Won't the two sorteds step over each other? Nope. Timsort is a stable sort, so you get a list that is sorted first by category and then by publication_date. //Lennart ___ 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] ZTK 2.0: Deprecate zope.sequencesort
On Thu, Feb 28, 2013 at 3:00 PM, Wichert Akkerman wich...@wiggy.net wrote: On Feb 28, 2013, at 14:43 , Stephan Richter stephan.rich...@gmail.com wrote: Hi everyone, I would like to deprecate zope.sequencesort in ZTK 2.0, since it cannot properly ported to Python 3, since it depends heavily on the cmp() way of sorting. I am also not a user of the package and I only tried to port the package for completeness sake. What does it do? I could not find a single line of documentation for it, which makes it likely very few people, if any, are using it. Reading through the code, it seems to use a lot of code to provide quite basic sorting functionality. It feels like it's trying to fill the same role as sorted() does since Python 2.4. //Lennart ___ 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] ZTK 2.0: Deprecate zope.sequencesort
On Thu, Feb 28, 2013 at 5:33 PM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/28/2013 10:41 AM, Lennart Regebro wrote: Reading through the code, it seems to use a lot of code to provide quite basic sorting functionality. It feels like it's trying to fill the same role as sorted() does since Python 2.4. The other features (locale-aware sorting, sort different keys using different algorithms / directions) are not easy to emulate using 'sorted()' Locale aware sorting can be tricky, I'll have to look at that code again. Sorting different keys and directions are trivial with sorted(). I'm not sure what different algorithms mean, with sorted you implement a function that returns a sorting key, that sorting key is then used to sort. It should be possible to sort according to any algorithm that way. //Lennart ___ 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] ZTK 2.0 process
On Tue, Feb 26, 2013 at 4:45 PM, Stephan Richter stephan.rich...@gmail.com wrote: Hi everyone, We are about 5-6 packages away from porting ZTK to Python 3 That's awesome! //Lennart ___ 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] Porting zope.tal to Python 3
On Mon, Feb 11, 2013 at 7:44 PM, Marius Gedminas mar...@gedmin.as wrote: - Running 2to3 on your sources is a good way to identify places that need changing, but you'll have to revert most of the actual changes to keep it compatible with Python 2. I've find the easiest way to keep compatibility to port to Python 3 first, and then reintroduce compatibility with first Python 2.7, and then 2.6. Python-modernize might change that. //Lennart ___ 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] javascript in zope
On Fri, Feb 8, 2013 at 9:25 AM, murat bilal murat.bi...@gmail.com wrote: Can anybody help how to execute javascript code on DTML method like It's a bit unclear what you are trying to do. But you can not call DTML methods from Javascript, if that's what you want. //Lennart ___ 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] Python 3 support status page
On Tue, Jan 29, 2013 at 1:59 PM, Marius Gedminas mar...@gedmin.as wrote: On Mon, Jan 28, 2013 at 10:41:59PM +0100, Lennart Regebro wrote: On Mon, Jan 28, 2013 at 6:27 PM, Marius Gedminas mar...@gedmin.as wrote: I wanted to have an up-to-date status page for the status of the Python 3 porting efforts of various zope-ish packages, so I made one: http://zope3.pov.lt/py3/ Awesome. But do we have to call it Zope3? :-) What should I call it, BlueBream? ZTK? Just Zope? Hmm, Zope, in the sense of all packages maintained under the aegis of the Zope Foundation, seems reasonable, as long as people won't assume the page was about Zope2. The Pyramid folks have a Pylons Project, which will develop a collection of related technologies [r]ather than focusing on a single web framework. Sounds familiar. Should there be a Zope Project, to encompass Zope 2, Zope 3/BlueBream, ZTK, Grok, and everything else? In other news, experts discuss the best color for bike sheds. Stay tuned. Yeah, ZTK, Zope or Zope Project all work. //Lennart ___ 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] Python 3 support status page
On Mon, Jan 28, 2013 at 6:27 PM, Marius Gedminas mar...@gedmin.as wrote: I wanted to have an up-to-date status page for the status of the Python 3 porting efforts of various zope-ish packages, so I made one: http://zope3.pov.lt/py3/ Awesome. But do we have to call it Zope3? :-) //Lennart ___ 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] [ZODB-Dev] Progress report: porting persistent, BTrees to Python3
On Mon, Dec 17, 2012 at 10:05 AM, Chris McDonough chr...@plope.com wrote: On Sun, 2012-12-16 at 22:10 +0100, Godefroid Chapelle wrote: Le 15/12/12 01:52, Tres Seaver a écrit : I fixed the remainig issues in persistent and released 4.0.5 today: its tests properly exercise the C extensions Under Python 3.2 / 3.3. I want to express my thanks to you, Tres, for taking care of that work ! This port of ZODB to Python 3 is really a crucial step for the ZTK ecosystem. After the work already done on zope.interface and zope.component. Further, I'd like to also thank Jim for his work on porting buildout. When this will be finished, porting the rest of the ZTK should be much easier, which hopefully implies that more of us will be able to participate. Hear, hear! +lots ___ 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] [ZODB-Dev] [announce] NEO 1.0 - scalable and redundant storage for ZODB
On Mon, Aug 27, 2012 at 2:37 PM, Vincent Pelletier vinc...@nexedi.com wrote: Hi, We've just tagged the 1.0 NEO release. NEO aims at being a replacement for use-cases where ZEO is used, but with better scalability (by allowing data of a single database to be distributed over several machines, and by removing database-level locking), with failure resilience (by mirroring database content among machines). Under the hood, it relies on simple features of SQL databases (safe on-disk data structure, efficient memory usage, efficient indexes). That sounds pretty cool! ___ 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] We need to change how code ownership works.
On Sun, Aug 19, 2012 at 1:38 PM, Hanno Schlichting ha...@hannosch.eu wrote: The Plone Foundation adopted a policy for this, see http://plone.org/foundation/materials/foundation-resolutions/patch-policy-052011 As we don't have any terms of service stating so for any of our issue trackers, we don't get any copyright assignments for reported bugs or proposed patches. Patches can be sent we private email, posted to bug trackers, on paste.org like services or sent via pull requests. All of those are legally the same and it's the responsibility of the person doing the checkin to validate the copyright situation. That said a lot of patches don't actually contain any creative work that falls under the copyright rules. This last point is the reason most projects aren't very strict about this issue. I Am Not A Lawyer, but this sounds reasonable, and if it's good enough for the Plone foundation, it's good enough for me. :-) //Lennart ___ 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] We need to change how code ownership works.
On Mon, Aug 20, 2012 at 9:07 AM, Jens Vagelpohl j...@dataflake.org wrote: Maintaining the chain of custody doesn't just consist of selecting pull requests or patches coming from somewhere. It also means verifying the contributor - be it the one who is creating the patch or pull request or the one who is merging new code into the repository - is who he claims to be. In the current setup the verification of the merging contributor is done using unique SSH logins with keys for every contributor, which works very well. Once again I have to say that I think it's beyond any reasonable doubt that whoever is using a github account is the owner of that account. Somebody could steal an SSH key as well. I'm pretty sure that the claim I know it says that Jens did the checkin, but in fact it was me, I had stolen his account, so therefore I own the copyright is hardly a claim that will hold up in a court of law. - Read access for everyone including anonymous viewers Github: Check. - Write access for signed contributors only Github: Check. - Signed contributors must be able to create new repositories themselves (current analogy: A contributor adds a new project on svn.zope.org) Github: Check. - Good verification that a login to the chosen system represents a specific person/contributor (current example: access via unique SSH logins with keys) Github: Check. - Only ZF-appointed contributor admins may open access for contributors after receiving and verifying signed contributor agreements (currently Andreas Jung as officially appointed contributor committee member and Christian Theune as board member and contributor committee member handle this job) Github: I don't know. I took the liberty of adding you to one of my repos as collaborator, but I didn't find any way to change your privileges so that you also could add collaborators, so someone else have to answer that more closely. (I removed you as a collaborator again, but just FYI: If anyone wants write access to my github repos you'll probably get it. :-) ) - Only ZF-appointed contributor admins (see above) may change or revoke access privileges for contributors Same thing, no? - a reasonably convenient web view onto the repositories/projects for visitors and contributors Github: Check - a reasonably convenient way (e.g. web admin capabilities) for the ZF contributor adminstration to do their job Github: Check The discussion is not github or nothing, but almost. Github makes open source easier. I got angry when Plone moved to github with basically no discussion, but there is no doubt that it was the right decision. //Lennart ___ 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] We need to change how code ownership works.
On Mon, Aug 20, 2012 at 9:19 AM, Lennart Regebro rege...@gmail.com wrote: Github: I don't know. I took the liberty of adding you to one of my repos as collaborator, but I didn't find any way to change your privileges so that you also could add collaborators, so someone else have to answer that more closely. (I removed you as a collaborator again, but just FYI: If anyone wants write access to my github repos you'll probably get it. :-) ) And I just realized that this test was completely pointless, as I was testing on repositories, but what we are takling about is Organizations like https://github.com/collective and https://github.com/plone. I'm 99% sure that Github fulfills the requirements here as well. I for example, have write access to the repos in the Collective, I can create new repos, but I do not have admin rights, showing that there is separation between collaborators and admins, and that therefore only Andreas and Christian could be made admins, fulfilling the requirement here as well. Hence I'm 99.8% sure that Github fulfills all the requirements, and that we can move development of various parts to Github with no problem. The patch/merge problem exists as of today, with or without Github, and needs to be fixed in any case. The Plone patch policy is one option there. //Lennart ___ 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] We need to change how code ownership works.
On Mon, Aug 20, 2012 at 10:28 AM, j...@nexedi.com wrote: This approach protects from: - legal risks posed by github Such as? - instabilities due to ever changing fashion in code hosting (sourceforce then google code then bitbucket then github then etc.) Sure. At the cost of a lot of extra complexity, that is. - destruction, traceability or security issues posed by cloud infrastructure not controlled by ZF (logs, bugs, forums, not only code) What would these be. This approach enforces: - freedom for fashion victims to follow latest fashions Making it easy to contribute is not a fashion but a fundamental part of how good open source works. //Lennart ___ 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] We need to change how code ownership works.
On Mon, Aug 20, 2012 at 11:58 AM, Leonardo Rochael Almeida leoroch...@gmail.com wrote: Hi, On Mon, Aug 20, 2012 at 11:09 AM, Lennart Regebro rege...@gmail.com wrote: On Mon, Aug 20, 2012 at 10:28 AM, j...@nexedi.com wrote: This approach protects from: - legal risks posed by github Such as? I'll let Jean-Paul elaborate, but I suppose it could be something along the lines of GitHub suddenly disappearing with (some of) your content (code, forum posts, metadata like group associations) We need backups, yes. making some other unwanted use of it, and you having no legal recourse because of some small print in some EULA somewhere that someone didn't bother to fully read. I have absolutely no idea what kind of legal but unwanted use that could be, except spamming email addresses of course. The point is not that these can't happen to ZF repos, but that ZF would have no recourse to fix the issue except to wait on GitHub to act on it. OK, that's the first good argument I have heard. //Lennart ___ 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] We need to change how code ownership works.
On Mon, Aug 20, 2012 at 12:39 PM, Charlie Clark charlie.cl...@clark-consulting.eu wrote: https://github.com/popular/starred i doubt that github i willing to get into the doghouse by doing really nasty things - and thus getting into risk of loosing projects. This is pure speculation, or are you privy to board decisions at Github. Yet again, I point out that the nastiest thing they legally can do is spamming your email address. I raised a specific objection: that the onus is on anyone with a Github account to demonstrate their code does not violate any patents in the case of a claim feels like a pretty real threat to me. If you are on Github or not makes no difference. Github has that clause to protect themselves if somebody else hosts copyright or patent protected code. It means, should Zope violate any patents and Github get sued because of this, the Zope Foundation needs to pay any damages. If we host it ourself, the *we* get sued, and need to pay the damages anyway. Hence Github or no Github yet again makes little, if any, difference. Again, as Jens has repeatedly said we should not conflate the separate items of toolchain and service provider. Zope Foundation has hardware and a proven track record in hosting. Is anyone actually criticising this? This is not about git vs svn. It's about using external services, with all the benefits this gets us, or not. And the arguments against are so far mostly because of perceived legal problems with using an external service. Problems that in fact either don't exist, or are just as severe with self-hosting of the code. //Lennart ___ 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: zc.buildout/ Moved to github
On Sun, Aug 19, 2012 at 8:49 AM, Jens Vagelpohl j...@dataflake.org wrote: On Aug 18, 2012, at 21:46 , Lennart Regebro rege...@gmail.com wrote: Yes, but my question is why this changes with github. GitHub is a third party infrastructure run by other people. I cannot ascertain how well it enforces our requirement that all checkins must be from signed contributors only. I have to say that I find it to be without any reasonable doubt without question that you can only wrote to a repository if you have write access. Questioning this is to me somewhat surprising, and we might as well claim that we can't ascertain how well the current SVN server enforces our requirements, as we don't know what undiscovered security holes it might have. Furthermore, I cannot ascertain that private contributor data remains private (email addresses etc). Is this really a requirement? Why is this a requirement? All you need to enter at github is an email (which in practice is all we can verify in ZF as well, as all communication is by email). Why does this email address have to remain private? And since it becomes ever easier to accept code from unknown sources (e.g. pull requests) legal code ownership becomes an issue again. And that returns me to my first question: Is it really legally different for a contributor to accept a pull request from a non-contributor compared with a contributor merging a patch from a non-contributor? //Lennart ___ 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] We need to change how code ownership works.
On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl j...@dataflake.org wrote: On Aug 19, 2012, at 10:17 , Lennart Regebro rege...@gmail.com wrote: And since it becomes ever easier to accept code from unknown sources (e.g. pull requests) legal code ownership becomes an issue again. And that returns me to my first question: Is it really legally different for a contributor to accept a pull request from a non-contributor compared with a contributor merging a patch from a non-contributor? Legally, both are disallowed unless there's some proof (written statement etc) from the code author that he assigns ownership of the patch or the contents of that pull request to the contributor who is doing the checkin. In the past we haven't done a good job of enforcing this clear ownership assignment chain. There are always code patches from non-contributors in the bug tracker that may make it into the code base with the help of a contributor. There's a grey area: Is the act of submitting a patch into the Zope bug tracker enough to signal I am giving you ownership of this code? I am not sure. GitHub makes this pulling in of outside code even easier. I'm afraid it will become even harder to really maintain this chain of custody. This is then, IMO a problem that we should fix. What you are in fact saying is that the current system are violating people's copyright everytime we merge a non-contributors patch. It is unfeasible to not merge peoples patches, and I think it is also a big problem that the way the ownership of the code works now inhibits the increased simplicity of making and merging fixes for non-core contributors. In other words, we have had an ownership situation which is terrible, and nobody seems to have realized this until now. Well, now we know. As such, the discussion must now shift from don't do this to how do we do this. Poeple want to contribute and we should not say don't do that, we have to figure out *how* to make it possible to do that, and pretty pronto as well. //Lennart ___ 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: zc.buildout/ Moved to github
On Sun, Aug 19, 2012 at 12:16 PM, Jens Vagelpohl j...@dataflake.org wrote: Speaking for myself as ZF representative, it is my duty to make sure that chain of custody for the code is upheld and safeguarded. Convenience, which I feel is driving the move towards GitHub, is nice to have. But I would not do my job if I didn't make extra-sure that any move for Zope Foundation code did not fulfil all legal requirements before spending much thought on convenience. Absolutely, and you are doing a good job as well, as you have no identified a problem that we have been having for a long time, before the problem actually turns legal. That's an amazing relief, because it means we can fix it. //Lennart ___ 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: zc.buildout/ Moved to github
On Sun, Aug 19, 2012 at 5:49 PM, Tres Seaver tsea...@palladion.com wrote: The point is that the identity of the committer on Github is not tied to the ZF's machinery for contributions, which means that it cannot be used to preserve the chain of custody under the contributor agreement. What stops us from fixing this problem? //Lennart ___ 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: zc.buildout/ Moved to github
On Sat, Aug 18, 2012 at 10:39 AM, Jens Vagelpohl j...@dataflake.org wrote: Legally this must be a fork then and I'm not sure it can be released as official Zope Foundation software anymore if you make releases from GitHub. Reason: the ZF can no longer ascertain that only official ZF contributor agreement signers have modified code in the package, which is a core requirement for software released from Zope Foundation repositories/under Zope Foundation auspices. Is this because of the support for merging pull requests? Is that really legally different than a contributor making a merge from a patch? //Lennart ___ 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: zc.buildout/ Moved to github
On Sat, Aug 18, 2012 at 11:03 PM, Tres Seaver tsea...@palladion.com wrote: Because the ability to check into svn.zope.org is based on a chain of custody managed by the ZF (web account, verified e-mail address, and SSH key). J. Random Hacker's account on Github has no such chain. Sure, but Random J Hacker shouldn't have write permission to the repository, so I don't understand why that makes a difference. //Lennart ___ 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] [ZODB-Dev] RFC: release persistent as a standalone package
On Mon, Jul 2, 2012 at 7:35 PM, Alan Runyan runy...@gmail.com wrote: I would like to release a '4.0.0' version of the package, and switch the ZODB trunk to pull it in as a dependency (deleting the currently included (older) copy of persistent). One possible issue is that I have not (yet) made the C extensions work under Python 3.2: I don't know whether that should be a blocker for a release. I do not believe its a blocker. That is a feature that could be added. Comments? You rock. +1 ___ 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.interface 4.0.0 considered annoying.
On Sun, May 20, 2012 at 6:08 AM, Tres Seaver tsea...@palladion.com wrote: I will release a 4.0.1 silencing the warnings unless somebody speaks up in their favor. We should make sure we have 2to3 fixers for everything change as well. I added some fixers, but it's so long ago I'm not sure all changes are covered. But with fixers the warnings aren't very problematic, as fixing the loud failures is just a matter of running the fixers. //Lennart ___ 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.i18n plural form support
On Thu, May 17, 2012 at 10:42 PM, Thomas Massmann thomas.massm...@inqbus.de wrote: I added the plural form support Whohoo! ___ 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] Python 3.3 port of zope.configuration
On Fri, Apr 13, 2012 at 01:37, Tres Seaver tsea...@palladion.com wrote: How deep is the six dependency? For every package I've ported to date, it has ended up being more sensible to implement a local '_compat' module which had only the needed straddles (sometimes inspired by six, sometimes very localized). You can also just copy six.py into the module and use it from there. That way it's not an external dependency any more. //Lennart ___ 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] ZAM/ZMI Demo
On Mon, Feb 6, 2012 at 13:07, Sylvain Viollon sylv...@infrae.com wrote: That would be great, for my part to be able to have the management tools (packing and such) in a separate package than the object browsing Excellent point. (and even the object actions, if you want to keep them, I don't want them). We need two packages for the object browser: One with the interfaces and layers to enable registration of the object actions and views, and one with the actual object browser views, that makes use of these registered actions and views. And we need one package that contain the New ZMI which is basically just a Zope Control panel, where the object browser is just one plugin to that control panel. //Lennart ___ 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 4 release management
On Wed, Feb 1, 2012 at 14:29, Alex Clark acl...@aclark.net wrote: On 2/1/12 8:21 AM, Lennart Regebro wrote: Should you then decide that github is the place to host it, well, then git is the software to use. Actually, they introduced improved Subversion client support late last year: - https://github.com/blog/966-improved-subversion-client-support And now you have two problems. :-) //Lennart ___ 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 4 release management
On Wed, Feb 1, 2012 at 15:40, Alexandre Garel alex.ga...@tarentis.com wrote: I'm a bit amazed by this argumentation. I think one important thing is that subversion is centralized while dvcs are not. And I think it's very unimportant. With dvcs everyone got full history of zope libs. I personally find it a big pro for a free software. You get that with svn too. More over with dvcs someone may fork a product on his side (a branch of his own, not on a zope server) and make it evolve, still having ability to merge updates (and auto merge in dvcs are superior to the one found in subversion). You can do that with svn too. The merging of it is easier with something like github or gitorious, but git in itself doesn't really help. //Lennart ___ 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 4 release management
On Wed, Feb 1, 2012 at 13:03, Alex Clark acl...@aclark.net wrote: - what RCS software to use - where to host it It may be easier if we disentangled them. Traditionally it was easier, but now-a-days with github and bitbucket they are harder to disentangle. It is entangled, but it is important to notice that they are separate concerns. I do think the big issue is where to host it. Yes, fine, people have opinions on git vs svn vs hg, etc. But that boils down to 25% technical arguments, 25% what you are used to 25% what everyone else uses and then 30% religion to make sure the bucket overflows. But where to host it is a tricky issue. Ownership and control is one big argument for having our own servers. Githubs forking/merging process a big argument for going to github. Should you then decide that github is the place to host it, well, then git is the software to use. To be honest I see little point in just setting up our own git repository. Yeah, maybe git is better from some technical standpoints, but it's also harder to use, and the question then becomes just religion. What we would like to do, of course, is to have a self-hosted github. :-) (And that exists. Buuut... it costs $250 per commiter and year, so that's not an option, obviously.) //Lennart ___ 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 internals documentation
On Sat, Dec 31, 2011 at 20:09, Martin Aspeli optilude+li...@gmail.com wrote: Hi folks, I have documented some of the darker corners of Zope's internals. I put it in the Plone developer documentation for lack of a better place, but it's not Plone-specific: http://collective-docs.readthedocs.org/en/latest/zope_secrets/index.html Topics covered include startup, publication, traversal and security. One reason to do this, apart from morbid fascination, is to provide a baseline against which we can consider simplifying some of this stuff. For example, I'd like to consider an (opt-in) simplification of the publisher and traversal, probably based on a stripped-down and modernised repoze.zope2, which does away with some hooks and edge cases, but is much simpler and easier to understand. Some things we could consider chopping are: - Attribute traversal to anything other than methods at the end of the traversal chain (i.e. use __getitem__ traversal only) - Traversal to anything without explicit security declarations - The docstring security check - Maybe __bobo_traverse__ (i.e. just implement __getitem__) and __before_publishing_traverse__ (use a BeforeTraverseEvent instead, and notify this for all traversals, not just over local component sites) - All differences between publication and path traversal This is still somewhat half-baked and obviously would break things and require at least a new major version of Zope, but I think it's worth exploring at least. +1 for all of those, as a part of the so called Zope 4 path of developments. ___ 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] Revert removal of ++skin++ in Zope4?
On Wed, Nov 16, 2011 at 16:12, Laurence Rowe l...@lrowe.co.uk wrote: While I think there is definitely scope for simplifying the mix of competing skin concepts in the Zope/CMF/Plone space, we need to be careful not to bite off more than we can chew. We still have a lot of CMF skin scripts and templates in Plone that I don't want to become a blocker for adopting Zope 4. This should be the first of several releases that progressively rationalise our software stack, lets not try and do it all at once. Absolutely. Getting rid of CMFSkins is a part of getting rid of CMF, not a part of moving to Zope 4. Different issues. But I do think that whatever skin concept Zope 4 has, should be one that can also be used by Plone. Until we get rid of CMF we have to have at least two skin concepts, and that's one to many. Having a third one is no good. If, as Tres say, ++skins++ is overworked and overcomplicated, could we extend plone.browserlayers to have a traverser or something? //Lennart ___ 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] Revert removal of ++skin++ in Zope4?
On Thu, Nov 17, 2011 at 11:52, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Hi Lennart, I'm not sure if you're not mixing different issues here. Am 17.11.2011, 11:35 Uhr, schrieb Lennart Regebro rege...@gmail.com: Absolutely. Getting rid of CMFSkins is a part of getting rid of CMF, not a part of moving to Zope 4. Different issues. I assume you are referring to removing Plone's dependencies on CMF. That is not relevant to the discussion about Zope 4 / ZMI reimagined. Which is exactly what I said above. //Lennart ___ 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 4 roadmap
On Thu, Nov 17, 2011 at 20:57, Tres Seaver tsea...@palladion.com wrote: FWIW, the port to Python3 of substantial existing web framework code is already a dubious proposition: nearly everybody doing it these days is suffering pain (making their own code more complicated by straddling) in order to gain hypothetical future benefits. The framework as a whole should not straddle versions. Just as we drop backwards incompatibility for Zope 4 and then Zope 5 and then Zope 6, etc, in one of these moves we drop backwards incompatibility by moving from Python 2 to Python 3. That in fact is probably a good reason for a new release all by itself. :-) The same thing goes for Plone. Once Zope X does the move, Plone Y does. Only the packages and products for Plone should need to straddle versions. //Lennart ___ 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] Revert removal of ++skin++ in Zope4?
On Wed, Nov 16, 2011 at 12:24, Laurence Rowe l...@lrowe.co.uk wrote: It was removed in http://zope3.pov.lt/trac/changeset/122056 because it wasn't actually being used anywhere. I'm not completely averse to adding it back, but it does create confusion with the various different alternatives in Zope2 like CMF skins and plone.browserlayer. Right. Could we standardize on skins or browserlayers plz? Having both confuses the heck out of me. //Lennart ___ 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] Revert removal of ++skin++ in Zope4?
On Wed, Nov 16, 2011 at 12:53, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Am 16.11.2011, 12:49 Uhr, schrieb Lennart Regebro rege...@gmail.com: Right. Could we standardize on skins or browserlayers plz? Having both confuses the heck out of me. Definitely a topic that needs (re)-opening. From a CMF point of I think we're just about at the point where we could switch to browser layers, well, at least once CMF 2.3 has been released. But I think that CMF Skins still offer some functionality that you don't get with browser layers out of the box. When I said skins I meant ++skins++. CMF Skins must die. //Lennart ___ 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 4 publisher/traversal, sprint topic
Do we really have to call it Zope 4? :-) On Thu, Oct 27, 2011 at 15:34, Leonardo Rochael Almeida leona...@nexedi.com wrote: Hi, Sorry for the cross-post, but I'd like to talk about a possible sprint topic for the next DZUG sprint[1], and invite myself to it :-) After the last two rather serious security issues that were recently patched in the Zope2 code base, it is increasingly clear to me that, differently than what Hanno reported some time ago, it's not so much the ZMI that represents a huge security liability in the Zope codebase, but it's actually the way the current publisher happily traverses any attribute and publishes any method with docstring by default. The ZMI, of course, has its problems (ugly in appearance and even uglier in code), and I agree with Hanno on most everything he has to say about it, but I'd like to propose we start, for Zope 4, by tackling the potential security liability that is the Zope publisher itself, and the fact that it makes it easy to open up large security holes if you're not paying attention. I'd like to propose that publishing traversal in Zope 4 would, by default only traverse based on __getitem__ (not attribute lookup). For a minimum of backward compatibility, it could perhaps do a single traversal on getattr, and only after it has exhausted __getitem__ traversal. After this, if the traversal found something, it would only be published if there is an explicit indication of intention that the object in question is supposed to be published. Otherwise, raise a NotFound, as if the traversal had failed. One example of an explicit demonstration of intent is, for example, if it provides an IPublishable interface (I just made that up, other names can be considered). Taking a suggestion from Shane, we could have convenient decorators for people who wants to explicitly publish class methods. They could dynamically create ZTK views with the same name as the function that they wrap and allow (or perhaps enable by default) some form of CSRF protection. To ease code migration, we could consider that the InitializeClass call provides the same effect as the above decorator. This would allow large amounts of previously existing code to work without recoding, while at the same time avoiding the security trap of forgetting to call InitializeClass and thus exposing unintented methods. It could even remove the need for the single getattr traversal compatibility above. On top of that, if InitializeClass register these views to a specific ZTK skin, it would make it possible to disable them by default, unless that specific skin is in effect, which would alleviate what Hanno described as running phpMyAdmin accessible to the world with the same credentials and on the same domain as the rest of your application. Anyway, I think the above is on-topic for the next DZUG sprint and I'd like to work on it there. So, even if the sprint is supposed to be in German, and I don't speak a word of it, can I attend? [1] http://www.zope.de/community/veranstaltungen/3.-dzug-sprint-2011-zmi , translation at: http://translate.google.com/translate?hl=ensl=autotl=enu=http%3A%2F%2Fwww.zope.de%2Fcommunity%2Fveranstaltungen%2F3.-dzug-sprint-2011-zmi Cheers, Leo ___ 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 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.schema and Python 3
On Tue, Oct 11, 2011 at 10:22, Brian Sutherland br...@vanguardistas.net wrote: On Mon, Oct 10, 2011 at 01:14:26PM +0200, Brian Sutherland wrote: I've managed to port zope.schema to Python 3.2 on a branch (jinty-python3). One doubt which has just crept up on me is if these classes: ASCII, ASCIILine, URI, Id, DottedName should still inherit from Bytes on Python 3. It seems more logical that they should inherit from Text. I had to do some gymnastics to keep them bytes on python 3 and feel all dirty about it. DottedName, in particular, describes itself as Python-style dotted names. But in Python 3 this code works: from 漢語 import Español print(Español) class '漢語.Español' so a DottedName could be '漢語.Español' under Python 3. Definitely unicode and not Bytes. However, changing the behaviour of these classes between Python 2 and 3 may be even more problematic. Another option is simply to have these classes raise NotImplementedError in their validate() methods under Python 3 and wait till the solution becomes more obvious. Anyone out there willing to assuage my doubts? It seems to me that they should be `str`, all of them, except possibly URI. I'm unsure exactly how that changes the behavior. ASCII/ASCIILine should have validators to restrict them to ASCII only, reasonably, I don't know if they already do. //Lennart ___ 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] web sites are keep crashing
On Thu, Aug 25, 2011 at 10:34, Babylakshmi Muthusamy babylakshmim...@gmail.com wrote: I would like to know whether we can change the proxy error to site error which wont affect the uptime of the site. By default the proxy you have in front (Apache?) should not show 502 in these cases. This may be a problem in the configuration of that proxy. It could also be that the Zope application you have catches the error and then returns an empty response instead of the normal error page. In that case the application needs to be fixed. //Lennart ___ 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] congrats on the new zope.org launch, but..
On Fri, Jul 15, 2011 at 16:23, Martijn Faassen faas...@startifact.com wrote: On 07/15/2011 03:13 PM, Hanno Schlichting wrote: On Fri, Jul 15, 2011 at 1:50 PM, Martijn Faassenfaas...@startifact.com wrote: I'd just call the category web framework; 2 out of 3 already say they are. Zope can then itself say in its description that it's an application server if that's an important term. At least zope2.zope.org uses the web framework term to describe Zope 2 as well. application server doesn't describe todays Zope 2 codebase and aim anymore either. So I'd rather place all of the big guys in the web framework box. +1 +1 too. ___ 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] versions on zope.org and launchpad.net
On Wed, Jun 29, 2011 at 00:17, Tres Seaver tsea...@palladion.com wrote: - breaking the historic URLs for no purpose is lame, and would cause useless pain to people with older installations that rely on them (Yes, Virginia, there were automated buildouts before zc.buildout). True. Can we have the old download URL's still there, but redirect or link to PyPI from the web? - PyPI is the canonical download location for the current releases: launchpad should just be pointing there. +1 I think also we should not on PyPI hide all releases except the latest one. The download box should contain at minimum all supported releases, preferrably the last of each major version (within reason). //Lennart ___ 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 - FAILED: 4, OK: 86, UNKNOWN: 1
Will not having open bug reports as a fail again turn the buildbots red again, and hence return the overview to uselessness? //Lennart On Mon, Jun 27, 2011 at 07:00, Zope tests summarizer nore...@zope.org wrote: This is the summary for test reports received on the zope-tests list between 2011-06-25 00:00:00 UTC and 2011-06-26 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received Bluebream / Python2.4.6 64bit linux Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.5 64bit linux [1] Repository policy check found errors in 305 projects Total languishing bugs for zope2: 0 [2] Total languishing bugs for zope: 59 [3] Total languishing bugs for zopeapp: 2 [4] Total languishing bugs for zopetoolkit: 200 [5] UNKNOWN : Zope Buildbot / zope2.13_win-py2.6 slave-win ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.5 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.5 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope Buildbot / zope2.12-py2.6 slave-osx Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.6 slave-osx Zope Buildbot / zope2.13-py2.6 slave-ubuntu32 Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.7 slave-osx Zope Buildbot / zope2.13-py2.7 slave-ubuntu32 Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 Zope Buildbot / zope2.13_win-py2.7 slave-win Zope Buildbot / zope2.14-py2.6 slave-osx Zope Buildbot / zope2.14-py2.6 slave-ubuntu32 Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 Zope Buildbot / zope2.14-py2.7 slave-osx Zope Buildbot / zope2.14-py2.7 slave-ubuntu32 Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0_win-py2.4 slave-win Zope Buildbot / zopetoolkit-1.0_win-py2.5 slave-win Zope Buildbot / zopetoolkit-1.0_win-py2.6 slave-win Zope Buildbot / zopetoolkit-1.1-py2.5 slave-osx Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-osx Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1_win-py2.5 slave-win Zope Buildbot / zopetoolkit-1.1_win-py2.6 slave-win Zope Buildbot / zopetoolkit-py2.5 slave-osx Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-py2.6 slave-osx Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit_win-py2.5 slave-win Zope Buildbot / zopetoolkit_win-py2.6 slave-win Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_254_win32 winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_254_win32 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot
Re: [Zope-dev] zope-tests - OK: 77
Whohoo! Amesome work all bugfixers! On Wed, Jun 22, 2011 at 07:00, Zope tests summarizer nore...@zope.org wrote: This is the summary for test reports received on the zope-tests list between 2011-06-20 00:00:00 UTC and 2011-06-21 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received Bluebream / Python2.4.6 64bit linux Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.5 64bit linux ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.5 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.5 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope Buildbot / zope2.12-py2.6 slave-osx Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.6 slave-osx Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.7 slave-osx Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 Zope Buildbot / zope2.14-py2.6 slave-osx Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 Zope Buildbot / zope2.14-py2.7 slave-osx Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.5 slave-osx Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-osx Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-py2.5 slave-osx Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-py2.6 slave-osx Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_254_win32 winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_254_win32 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -- ___ 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 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] beta.zope.org (www.zope.org relaunch project)
On Fri, May 13, 2011 at 12:12, Charlie Clark charlie.cl...@clark-consulting.eu wrote: One thing that I think is missing on the resource page is a Products overview - PyPI isn't really suitable for someone wanting to see whether Zope (2) is suitable for them and despite what we now think about how to extend Zope, the Products do provide off-the shelf solutions for many situations; something that as developers we easily overlook. That's not really Products but full applications, like Plone and ERP5 etc. It might be an idea to have a listing for that, but that's not really to determine if Zope is suitable, but to brag of the nice solutions built with Zope. :-) //Lennart ___ 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] beta.zope.org (www.zope.org relaunch project)
Oh! Nice! IMO you can switch now. It's already a vast improvement, constructive feedback and changes might improve it more, but it doesn't need to be perfect before it's launched, just better. And it is. On Tue, May 10, 2011 at 06:55, Andreas Jung li...@zopyx.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I am happy to announce that we have made progress with the zope.org relaunch project. The first public version of the new site is now available under http://beta.zope.org The basic idea behind the project is: - a minimalistic www.zope.org site giving a short overview about what Zope is - including all related app servers, CMSes, frameworks etc. which links to the related project sites (micro-site approach) - no more member contents on www.zope.org - the current www.zope.org will be stripped down to the current member contents and stuff that has to be preserved. www.zope.org will be renamed to old.zope.org later Constructive criticism and feedback is welcome _now_. I hope that we can fix the outstanding issues and integrate further feedback over the next few week in order to roll out the new site in the first half of June (2011 of course). Many thanks to my team (doing the real work): - - Michael Haubenwaller - - Kai Mertens - - Johannes Raggam Andreas Jung Zope Foundation -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGUBAEBAgAGBQJNyMVOAAoJEADcfz7u4AZjTgoLvigFQqPKlnn9J97+wrQRJkdr 8ErOiV6LCmpQeNLGDVodq0Y4JGnfQELu0ByzRz+xdig3NDAY9WyKTcxjJqu7DJ4H NnZ49dK47uvZaYbfq0kKjzIw9/FX092t5+lyVdiYst1d3JGEphz1iDsl+rySu4m1 xf3Zq5/+HH0xl2NPQ391dqPuoka+93ydygBfqR7TbBxr4t1GcbFs6vMhN5/13I7c g/Q6CWCKlBOfdSnof+p1M/EHtLelst7LPHXluB5tLSQcbpbhd3vtV2x19+InNBWs 3vbaWz9EFPQVdgrAc8f3Npw6+t1tn2JMBlLEJtwLmaErqjgDA4MMEmOmJPqNDqYo 7fyVWy0+OFeJdrGtO6MOZvmkgTxp+DBYjCOqzhzBijoHGaBQz1RsfH8IrWqhI+Av PRihsjM6ZBEhVcHyW/FIQfSvsYJCsim+xxcfkmUhUjXSD6j2h4BBjNnnyI2JRHkq iu0A27ANzqZrHx8rRipFcU9gJqLtBfA= =8/ed -END PGP SIGNATURE- ___ 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 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] beta.zope.org (www.zope.org relaunch project)
I think http://beta.zope.org/the-world-of-zope does a good job. On Tue, May 10, 2011 at 07:28, Alex Clark acl...@aclark.net wrote: Hi, On 5/10/11 12:55 AM, Andreas Jung wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I am happy to announce that we have made progress with the zope.org relaunch project. The first public version of the new site is now available under http://beta.zope.org The basic idea behind the project is: - a minimalistic www.zope.org site giving a short overview about what Zope is - including all related app servers, CMSes, frameworks etc. which links to the related project sites (micro-site approach) - no more member contents on www.zope.org - the current www.zope.org will be stripped down to the current member contents and stuff that has to be preserved. www.zope.org will be renamed to old.zope.org later Constructive criticism and feedback is welcome _now_. Looks great, well done all! Thanks for putting in the effort. My one (very minor) nit would be that we try to over-emphasize and over-clarify what Zope is (and is not), anywhere and everywhere possible. And by that, I mean: - Zope is: a brand, a term for any Zope-related technology, a general term. It no longer refers to anything specific. It is all-encompassing. - Zope 2 is the original web application server. - Bluebream is the former-Zope 3 web application server. - ZTK is a set of re-usable libraries. And so on. Alex I hope that we can fix the outstanding issues and integrate further feedback over the next few week in order to roll out the new site in the first half of June (2011 of course). Many thanks to my team (doing the real work): - - Michael Haubenwaller - - Kai Mertens - - Johannes Raggam Andreas Jung Zope Foundation -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGUBAEBAgAGBQJNyMVOAAoJEADcfz7u4AZjTgoLvigFQqPKlnn9J97+wrQRJkdr 8ErOiV6LCmpQeNLGDVodq0Y4JGnfQELu0ByzRz+xdig3NDAY9WyKTcxjJqu7DJ4H NnZ49dK47uvZaYbfq0kKjzIw9/FX092t5+lyVdiYst1d3JGEphz1iDsl+rySu4m1 xf3Zq5/+HH0xl2NPQ391dqPuoka+93ydygBfqR7TbBxr4t1GcbFs6vMhN5/13I7c g/Q6CWCKlBOfdSnof+p1M/EHtLelst7LPHXluB5tLSQcbpbhd3vtV2x19+InNBWs 3vbaWz9EFPQVdgrAc8f3Npw6+t1tn2JMBlLEJtwLmaErqjgDA4MMEmOmJPqNDqYo 7fyVWy0+OFeJdrGtO6MOZvmkgTxp+DBYjCOqzhzBijoHGaBQz1RsfH8IrWqhI+Av PRihsjM6ZBEhVcHyW/FIQfSvsYJCsim+xxcfkmUhUjXSD6j2h4BBjNnnyI2JRHkq iu0A27ANzqZrHx8rRipFcU9gJqLtBfA= =8/ed -END PGP SIGNATURE- ___ 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 ) -- Alex Clark · http://aclark.net/training ___ 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 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] Please, if you port to Python 3, port to 23
On Sat, Apr 30, 2011 at 17:36, Jim Fulton j...@zope.com wrote: If we decide to port zope.org-based projects to Python 3, please please please, port them to Python 23 rather than relying on 2to3 (or 3to2). That is, update the code to work with both Python 2 and Python 3. Relying on 2to3 (or 3to2) is a headache for anyone who uses a develop installation of a package. (It's also rather annoying for someone installing a 2to3-based project in Python 3.) I'm not sure exactly what using a develop installation means or what headaches it causes, but, for many projects supporting Python 2 and Python 3 without 2to3 is going to require massive changes and/or dropping Python 2.5 support. That has to be considered. I found 2to3 somewhat helpful in beginning the process of getting buildout working with Python 3, but then worked the source into a form that works with both Python versions. The code is uglier, but not as ugly as incporating 2to3 in the development workflow. Well, incorporating 2to3 into the buildout development workflow would have been nearly impossible, but buildout is a special case. //Lennart ___ 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] Anyone want to do Google Summer of code mentoring for PSF?
On Tue, Apr 5, 2011 at 07:56, Chris McDonough chr...@plope.com wrote: On Thu, 2011-03-17 at 14:57 -0400, Lennart Regebro wrote: I'm still in Atlanta, and Arc Riley asked for a Zope person to possibly mentor some zope.* project for Python Software Foundation this year. They probably want to get more of the Zope Toolkit ported to Python 3. I forwarded the roadmap to him, so anyone who wants to mentor, that would be great. I've said I'm available to ask questions about porting and help from a technical point of view, but I suck at the mentoring part, so somebody else that does that is needed. Mail him at arcri...@gmail.com if interested. Did this particular effort get to the place where there are students and mentors lined up to do ZTK porting? No, it got to the pace where I'm supposed to set up a team page on a Wiki. ___ 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] Anyone want to do Google Summer of code mentoring for PSF?
On Tue, Apr 5, 2011 at 11:57, Lennart Regebro rege...@gmail.com wrote: On Tue, Apr 5, 2011 at 07:56, Chris McDonough chr...@plope.com wrote: Did this particular effort get to the place where there are students and mentors lined up to do ZTK porting? No, it got to the pace where I'm supposed to set up a team page on a Wiki. Done: http://wiki.zope.org/gsoc/SummerOfCode2011 ___ 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] Anyone want to do Google Summer of code mentoring for PSF?
On Sun, Mar 20, 2011 at 01:06, Stephan Richter srich...@cosmos.phy.tufts.edu wrote: On Saturday, March 19, 2011, Lennart Regebro wrote: Getting ZCA/ZTK to run on PyPy is probably easier, and actually more useful. Maybe someone would want to mentor that? While I would mentor someone wanting to do such a project, I would be much more interested in seeing a working WebOb to zope.publisher bridge. I know Jim(?) has done some initial work on that. I think it would make an interesting PSF project, since it encourages more reusability across the Python Web dev community. So I'll sign up as a Zope team member. Cool. But it turns out we need three to make a team (see https://spreadsheets.google.com/viewform?formkey=dHh3WFNGYzkyWWE0ZjM1eFFoUUVGWmc6MQ), and we only really have one. :-) I guess I could take a bullet for the team too, but that still makes only two. Maybe next year. :-) //Lennart ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
I haven't read through the whole discussion in detail, so I'm sure I repeat some of what has been said already, but here is my point of view. 1. Yes, Grok is pretty implicit. If it's soo implecit is a matter of taste, but much of the implicitness makes sense. You typically do have a model and a view and a template, and the model and view are typically in one module, and has a name similar to the template. That implicitness however only makes sense in the specific context of web applications. There is no reasonably way to have that implicitness with components and adapters. So a configuration for the ZCA in general can't be implicit. 2. That doesn't mean we can't use grok-style configuration though. 3. Although Python 3 means we can't. We'll have to use decorators. 4. zope.interface already does, and zope.component will as well, once it's ported. That means we get things like: class IMyFace(Interface): whatevah class IMyFeet(Interface): something @implementer(IMyFace) class MyFace(object): yeahyeah @adapter(IMyFace, IMyFeet) class FootInMouth(object): def __init__(self, mouth, foot): pass The @adapter decorator so far only handles functions, but will be extended to classes once we port zope.component. I think also adapter today will only mark the object as adapts(...) does, but you will still use zcml to register the adapter. So probably we still need @adapter (as it already exists) and also another decorator (say @adapt() maybe?) that will both mark the class and register it in the registry, and hence do the same as the adapter ... / directive does today. Then we have subscriber, utility, resource and view directives. There's no particular reason I know of that means they couldn't be class decorators as well. That takes care of most of the configuration needed for the ZCA itself. How to deal with the rest probably gets more obvious once we've done this. //Lennart ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
Also, the decorators will always return the original component, meaning they can easily be used as post-config: @adapter(IMyFace, IMyFeet) class FootInMouth(object): ... Will mark the class as an adapter, but not register it. @adapt(IMyFace, IMyFeet) class FootInMouth(object): ... Will mark and register. @adapter(IMyFace, IMyFeet) class FootInMouht(object): ... adapt(FootInMouth)() Will register a previously marked adapter, and adapt(FootInMouth)(IMyFace, IMyFeet) Will mark and register. This means you can, if you want, still have the interfaces in one file, the implementations in one file, and the registrations separately (say, configure.py), thereby getting the same separation as you had with interfaces.py, components.py and configure.zcml. Your package just needs to *not* import the configure.py file. On Mon, Mar 21, 2011 at 12:47, Lennart Regebro rege...@gmail.com wrote: I haven't read through the whole discussion in detail, so I'm sure I repeat some of what has been said already, but here is my point of view. 1. Yes, Grok is pretty implicit. If it's soo implecit is a matter of taste, but much of the implicitness makes sense. You typically do have a model and a view and a template, and the model and view are typically in one module, and has a name similar to the template. That implicitness however only makes sense in the specific context of web applications. There is no reasonably way to have that implicitness with components and adapters. So a configuration for the ZCA in general can't be implicit. 2. That doesn't mean we can't use grok-style configuration though. 3. Although Python 3 means we can't. We'll have to use decorators. 4. zope.interface already does, and zope.component will as well, once it's ported. That means we get things like: class IMyFace(Interface): whatevah class IMyFeet(Interface): something @implementer(IMyFace) class MyFace(object): yeahyeah @adapter(IMyFace, IMyFeet) class FootInMouth(object): def __init__(self, mouth, foot): pass The @adapter decorator so far only handles functions, but will be extended to classes once we port zope.component. I think also adapter today will only mark the object as adapts(...) does, but you will still use zcml to register the adapter. So probably we still need @adapter (as it already exists) and also another decorator (say @adapt() maybe?) that will both mark the class and register it in the registry, and hence do the same as the adapter ... / directive does today. Then we have subscriber, utility, resource and view directives. There's no particular reason I know of that means they couldn't be class decorators as well. That takes care of most of the configuration needed for the ZCA itself. How to deal with the rest probably gets more obvious once we've done this. //Lennart ___ 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 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] Anyone want to do Google Summer of code mentoring for PSF?
On Mon, Mar 21, 2011 at 13:28, Stephan Richter srich...@cosmos.phy.tufts.edu wrote: On Monday, March 21, 2011, Lennart Regebro wrote: So I'll sign up as a Zope team member. Cool. But it turns out we need three to make a team (see https://spreadsheets.google.com/viewform?formkey=dHh3WFNGYzkyWWE0ZjM1eFFoUU VGWmc6MQ), and we only really have one. :-) I guess I could take a bullet for the team too, but that still makes only two. Maybe next year. :-) Jim said he would be willing to mentor someone for the right project. That would make us three. Ah, OK. I'll sign up then. ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, Mar 21, 2011 at 14:17, Martijn Faassen faas...@startifact.com wrote: Anyway, Grok's configuration is dependent on the rules you give it, so it's possible to have a completely explicit set of directives with no implicit fallback to default values whatsoever. Martian supports that scenario right now. Sure, but I'm of course referring to how it behaves by default, including the associations made by the grokking process. I think that makes sense in a webapp, but not otherwise, and we should at least as a start concentrate on the generic component architecture case. For Martian, Python 3 support is mostly an issue of making class directives work as class decorators. And the same goes for zope.component support, of course. With martian, the registration is then done by the grokking process, but I think decorators would be a process that is more acceptable to the Python world in general. Instances does indeed require something else than decorators, I hadn't thought of that, that's a drawback. //Lennart ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, Mar 21, 2011 at 15:28, Jim Fulton j...@zope.com wrote: This might be OK for @implements and maybe @adapts, which describe behavior, but start feeling wonky to me for something like: @utility. Well, the wonkyness comes from @utility *not* being inherited, while @implements would be. That could be confusing. It wold be possible to let @utility be inherited if it's done by scanning, though. But under what name in that case? I think that possibly would be even *more* confusing. It may be that decorators isn't the right answer for registration. In that case scanning is an option, unless we simply go for straight imperative configuration. @implementer(IMyFace) @adapter(IMyFoot) class FootInFace(object): def __init__(self, foot, face) self.foot = foot self.face = face component.utility(FootInFace()) It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. On Mon, Mar 21, 2011 at 15:36, Martijn Faassen faas...@startifact.com wrote: Do we really care about the Python world in general? Is that relevant to the discussion? Can't we just talk about what we care about? The Python world in general uses metaclasses for this kind of stuff, which relies on base classes too, by the way. Yeah, but that's to a large extent because class decorators still are relatively new. You can't use them if you need to support Python 2.5. You'll still need a module importing process, as I sketched out elsewhere if you use class decorators, to have the class decorators kick in at all for modules you don't need to import otherwise. Is that a problem? In the end, no matter what you do, the module needs to be imported. :-) That a utility doesn't get registered unless you import a specific module somewhere in the app doesn't seem like a problem to me. //Lennart ___ 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] Anyone want to do Google Summer of code mentoring for PSF?
On Thu, Mar 17, 2011 at 22:08, Jim Fulton j...@zope.com wrote: On Thu, Mar 17, 2011 at 2:57 PM, Lennart Regebro rege...@gmail.com wrote: I'm still in Atlanta, and Arc Riley asked for a Zope person to possibly mentor some zope.* project for Python Software Foundation this year. They probably want to get more of the Zope Toolkit ported to Python 3. I forwarded the roadmap to him, so anyone who wants to mentor, that would be great. I hope that isn't what they want. :) His stated goal for GSOC was to bring people into the community. I can't think of many better ways to turn someone off than to ask them to port something from Py2 to Py3. Well, that's what he said. But in any case it might be a good idea if Zope people joined the PSF GSoC project to vote and comment on any zope related applications if those show up. I will, even though I refuse to be a mentor, since I suck at it. //Lennart ___ 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] Anyone want to do Google Summer of code mentoring for PSF?
On Sat, Mar 19, 2011 at 13:07, Lennart Regebro rege...@gmail.com wrote: On Thu, Mar 17, 2011 at 22:08, Jim Fulton j...@zope.com wrote: On Thu, Mar 17, 2011 at 2:57 PM, Lennart Regebro rege...@gmail.com wrote: I'm still in Atlanta, and Arc Riley asked for a Zope person to possibly mentor some zope.* project for Python Software Foundation this year. They probably want to get more of the Zope Toolkit ported to Python 3. I forwarded the roadmap to him, so anyone who wants to mentor, that would be great. I hope that isn't what they want. :) His stated goal for GSOC was to bring people into the community. I can't think of many better ways to turn someone off than to ask them to port something from Py2 to Py3. Well, that's what he said. But in any case it might be a good idea if Zope people joined the PSF GSoC project to vote and comment on any zope related applications if those show up. I will, even though I refuse to be a mentor, since I suck at it. Ah, actually, this year you put together teams. So in this case we need a Zope team. So if nobody shows interest we don't have a team, and we won't do anything. //Lennart ___ 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] Anyone want to do Google Summer of code mentoring for PSF?
Getting ZCA/ZTK to run on PyPy is probably easier, and actually more useful. Maybe someone would want to mentor that? On Thu, Mar 17, 2011 at 22:08, Jim Fulton j...@zope.com wrote: On Thu, Mar 17, 2011 at 2:57 PM, Lennart Regebro rege...@gmail.com wrote: I'm still in Atlanta, and Arc Riley asked for a Zope person to possibly mentor some zope.* project for Python Software Foundation this year. They probably want to get more of the Zope Toolkit ported to Python 3. I forwarded the roadmap to him, so anyone who wants to mentor, that would be great. I hope that isn't what they want. :) His stated goal for GSOC was to bring people into the community. I can't think of many better ways to turn someone off than to ask them to port something from Py2 to Py3. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Anyone want to do Google Summer of code mentoring for PSF?
I'm still in Atlanta, and Arc Riley asked for a Zope person to possibly mentor some zope.* project for Python Software Foundation this year. They probably want to get more of the Zope Toolkit ported to Python 3. I forwarded the roadmap to him, so anyone who wants to mentor, that would be great. I've said I'm available to ask questions about porting and help from a technical point of view, but I suck at the mentoring part, so somebody else that does that is needed. Mail him at arcri...@gmail.com if interested. //Lennart ___ 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] PyCon Zope sprint Python 3 progress report / roadmap.
We are here in Atlanta porting Zope stuff, and I've updated the roadmap, so I thought I'd post it on zope-dev and python-porting, so people know things are happening, and that they should have been here, because PyCon was awesome! So yesterday we've finished the porting of some low-hanging fruits, and they are now just hanging around waiting for releases. The complete roadmap for zope.component porting is here: Done and released: == setuptools (ie distribute) zope.interface zope.event zope.exceptions zope.testrunner Low hanging fruit: == zope.i18nmessageid: Done - not released setuptools - Done TODO: Trunk supports Python 3, not yet released. zope.hookable: Done - not released setuptools - Done zope.testing - [test] Done, not released TODO: Trunk supports Python 3, not yet released. zope.proxy: Done - not released setuptools - Done zope.interface - Done TODO: Trunk supports Python 3, not yet released. zope.testing: Done - not released setuptools - Done zope.interface - Done zope.exceptions - Done TODO: Trunk supports Python 3, not yet released. zope.testrunnner: Done setuptools - Done zope.interface - Done zope.exceptions - Done zope.testing - [test] Done, not released TODO: Some cleanup needed after releasing zope.testing for Python 3. Mid hanging fruit: == zope.configuration: setuptools - Done zope.interface - Done zope.i18nmessageid - Done, not released zope.schema transaction: zope.interface - Done zc.lockfile: setuptools - Done ZConfig: None zdaemon: None manuel: setuptools - Done zope.testrunner - Done, waiting for zope.testing. zope.testing - [test] Done, not released High hanging fruit: === zc.buildout: In Progress setuptools - Done zope.testing - [test] Done, not released zope.component: setuptools - Done zope.interface - Done zope.event - Done zope.testing - [test] Done, not released zope.testrunner - [test] Almost done, waiting for zope.testing. zope.hookable - [hook] [test] Done, not released zope.i18nmessageid - [zcml] Done, not released zope.proxy - [security] zope.location - [security] (Note semi-circular dependency) zope.security - [security] (Note semi-circular dependency) zope.configuration - [zcml] ZODB3 - [persistentregistry] [test] COMMENT: Loads of tests, mostly doctests means this is a pain to port. Also there is loads of magic which also may be a pain to port. Lastly, to run all the tests, we need a lot of extra modules, and some of those require zope.component. So we need to run only some tests under Python 3, and add tests once we port the other modules. zope.component dependencies === Optional packages for zope.component. Should be ported directly after zope.component. I don't know how difficult these are to port. zope.schema: setuptools - Done zope.interface - Done zope.event - Done zope.testing - [test] Done, not released z3c.recipe.sphinxdoc - [docs] COMMENT: Sphinx isn't ported yet. That's only for docs though, so no biggie. Possibly we'll have to avoid zc.buildout because of that. zope.location: setuptools - Done zope.interface - Done zope.proxy zope.schema zope.component - (Note semi-circular dependency) zope.security: (Uses a c-module) setuptools - Done zope.interface - Done zope.i18nmessageid - Done, not released zope.proxy zope.component - (Note semi-circular dependency) zope.location zope.schema zope.testing - [test] Done, not released ZODB3: zope.event - Done zope.interface - Done transaction zc.lockfile ZConfig zdaemon zope.testing - [test] Done, not released manuel - [test] COMMENT: Once zope.testing and zc.buildout are done, merging Martins work might not be too painful. ___ 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] string exceptions
On Fri, Feb 25, 2011 at 12:05, Laurence Rowe l...@lrowe.co.uk wrote: I take that back, that documentation is incorrect, they have indeed stopped working. You are allowed to catch them, but not raise them. This is so you can have code that runs on old Pythons with old libraries still. But in any case I think we safely can move them to ordinary exceptions. ___ 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] Sprints at PyCon
On Thu, Feb 10, 2011 at 16:46, Jim Fulton j...@zope.com wrote: I was planning to work on getting buildout woring with Python 3 (if it isn't done by then). Awesome! I'll make sure to get up to speed on what the issues was with my last attempt, because I forgot as usual. On Thu, Feb 10, 2011 at 11:58 AM, Baiju M baiju.m.m...@gmail.com wrote: 1. Port ZTK to Python 3 Excellent! More people interested in this are welcome, I made a roadmap recently, there are tasks that are both simple and very difficult on that one, we can find work for anyone interested. :-) Glad to see so many signing up already, this will be fun! //Lennart ___ 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] PyPy 1.4.1 and the ZTK
On Wed, Dec 22, 2010 at 15:24, Martijn Faassen faas...@startifact.com wrote: Hi there, I thought it'd be interesting to note that PyPy 1.4.1 (with JIT) now works out of the box with buildout Awesome! ___ 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 3 porting sprint?
On Fri, Nov 26, 2010 at 07:26, Ross Patterson m...@rpatterson.net wrote: Who would be interested in a sprint, when, where and how? I'd be interested in remote sprinting. I'm available now, FWIW. OK, so it's me and you then. :-) Let's talk in January about doing something and staying online at the same time during some specified period. ___ 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] I want some Python 3 C coding style guidance.
On Thu, Nov 25, 2010 at 11:37, Wichert Akkerman wich...@wiggy.net wrote: On 11/25/10 11:31 , Lennart Regebro wrote: Which style do you prefer? I'll make zope.hookable, zope.i18nmessage and zope.proxy use the same style if we can agree on one. The second. #ifdefs in code make code hard to follow and tend to lead to problems. FWIW the Linux kernel tree has a similar policy: they hide all differences behind macros and helper functions. OK, only one voice, but it agrees with me, so I'll go for this. Thanks! //Lennart ___ 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] I want some Python 3 C coding style guidance.
I've been porting some zope.* modules that have C-extensions to Python
3, and with the C-preprocessor you have so many possibilities that I
get all confused. So I'd like some opinions. Or onions. Or something.
The big issue is the module definition, which is quite different in
Python 2 and Python 3. What I ended up with in zope.proxy was
something like this:
--
#if PY_MAJOR_VERSION = 3
static struct PyModuleDef moduledef = {
PyModuleDef_HEAD_INIT,
_zope_proxy_proxy, /* m_name */
module___doc__, /* m_doc */
-1, /* m_size */
module_functions,/* m_methods */
NULL,/* m_reload */
NULL,/* m_traverse */
NULL,/* m_clear */
NULL,/* m_free */
};
#endif
static PyObject *
moduleinit(void)
{
PyObject *m;
#if PY_MAJOR_VERSION = 3
m = PyModule_Create(moduledef);
#else
m = Py_InitModule3(_zope_proxy_proxy,
module_functions, module___doc__);
#endif
if (m == NULL)
return NULL;
if (empty_tuple == NULL)
empty_tuple = PyTuple_New(0);
ProxyType.tp_free = _PyObject_GC_Del;
if (PyType_Ready(ProxyType) 0)
return NULL;
Py_INCREF(ProxyType);
PyModule_AddObject(m, ProxyBase, (PyObject *)ProxyType);
if (api_object == NULL) {
api_object = PyCObject_FromVoidPtr(wrapper_capi, NULL);
if (api_object == NULL)
return NULL;
}
Py_INCREF(api_object);
PyModule_AddObject(m, _CAPI, api_object);
return m;
}
#if PY_MAJOR_VERSION 3
PyMODINIT_FUNC
init_zope_proxy_proxy(void)
{
moduleinit();
}
#else
PyMODINIT_FUNC
PyInit__zope_proxy_proxy(void)
{
return moduleinit();
}
#endif
--
As you see, there are loads of #if PY_MAJOR_VERSION = 3 in there. And
three methods (I took this from Martin v Löwis work on zope.interface)
for the module init, as they have different profiles and names in
Python 2 and Python3.
This may be seen as quite messy, and many other compatibility issues
between 2 and 3 can be handled by defining macros and using #ifndefs.
So why not do the same for the module initialization? Said and done.
This is from zope.hookable:
--
#if PY_MAJOR_VERSION = 3
#define MOD_ERROR_VAL NULL
#define MOD_SUCCESS_VAL(val) val
#define MOD_INIT(name) PyMODINIT_FUNC PyInit_##name(void)
#define MOD_DEF(ob, name, doc, methods) \
static struct PyModuleDef moduledef = { \
PyModuleDef_HEAD_INIT, name, doc, -1, methods, }; \
ob = PyModule_Create(moduledef);
#else
#define MOD_ERROR_VAL
#define MOD_SUCCESS_VAL(val)
#define MOD_INIT(name) void init##name(void)
#define MOD_DEF(ob, name, doc, methods) \
ob = Py_InitModule3(name, methods, doc);
#endif
MOD_INIT(_zope_hookable)
{
PyObject *m;
hookabletype.tp_new = PyType_GenericNew;
hookabletype.tp_free = _PyObject_GC_Del;
if (PyType_Ready(hookabletype) 0)
return MOD_ERROR_VAL;
MOD_DEF(m, _zope_hookable,
Provide an efficient implementation for hookable objects,
module_methods)
if (m == NULL) return MOD_ERROR_VAL;
if (PyModule_AddObject(m, hookable, \
(PyObject *)hookabletype) 0)
return MOD_ERROR_VAL;
return MOD_SUCCESS_VAL(m);
}
--
As you see, there is one block of macro definitions in the start, and
then just one function at the bottom. Benefits are that if you have
many C-extensions you can extract the macro definitions to a separate
file. Drawbacks are that MOD_INIT looks like a function, when it is in
fact a function definition. But I don't know, maybe C-programmers are
used to that sort of thing. :-) Also, it's far from complete, MOD_DEF
doesn't support the new module_reload and module_traverse things for
example, bt maybe that's fixable.
Which style do you prefer? I'll make zope.hookable, zope.i18nmessage
and zope.proxy use the same style if we can agree on one.
//Lennart
___
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] Zope 3 porting sprint?
OK, I've run out of steam for this run of trying to port zc.buildout to Python 3. I got pretty far, in fact. Of course, if we wait too long, somebody will make big changes, and all will be messy and the branch will rot and we might as well start over. :-) So I want to avoid that, and get some help on zope.proxy and zc.buildout to finish the ports. The best way to do this is a sprint. And there are loads of small tasks to do as well, such as test zope.hookable and zope.i18nmessage on Plone and ZTK to make sure nothing breaks (even though each modules tests pass), merge and release it. Also finish the Python 3 port of zope.testing/zope.testrunner. All these are small and fairly easy tasks that I'm sure somebody else interested could do. I hope to attend PyCon, so that would be an option. Otherwise we have to do an online sprint, which with irc and skype/google phone should be doable. I'd havetime for that in January, I think. Of course, if people want to come to Krakow for a sprint I would be happy host it. But you'd have to pay for plane tickets yourself. And hotels, unless you want to sleep on my floor. :-) Who would be interested in a sprint, when, where and how? -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Telephone: +48 691 268 328 ___ 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 vs. Python 3 porting roadmap
Oh, and zc.buildout also exposes bugs in Distribute under Python 3, so a new version of Distribute is needed before this can be finished. But that could probably happen quite fast after I get most of the zc.buildout tests running. ___ 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] zope.proxy explanation?
I'm trying to port zope.proxy to Python 3, and most tests seem to work, but investigating those two who doesn't is confusing. The first one is the test to prevent pickling. This works under Python 2, but as I understand it it should work by implementing a __reduce__ function that throws an exception. But that method is never called under Python 2. Instead a pickling error is thrown, but this is because the pickler has no special knowledge about proxies, and then tries to find __reduce__ and fails. Apparently the __reduce__of the proxy isn't found, weirdly enough. In Python 3, the base object now *has* __reduce__, so it *is* found and used, so the test fails. So there is something I'm missing here. It seems to be that two bugs cancel each other out under Python 2, and under Python 3 they don't, and the test fails. //Lennart ___ 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.i18nmessageid/branches/regebro-python3/src/zope/i18nmessageid/messages.txt Paper over different exception type raised under Python3.
Hmm, the tests failed for me without that change under Python 3.1, but pass with it: Weird. How are you running the tests under Python3, BTW? python3 setup.py test ___ 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] Survey: most obscure errors
On Tue, Sep 14, 2010 at 12:00, Marius Gedminas mar...@gedmin.as wrote: What are the most obscure error conditions you've encountered while developing Zopeish[1] applications? [1] ZTK, Grok, Bluebream, the old Zope 3.x KGSes all qualify. I'm talking about situations where the error message/traceback are disconnected from the actual cause. Late answer: The really obscure ones are when there *is no error message*. Common in Plone (which may or may not be zopeish). ___ 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] Class advisors in Python 3
On Fri, Jul 30, 2010 at 13:35, Hanno Schlichting ha...@hannosch.eu wrote: zope.interface contains 2to3 fixers to rewrite them to a class decorator syntax IIRC. Actually, it's in zope.fixers. :) And it's only implements() - @implementor i think. Adapts come with zope.component which isn't ported to Python 3 yet, but the same thing should happen there, yes. -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Python, Zope, Plone blog: http://regebro.wordpress.com/ Telephone: +33 661 58 14 64 ___ 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 / zope.testrunner path forward:
On Tue, Jul 27, 2010 at 13:26, Jonathan Lange j...@mumak.net wrote: Just to be clear, is zope.testing 4.0.0 intended to work with Python 2? Yes. ___ 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] I have loads of tests failing on zc.buildout on trunk
Am I doing something wrong? I have a dedicated python 2.6, and run python2.6 dev.py and then bin/test. -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Python, Zope, Plone blog: http://regebro.wordpress.com/ Telephone: +33 661 58 14 64 ___ 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] I have loads of tests failing on zc.buildout on trunk
On Thu, Jul 22, 2010 at 08:38, Lennart Regebro rege...@gmail.com wrote: Am I doing something wrong? I have a dedicated python 2.6, and run python2.6 dev.py and then bin/test. I looked through the tests again, and some of the tests are clearly an effect of using doctest instead of zope.testing.doctest, I recognize that. I'll try again with zope.testing.doctest, so ignore this mail for a couple of hourse. I'll be back. :-) ___ 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] I have loads of tests failing on zc.buildout on trunk
On Thu, Jul 22, 2010 at 08:40, Lennart Regebro rege...@gmail.com wrote: On Thu, Jul 22, 2010 at 08:38, Lennart Regebro rege...@gmail.com wrote: Am I doing something wrong? I have a dedicated python 2.6, and run python2.6 dev.py and then bin/test. I looked through the tests again, and some of the tests are clearly an effect of using doctest instead of zope.testing.doctest, I recognize that. I'll try again with zope.testing.doctest, so ignore this mail for a couple of hourse. I'll be back. :-) OK, I got that down to one error: bootstrap.py: error: no such option: --setup-source It seems the --setup-source option is gone? I can remove the test... Then I can start updating the tests to using zope.testrunner and doctest as well, that seems to be a couple of extra failing tests there. -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Python, Zope, Plone blog: http://regebro.wordpress.com/ Telephone: +33 661 58 14 64 ___ 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: 38 OK, 17 Failed, 1 Unknown
Well, that was one failure less than yesterday, so at least the new zope.testing release didn't make anything explode. I guess that's because most have version pinning, but there you go. :-) On Thu, Jul 22, 2010 at 12:58, Zope Tests Summarizer zope-te...@epy.co.at wrote: Summary of messages to the zope-tests list. Period Wed Jul 21 12:00:00 2010 UTC to Thu Jul 22 12:00:00 2010 UTC. There were 56 messages: 6 from Zope Tests, 1 from buildbot at enfoldsystems.com, 4 from buildbot at pov.lt, 15 from buildbot at winbot.zope.org, 13 from ccomb at free.fr, 17 from jdriessen at thehealthagency.com. Test failures - Subject: FAILED : Bluebream / Python2.4.6 32bit linux From: ccomb at free.fr Date: Wed Jul 21 22:04:08 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017105.html Subject: FAILED : Bluebream / Python2.5.2 32bit linux From: ccomb at free.fr Date: Wed Jul 21 22:05:50 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017106.html Subject: FAILED : Bluebream / Python2.6.4 32bit linux From: ccomb at free.fr Date: Wed Jul 21 22:05:51 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017107.html Subject: FAILED : winbot / ztk_dev py_244_win32 From: buildbot at winbot.zope.org Date: Wed Jul 21 22:10:34 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017109.html Subject: FAILED : winbot / ztk_dev py_254_win32 From: buildbot at winbot.zope.org Date: Wed Jul 21 22:19:31 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017110.html Subject: FAILED : winbot / ztk_dev py_265_win32 From: buildbot at winbot.zope.org Date: Wed Jul 21 22:28:03 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017111.html Subject: FAILED : winbot / ztk_dev py_265_win64 From: buildbot at winbot.zope.org Date: Wed Jul 21 22:36:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017113.html Subject: FAILED : winbot / ztk_dev py_270_win32 From: buildbot at winbot.zope.org Date: Wed Jul 21 22:45:01 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017114.html Subject: FAILED : winbot / ztk_dev py_270_win64 From: buildbot at winbot.zope.org Date: Wed Jul 21 22:53:36 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017115.html Subject: FAILED : winbot / ztk_10 py_244_win32 From: buildbot at winbot.zope.org Date: Wed Jul 21 23:01:54 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017116.html Subject: FAILED : ZTK 1.0dev / Python2.4.6 Linux 32bit From: ccomb at free.fr Date: Wed Jul 21 23:46:31 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017120.html Subject: FAILED : ZTK 1.0dev / Python2.7.0 Linux 32bit From: ccomb at free.fr Date: Wed Jul 21 23:47:58 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017121.html Subject: FAILED : ZTK 1.0dev / Python2.6.4 Linux 32bit From: ccomb at free.fr Date: Wed Jul 21 23:48:20 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017122.html Subject: FAILED : ZTK 1.0dev / Python2.5.2 Linux 32bit From: ccomb at free.fr Date: Wed Jul 21 23:48:39 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017123.html Subject: FAILED : ZTK 1.0 / Python2.7.0 Linux 32bit From: ccomb at free.fr Date: Thu Jul 22 01:51:03 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017129.html Subject: FAILED : winbot / ZODB_dev py_270_win32 From: buildbot at winbot.zope.org Date: Thu Jul 22 03:12:19 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017133.html Subject: FAILED : winbot / ZODB_dev py_270_win64 From: buildbot at winbot.zope.org Date: Thu Jul 22 04:07:42 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017134.html Unknown --- Subject: [zodb-tests] buildbot failure in Enfold Systems on zodb-trunk-python-2.6-maestro From: buildbot at enfoldsystems.com Date: Thu Jul 22 04:53:32 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017135.html Tests passed OK --- Subject: OK : Zope Buildbot / zope2 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Wed Jul 21 10:54:41 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017094.html Subject: OK : Zope Buildbot / zope2 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Wed Jul 21 10:54:48 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017095.html Subject: OK : Zope Buildbot / zope2 slave-osx From: jdriessen at thehealthagency.com Date: Wed Jul 21 10:54:54 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017096.html Subject: OK : Zope 3.4 Known Good Set / py2.4-64bit-linux From: buildbot at pov.lt Date: Wed Jul 21 21:08:38 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/017097.html Subject: OK : Zope 3.4 Known Good Set / py2.4-32bit-linux From:
[Zope-dev] zope.hookable ported to Python 3
I've ported zope.hookable too, but I don't need it until it's time to port zope.component (and I think the same goes for zope,security which I think is next if I remember correctly), so I'm not merging the branch yet. It's full if ugly Python 3 hacks, as it's a c-extension. Feel free to take a look and complain if you you like. :-) http://svn.zope.org/zope.hookable/branches/regebro-python3/ -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Python, Zope, Plone blog: http://regebro.wordpress.com/ Telephone: +33 661 58 14 64 ___ 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 / zope.testrunner path forward:
On Wed, Jul 21, 2010 at 06:28, Christian Theune c...@gocept.com wrote: I myself prefer having more releases. I like Marius' idea: 3.10 would be good for removing the test runner then 4.0 can be Py3 compatibility. OK, I'll merge and release 3.10 today or tomorrow or so. -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Python, Zope, Plone blog: http://regebro.wordpress.com/ Telephone: +33 661 58 14 64 ___ 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 / zope.testrunner path forward:
On Tue, Jul 20, 2010 at 23:57, Marius Gedminas mar...@gedmin.as wrote: 1. Should there be BBB imports of zope.testrunner into zope.testing? We can do that to get a longer deprecation period, a couple of months isn't very long). *shrug* Nobody said YES! and since it actually requires that zope.testing depends on zope.testrunner to be pracically useful, I think we'll skip it. -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Python, Zope, Plone blog: http://regebro.wordpress.com/ Telephone: +33 661 58 14 64 ___ 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 / zope.testrunner path forward:
On Wed, Jul 21, 2010 at 15:06, Jim Fulton j...@zope.com wrote: Do whatever is easiest for you. One option would be to release as eggs for Python 3 only. That way, you shouldn't be affecting Python 2 users. I've released 3.10.0 now, and will let that simmer a while. I'm on Europython so please mail me if something breaks so I see it. 4.0.0 is ready, but I'll wait with releasing it for a week at least, I only need it to work on my porting of zc.buildout, and I don't need it uploaded to PyPI. :-) -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Python, Zope, Plone blog: http://regebro.wordpress.com/ Telephone: +33 661 58 14 64 ___ 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] zope.testing / zope.testrunner path forward:
I'd like to put down some effort this week during the EuroPython sprint to go forward with zope.testing for Python 3. zope.testing 3.9.5 is already deprecating zope.testing.testrunner, but I need to remove it so that I can port zope.testing to Python 3 without going mad. (zope.testrunner runs on Python 3 already, although installing it fails, because it tries to install zope.testing 3.9.5.) The questions are (some have been discussed before, but I don't remember the outcome): 1. Should there be BBB imports of zope.testrunner into zope.testing? We can do that to get a longer deprecation period, a couple of months isn't very long). 2. Should I release the testrunner-free version before I port to Python 3, or should we do both at once?Doing both at once of course risks more problems than one at a time. On the other hand we might want all changes at once to lessen annoyance. 3. It should be zope.testing 4.0.0, right? -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.com/ +33 661 58 14 64 ___ 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] ./bin/test failing with trunk zope.testing
On Sun, Jul 18, 2010 at 16:58, Jonathan Lange j...@mumak.net wrote: Actually, it turned out to be something of a pebkac. Happy to hear it, zope.testrunner and zope.testing.testrunner *should* be compatible, and if they aren't that is probably a bug. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.com/ +33 661 58 14 64 ___ 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 / zope.testrunner path forward:
On Tue, Jul 20, 2010 at 23:57, Marius Gedminas mar...@gedmin.as wrote: I'm for two separate releases. Release early, release often. Oh, that's not a problem. svn://svn.zope.org/repos/main/zope.testing/branches/regebro-400 Is testrunner free and runs on Python 3 already. It's purely a question of if we want both changes at once or not. :-) -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Python, Zope, Plone blog: http://regebro.wordpress.com/ Telephone: +33 661 58 14 64 ___ 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: 10 OK, 4 Failed, 2 Unknown
On Tue, May 4, 2010 at 00:41, Christophe Combelles cc...@free.fr wrote: Unless I missed something, the ZTK was globally compatible with Python2.4 recently, wasn't it? Do we want the latest changes and Lennart's work to be part of the ZTK 1.0? I think it's OK if they are not. Of course it would be cool if 1.0 does include the latest and greatest, but my changes are mostly aimed at Python 3 compatibility, and ZTK 1.0 will not have that as a whole anyway. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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: 10 OK, 4 Failed, 2 Unknown
On Mon, May 3, 2010 at 20:02, Tres Seaver tsea...@palladion.com wrote:
- - zope.browserpage
- - zope.viewlet
- - zope.contentprovider
- - zope.deferredimport
These tests all fail because as Tres pointed out, Python 2.4 doesn't
set __file__ to the doctest filename in the globals. Zope.browserpage
in turn uses those globals to determine the filename of the
pagetemplate. So, you get an error if you create a browserpage in a
DocTestFile, like so:
ErrorPage = SimpleViewClass(errorFileName, name='error.html')
Passing in file explicitly solves the problem:
ErrorPage = SimpleViewClass(errorFileName, name='error.html',
offering={'__file__': 'README.txt'})
The same thing goes for ViewPagetemplateFile, but there it's called
_prefix instead of offering. Yeah, none of those variable names make
sense.
It can also typically be fixed by passing in __file__ explicitly to the doctest:
def test_suite():
import doctest
filename = os.path.join(os.pardir, 'namedtemplate.txt')
return doctest.DocFileSuite(
filename,
setUp=pageSetUp, tearDown=zope.component.testing.tearDown,
globs={'__file__':
os.path.abspath(os.path.join(os.path.dirname(__file__), filename))}
)
Other options is to make the usage of __file__ lazy, so that it's only
looked up in the globals when accessed. Because I suspect it's not
actually used except when you get errors, but I'm not 100% sure.
So for the time being, I went for passing in __file__ explicitly in
globs. The tests run under Python 2.4 again.
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
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: 10 OK, 4 Failed, 2 Unknown
On Tue, May 4, 2010 at 12:07, Martijn Faassen faas...@startifact.com wrote: For a while already people have been making changes that at least break tests on 2.4. For instance, zope.testing has some facility to pretty print a dictionary that sorts the keys, because Python 2.4's built-in pretty print module apparently doesn't do that yet, meaning random test failures can happen. But people have been updating code to use Python's built-in pretty print facility and this will only be reliable on Python 2.5 and higher. Although that zope.testing facility has been deprecated, as far as I'm aware it's still there... If not maybe it should be reintroduced, we're suppose dto deprecate, not break in this case. In my opinion it's time to drop Python 2.4 support anyway, but it's been going a bit haphazardly by way of bit rot.. Yeah, officially dropping is better than bitrot dropping it, that's for sure. And as mentioned, except for the Bicycle toolkit or whatever the name is, 2.4 is not needed any more. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] Hanno, please update the ZTK
On Mon, May 3, 2010 at 13:22, Martijn Faassen faas...@startifact.com wrote: Wichert Akkerman wrote: Sorry, my mistake. I meant the ZTK release manage group, not the now defunct ZTK steering group, Well, if it's defunct or not is up to the members of the steering group. The steering group created itself, and may disband itself if it so wishes. It has all the right in the world to continue existing, even if the idea is that the ZTK oversight will be done by the release manager team instead. If it's defunct someone better update the documentation. The creation of the release manager team was only recently concluded. To expect zope process documentation to update quickly is unrealistic. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] Hanno, please update the ZTK
On Mon, May 3, 2010 at 15:41, Martijn Faassen faas...@startifact.com wrote: Well, I'm disappointed in the zope documentation process then. Work faster! :) If you don't inform people about this release manager team thingy, you can't rightly expect people like me to care about it. Heh. Martijn, I understand you are just shaking off all the shit that you had to take, but I'm not sure everyone gets the joke. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] Hanno, please update the ZTK
On Mon, May 3, 2010 at 17:30, Martijn Faassen faas...@startifact.com wrote: Answers like read the mailing list archives and we're working on it are legitimate sometimes. But they're also all too easily the answers of a bureaucracy that's stalling things as bureaucracies do. They're not very useful in a constructive discussion. But in this case it's not bureaucracy that's stalling. It's the community readjusting to a large extent to fill the hole that appeared when you stepped aside. And that readjustment will NOT take a couple of days, it will take longer. We will need to keep the ZTK up to date, and I know people are committed to the ZTK so it will be. But we'll need to figure out the process, but that process isn't really done yet, and it's hard to document what doesn't exist. I don't know anything about the fork, but my view of the fork is that of Hanno wants a fork, Hanno can have a fork, as long as he doesn't try to poke anyones eye out with it. If it's a stupid waste of time, it's Hannos stupid waste of time. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] Hanno, please update the ZTK
On Mon, May 3, 2010 at 18:09, Martijn Faassen faas...@startifact.com wrote: Hanno is making releases of packages in the ZTK. So it's not just Hanno's waste of time; it's mine too. Obviously he shouldn't hurt the main ZTK in any way. That would be a problem (even if i missed this incident completely and hence dn't understand what or how things broke). But I think the fork in itself is a red herring. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] summary of suggestions
On Mon, May 3, 2010 at 20:13, Martijn Faassen faas...@startifact.com wrote: Since there are no ZTK releases Grok and BlueBream gain stability by pinning to a particular revision of ztk.cfg (and moving it forward when needed). Zope 2 could easily do the same. If more is needed, then a branch or tag can easily be made. Besides the perennial documentation issues, I also don't see why we couldn't just start releasing the ZTK; instead of pinning to an SVN revision we'd start pinning to an SVN tag (or a release URL with version number in it). What's the holdup, really? Making a ZTK 1.0a seems to be a good idea to me, and should help here. And we don't have to commit to anything, since it's an alpha. We could even call it 0.1, if so desired. :) One objection I can see is that we might end up with quite a few releases in a short period, and it might be nicer to have a more stable base that people can build on. But they could simply pin to one release and stick with it for a while, right? Right. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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: 10 OK, 4 Failed, 2 Unknown
On Mon, May 3, 2010 at 20:02, Tres Seaver tsea...@palladion.com wrote: At least the first one is due to doctests not exposing an '__file__' in their faux-module globals under 2.4. We might need to add Lennart's monkeypatch under 2.4, or else drop 2.4 support altogether. Well, I don't want a monkey-patch product just for 2.4, and the monkeypatches was voted off from zope.testing because they are evil in the first place. The tests might pass __file__ in explicitly, maybe? Otherwise dropping 2.4 is probably the only reasonable option. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] summary of suggestions
On Mon, May 3, 2010 at 21:57, Martijn Faassen faas...@startifact.com wrote: I think the list needs to commit to something If it needs to commit to what packages are included, then there is no reason to call it an alpha, and also, we can't do it now. So then the status persists with the users of ZTK having to use trunk, which means we can't just change versions all the time. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] Test fixture failure zope.interface under Python 3.1
On Sun, May 2, 2010 at 18:37, Jens Vagelpohl j...@dataflake.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all (and especially Lennart),
I need a quick sanity check. Trying to test a package of mine for Python
3 compatibility I built Python 3.1.2 and installed distribute into it.
My package depends on zope.interface. I am executing...
$ python3.1 setup.py test
It tries to install zope.interface, but fails with this traceback:
Running zope.interface-3.6.0/setup.py -q bdist_egg --dist-dir
/var/folders/ZD/ZDGPtbYeGkqB4K7rOkPK4U+++TI/-Tmp-/easy_install-8LJGXC/zope.interface-3.6.0/egg-dist-tmp-xVkH07
Traceback (most recent call last):
File setup.py, line 58, in module
snip
File
/usr/local/lib/python3.1/site-packages/distribute-0.6.10-py3.1.egg/setuptools/sandbox.py,
line 33, in lambda
{'__file__':setup_script, '__name__':'__main__'})
File setup.py, line 80, in module
That's not very informative at all. Trying to debug this further I
download zope.interface 3.6.0 and attempt to run its tests using
setup.py test, which gives a little more information:
Traceback (most recent call last):
File setup.py, line 80, in module
+ '\n' +
File setup.py, line 65, in read
return open(os.path.join(os.path.dirname(__file__), *rnames)).read()
File /usr/local/lib/python3.1/encodings/ascii.py, line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
290: ordinal not in range(128)
The issue is a non-ASCII character in the Changelog:
snip
- - Added support for Python 3.1. Contributors:
Lennart Regebro
Martin v Löwis
Thomas Lotze
Wolfgang Schnerring
/snip
Removing the ö I can run the tests and buildout. Question: Is this an
issue with my particular sandbox? The Python 3.1 I use is a fresh build
and I don't manipulate the default encoding anywhere.
Hmm, I do not get that issue, but maybe the default encoding is
different on different systems? What are you using?
I'll change that to Loewis in any case, having non-ascii test like
that is definitely a no-no. You would think that after 30 years of
these kinds of problems I would have learnt, but apparently not. :)
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
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 )
