On Mar 6, 2009, at 2:18 AM, Shane Hathaway wrote:
Jim Fulton wrote:
- It's not well enough documented. While I think there's merit in
doing some things at the WSGI level, I remain pretty happy with the
publication interface for separatating generic publisher functions
from
Jim Fulton wrote:
I'd rather leave zope.publsiher more or less alone, but develop a new
thing that has the basic/core functionality we need and refactor
zope.publisher to use that. I'd also like to use or be compatible with
WebOb on that. I'd prefer to do this at PyCon where I'll have time
Hello,
since Dan Korostelev commented on my
https://bugs.launchpad.net/zope3/+bug/338136
saying I should take it to the mailing list, here goes:
zope.publisher.interfaces.browser.IBrowserView inherits from
zope.component.interfaces.IView, which actually is
zope.component.bbb.interfaces.IView --
Summary of messages to the zope-tests list.
Period Thu Mar 5 12:00:00 2009 UTC to Fri Mar 6 12:00:00 2009 UTC.
There were 6 messages: 6 from Zope Tests.
Tests passed OK
---
Subject: OK : Zope-2.10 Python-2.4.6 : Linux
From: Zope Tests
Date: Thu Mar 5 20:22:20 EST 2009
URL:
2009/3/5 Benji York be...@zope.com:
On Wed, Mar 4, 2009 at 6:36 PM, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Baiju M wrote:
On Tue, Mar 3, 2009 at 2:35 PM, Dan Korostelev nad...@gmail.com wrote:
2009/3/2 Tres Seaver
Hi there,
Tres Seaver wrote:
[snip]
Actually, we don't need an upgrade path. We can just leave a
'meta.zcml' in zope.component which includes the new locations. That
file will be *inert*, and doesn't therefore need testing, because none
of the directive implementations will be present.
Hey,
Wolfgang Schnerring wrote:
since Dan Korostelev commented on my
https://bugs.launchpad.net/zope3/+bug/338136
saying I should take it to the mailing list, here goes:
zope.publisher.interfaces.browser.IBrowserView inherits from
zope.component.interfaces.IView, which actually is
Hanno Schlichting wrote:
[snip interesting analysis]
I'd say that the deprecation system in its current form is well suited
and has worked for the more silent times. It is not suited for covering
the changes of a major new version.
I'm not sure it has worked so well. I've seen code in zope.*
Roger Ineichen wrote:
Hi Martijn
Betreff: [Zope-dev] deprecating the deprecation system?
Hi there,
Perhaps it's time to deprecate the deprecation system.
Why?
* I've had good experience in the Grok project with just
noting changes that might break code in the upgrade notes for
Grok
Hey,
Laurence Rowe wrote:
[snip]
It seems there is a 'tests_require'
One reason that isn't used is that apparently there is no way for us to
dig up this information in the way our test runner needs, unlike extras
requires.
Regards,
Martijn
___
Hi there,
Thanks Gary for sketching our the zc.async usecase. Note that zc.async
isn't in the Zope Framework at this point in time so it wouldn't be
directly affected by this policy, but it's still a useful usecase of course.
We seem to have a split community here...
I care about this as it
Hey,
Since nobody spoke up in favor of ZCML slugs, I'm going to record an
official policy they can be removed.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML
On Fri, Mar 6, 2009 at 9:52 AM, Martijn Faassen faas...@startifact.com wrote:
Since nobody spoke up in favor of ZCML slugs, I'm going to record an
official policy they can be removed.
+1
--
Benji York
Senior Software Engineer
Zope Corporation
___
On Mar 6, 2009, at 9:50 AM, Martijn Faassen wrote:
Hi there,
Thanks Gary for sketching our the zc.async usecase. Note that zc.async
isn't in the Zope Framework at this point in time so it wouldn't be
directly affected by this policy, but it's still a useful usecase of
course.
Right,
Hey,
No volunteers to help produce such a list?
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
Martijn Faassen wrote:
The deprecation system is a system that is intended to help developers
upgrade their code and that allows us to remove certain deprecated
features after a while.
* we have quite a few of these developers who are not happy about the
deprecation system.
* we've
Hey,
Jim Fulton wrote:
[snip]
I'd rather leave zope.publsiher more or less alone, but develop a new
thing that has the basic/core functionality we need and refactor
zope.publisher to use that.
I had the impression Shane was doing that; i.e. building zope.pipeline
factoring bits out of
Hey Baiju,
Thanks for the reminder. I'm really going to do my best not to get
dragged into this again though, so I'm going to stay away from the
project. You should try emailing Aroldo though.
I just recommend you get a mentor coordinator who gets reports every
week from all the mentors and
Hey,
Dan Korostelev wrote:
[snip]
Well, I simply didn't mention the removal of zcml slug, I know that
it's not related to zpkg.
Bunch of nitpickers we are. :)
Anyway, removing zcml slugs is now official policy. Carry on!
Regards,
Martijn
___
Hi.
Martijn Faassen wrote:
No volunteers to help produce such a list?
Attached you'll find my suggestion for the list. It is based on the
Zope2/Plone perspective: Which packages do those two actually use from
all the zope.* packages.
I suspect the set will initially be a bit larger to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shane Hathaway wrote:
Jim Fulton wrote:
- It's not well enough documented. While I think there's merit in doing
some things at the WSGI level, I remain pretty happy with the
publication interface for separatating generic publisher functions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hi there,
Tres Seaver wrote:
[snip]
Actually, we don't need an upgrade path. We can just leave a
'meta.zcml' in zope.component which includes the new locations. That
file will be *inert*, and doesn't therefore need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hey,
Laurence Rowe wrote:
[snip]
It seems there is a 'tests_require'
One reason that isn't used is that apparently there is no way for us to
dig up this information in the way our test runner needs, unlike extras
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hey,
Wolfgang Schnerring wrote:
since Dan Korostelev commented on my
https://bugs.launchpad.net/zope3/+bug/338136
saying I should take it to the mailing list, here goes:
zope.publisher.interfaces.browser.IBrowserView
Tres Seaver wrote:
[snip]
I'd say leave the extra shim in place for the time being. We can then
see about getting rid of that at some point.
In any package where I create a backward incompatibility, I will
certainly document it clearly, with instructions on how to update
dependent packages.
Martijn Faassen wrote:
Jim Fulton wrote:
[snip]
I'd rather leave zope.publsiher more or less alone, but develop a new
thing that has the basic/core functionality we need and refactor
zope.publisher to use that.
I had the impression Shane was doing that; i.e. building zope.pipeline
On Wednesday 04 March 2009, Martijn Faassen wrote:
But I'm sure we can find more packages to evict from the Zope Framework.
Martijn, I was just planning to split up the KGS in the next week and see what
happens. But if I have a list to start out with I'll take it. :-)
Regards,
Stephan
--
2009/3/6 Tres Seaver tsea...@palladion.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hey,
Wolfgang Schnerring wrote:
since Dan Korostelev commented on my
https://bugs.launchpad.net/zope3/+bug/338136
saying I should take it to the mailing list, here goes:
Stephan Richter wrote:
On Wednesday 04 March 2009, Martijn Faassen wrote:
But I'm sure we can find more packages to evict from the Zope Framework.
Martijn, I was just planning to split up the KGS in the next week and see
what
happens. But if I have a list to start out with I'll take it.
2009/3/6 Tres Seaver tsea...@palladion.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hey,
Laurence Rowe wrote:
[snip]
It seems there is a 'tests_require'
One reason that isn't used is that apparently there is no way for us to
dig up this information in the
Dan Korostelev wrote:
2009/3/6 Tres Seaver tsea...@palladion.com:
[snip]
I just undeprecated IView and the other 'bbb' interfaces for exactly
this reason: if core packages still use them five years later, then the
deprecation loses.
I doubt that the IView and (especially)
On Mar 6, 2009, at 4:30 PM, Dan Korostelev wrote:
2009/3/6 Tres Seaver tsea...@palladion.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hey,
Laurence Rowe wrote:
[snip]
It seems there is a 'tests_require'
One reason that isn't used is that apparently there
On Friday 06 March 2009, Martijn Faassen wrote:
I'd definitely be in favor of trying this instead of undeprecating them.
zope.component has no business knowing about views and such.
+1
Regards,
Stephan
--
Stephan Richter
Web Software Design, Development and Training
Google me. Zope Stephan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dan Korostelev wrote:
2009/3/6 Tres Seaver tsea...@palladion.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hey,
Laurence Rowe wrote:
[snip]
It seems there is a 'tests_require'
One reason that isn't used is that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary Poster wrote:
(http://pypi.python.org/pypi/eggtestinfo)
I skimmed the docs, but they were written generically, so I couldn't
confirm: Tres, is this the thing that lets you run ``setup.py test``
against zope.testing, if you configure it
35 matches
Mail list logo
