On Tue, Dec 29, 2009 at 07:38:16AM +0100, Fabio Tranchitella wrote:
* 2009-12-28 13:31, Marius Gedminas wrote:
I think you mean assumes doctest is imported in zope.testing's
__init__.py.
There's no difference between modules or packages for the import
statement, witness
Yes, you are
Summary of messages to the zope-tests list.
Period Mon Dec 28 12:00:00 2009 UTC to Tue Dec 29 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: Mon Dec 28 20:55:03 EST 2009
URL:
Hi,
I was going through Zope 2 source code today. There are 20+ top-level
packages specific to Zope 2. Would it be useful if we move those packages
to a top-level namespace package. I mean something similar to:
zope.app.*, grokcore.*, repoze.bfg.* ?
Well, I don't have any name suggestion
On Tue, Dec 29, 2009 at 6:40 PM, Baiju M mba...@zeomega.com wrote:
Hi,
I was going through Zope 2 source code today. There are 20+ top-level
packages specific to Zope 2. Would it be useful if we move those packages
to a top-level namespace package. I mean something similar to:
On Tue, Dec 29, 2009 at 2:10 PM, Baiju M mba...@zeomega.com wrote:
I was going through Zope 2 source code today. There are 20+ top-level
packages specific to Zope 2. Would it be useful if we move those packages
to a top-level namespace package. I mean something similar to:
zope.app.*,
Hey,
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hanno Schlichting wrote:
The ZTK no longer contains any
zope.app packages with one exception.
I'm not sure I understand the details of what you did.
I think we should be careful to just remove
Following the guide at
http://docs.zope.org/zope2/releases/2.12/INSTALL.html#buildout-instances
I get the following error:
m...@platonas:~/src/akl-website-z2.12-experiment $ python2.5 bootstrap.py
Creating directory '/home/mg/src/akl-website-z2.12-experiment/bin'.
Creating directory
Hanno Schlichting wrote:
On Mon, Dec 28, 2009 at 10:57 PM, Martijn Faassen
faas...@startifact.com wrote:
Hanno Schlichting wrote:
The ZTK no longer contains any zope.app packages.
I think we should be careful to just remove the zope.app packages from
the ZTK entirely. I.e. we should maintain
2009/12/29 Marius Gedminas mar...@gedmin.as:
I get the following error:
File build/bdist.linux-i686/egg/Zope2/utilities/load_site.py, line 248
body = (htmlheadtitledtml-var title_or_id/title
^
SyntaxError: EOL while
On Tue, Dec 29, 2009 at 03:30:20PM +0100, Hanno Schlichting wrote:
2009/12/29 Marius Gedminas mar...@gedmin.as:
I get the following error:
File build/bdist.linux-i686/egg/Zope2/utilities/load_site.py, line 248
body = (htmlheadtitledtml-var title_or_id/title
On 12/29/09 15:28 , Martijn Faassen wrote:
Hanno Schlichting wrote:
On Mon, Dec 28, 2009 at 10:57 PM, Martijn Faassen
faas...@startifact.com wrote:
Hanno Schlichting wrote:
The ZTK no longer contains any zope.app packages.
I think we should be careful to just remove the zope.app packages
Wichert Akkerman wrote:
I don't know what you mean with pre-ZTK applications. Are those Zope 2
applications? Zope 3? Grok?
Yes, yes, yes. You know, us, who get together here on zope-dev to work
together.
All of those can keep working as long as
Zope 2, Zope 3 and Grok make sure they
On 12/29/09 16:23 , Martijn Faassen wrote:
Wichert Akkerman wrote:
but I do not think it is fair
to shift that responsibility to others by forcing zope.app.* into the
ZTK.
That's not what happened. What just happened that the responsibility was
*forced out* of the ZTK. I'm all
Hi there,
Fastest summary:
* removing responsibility from the ZTK, yes, but not like this.
Quick summary:
* I agree we should dump most, perhaps all, of the code that is in
zope.app.* from the ZTK. Most of these packages will likely eventually
become unmaintained.
* We as a community have a
On 12/29/09 16:25 , Martijn Faassen wrote:
Earlier this year we decided to refocus our efforts on the ZTK, a
leaner, meaner Zope 3 with a different focus, which has code that we
really use, no UI, and with cleaner dependencies.
I feel a disconnect here. As I see it the ZTK is not a 'leaner,
On 12/29/09 16:39 , Wichert Akkerman wrote:
On 12/29/09 16:25 , Martijn Faassen wrote:
Earlier this year we decided to refocus our efforts on the ZTK, a
leaner, meaner Zope 3 with a different focus, which has code that we
really use, no UI, and with cleaner dependencies.
I feel a disconnect
Marius Gedminas wrote:
Well. You didn't specify a database file in your zope,conf it seems.
Without a declaration, there's no database.
Makes sense, in a rather user-unfriendly way. May I suggest the
documentation be amended to supply a closer-to-working zope.conf?
I'm referring to this
Wichert Akkerman wrote:
On 12/29/09 16:25 , Martijn Faassen wrote:
Earlier this year we decided to refocus our efforts on the ZTK, a
leaner, meaner Zope 3 with a different focus, which has code that we
really use, no UI, and with cleaner dependencies.
I feel a disconnect here. As I see it
Hi,
I hate DeprecationWarnings at the best of times, since no one actually
does anything about them until whatever they're bleating about is
actually gone anyway, but zope.testing has outdone itself.
Whoever introduced that warning, if you're going to do so, please solve
any problems with
On Tue, Dec 29, 2009 at 10:39 AM, Wichert Akkerman wich...@wiggy.net wrote:
It seems that you want to have a 'ZTK+' which aims to be backwards
compatible with Zope 3 but is somehow not Zope 3 itself. That is
something that not everybody appears to be interested in judging by the
lack of
On 12/29/09 17:00 , Martijn Faassen wrote:
Wichert Akkerman wrote:
On 12/29/09 16:25 , Martijn Faassen wrote:
Earlier this year we decided to refocus our efforts on the ZTK, a
leaner, meaner Zope 3 with a different focus, which has code that we
really use, no UI, and with cleaner
I don't think the ZTK as defined by the historical constraints under
discussion here has much attraction for a large number of folks who are
otherwise willing to put effort into maintaining Zope packages.
For these folks, any reduction in number of dependencies and test maintenance
is a net
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I started documenting the Zope 2 release process (Zope 2.12 only for now):
svn+ssh://svn.zope.org/repos/main/zope2docs/trunk/maintenance/index.rst
Hints and feedback appreciated.
Andreas
- --
ZOPYX Ltd. Co KG \ zopyx group
Charlottenstr.
On Tue, Dec 29, 2009 at 6:40 PM, Andreas Jung li...@zopyx.com wrote:
I started documenting the Zope 2 release process (Zope 2.12 only for now):
svn+ssh://svn.zope.org/repos/main/zope2docs/trunk/maintenance/index.rst
Hints and feedback appreciated.
Cool. Looks quite good already. You could
Fred Drake wrote:
It's interesting to note that Python 2.6's doctest doesn't use
universal newlines, but zope.testing.doctest.
Good think we haven't just deprecated zope.testing.doctest and defecated
on zope.testing in the process...
...oh wait.
Interestingly, the doctests I referred to
On Tue, Dec 29, 2009 at 03:59:07PM +, Chris Withers wrote:
Marius Gedminas wrote:
Well. You didn't specify a database file in your zope,conf it seems.
Without a declaration, there's no database.
Makes sense, in a rather user-unfriendly way. May I suggest the
documentation be
On Tue, Dec 29, 2009 at 04:04:34PM +, Chris Withers wrote:
I hate DeprecationWarnings at the best of times, since no one actually
does anything about them until whatever they're bleating about is
actually gone anyway, but zope.testing has outdone itself.
Some background, because you're
Wichert Akkerman wrote:
[snip]
You are ignoring my point though: why should the ZTK have to be burdened
with trying to be backwards compatible with something that it never was?
Why are you insisting on putting Zope3 in it?
We should not remove it until we have a good way to upgrade people
On Tue, Dec 29, 2009 at 9:43 PM, Marius Gedminas mar...@gedmin.as wrote:
On Tue, Dec 29, 2009 at 03:59:07PM +, Chris Withers wrote:
Marius Gedminas wrote:
It'd be even better if there was a command I could run to generate an
up-to-date default zope.conf, like mkzopeinstance does. Is there
Chris McDonough wrote:
I don't think the ZTK as defined by the historical constraints under
discussion here has much attraction for a large number of folks who are
otherwise willing to put effort into maintaining Zope packages.
For these folks, any reduction in number of dependencies and
On Tue, Dec 29, 2009 at 9:54 PM, Martijn Faassen faas...@startifact.com wrote:
And let's please not turn this around: I'm not putting anything *in*.
Something was *removed*. Let's remove it responsibly. Not just disclaim
responsibility and drop it all.
So far I defined the ZTK based on what we
Fred Drake wrote:
On Tue, Dec 29, 2009 at 10:39 AM, Wichert Akkerman wich...@wiggy.net wrote:
It seems that you want to have a 'ZTK+' which aims to be backwards
compatible with Zope 3 but is somehow not Zope 3 itself. That is
something that not everybody appears to be interested in judging by
Wichert Akkerman wrote:
On 12/29/09 16:23 , Martijn Faassen wrote:
Wichert Akkerman wrote:
but I do not think it is fair
to shift that responsibility to others by forcing zope.app.* into the
ZTK.
That's not what happened. What just happened that the responsibility was
*forced
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hanno Schlichting wrote:
On Mon, Dec 28, 2009 at 10:57 PM, Martijn Faassen
faas...@startifact.com wrote:
Hanno Schlichting wrote:
The ZTK no longer contains any zope.app packages.
I think we should be careful to just
Hi there,
Let me sketch out some ideas for a plan:
* we create a new project, zopeapp, with the same structure as the
zopetoolkit (sans documentation)
* we pull the zope.app.* packages from the ZTK and move them into zopeapp.
* we make sure we have a way to regularly run the zopeapp tests in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Baiju M wrote:
On Tue, Dec 29, 2009 at 6:40 PM, Baiju M mba...@zeomega.com wrote:
Hi,
I was going through Zope 2 source code today. There are 20+ top-level
packages specific to Zope 2. Would it be useful if we move those packages
to a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wichert Akkerman wrote:
On 12/29/09 16:25 , Martijn Faassen wrote:
Earlier this year we decided to refocus our efforts on the ZTK, a
leaner, meaner Zope 3 with a different focus, which has code that we
really use, no UI, and with cleaner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Wichert Akkerman wrote:
[snip]
You are ignoring my point though: why should the ZTK have to be burdened
with trying to be backwards compatible with something that it never was?
Why are you insisting on putting Zope3 in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Chris McDonough wrote:
I don't think the ZTK as defined by the historical constraints under
discussion here has much attraction for a large number of folks who are
otherwise willing to put effort into maintaining Zope
On Tue, Dec 29, 2009 at 4:04 PM, Martijn Faassen faas...@startifact.com wrote:
But right now we need to provide some guidance for how people can move
away from these packages in a sane manner. And we should make sure we
continue to test the zope.app.* packages when we make ZTK changes, for
the
Hanno Schlichting wrote:
On Tue, Dec 29, 2009 at 9:54 PM, Martijn Faassen faas...@startifact.com
wrote:
And let's please not turn this around: I'm not putting anything *in*.
Something was *removed*. Let's remove it responsibly. Not just disclaim
responsibility and drop it all.
So far I
On Tue, Dec 29, 2009 at 09:56:01PM +0100, Hanno Schlichting wrote:
On Tue, Dec 29, 2009 at 9:43 PM, Marius Gedminas mar...@gedmin.as wrote:
On Tue, Dec 29, 2009 at 03:59:07PM +, Chris Withers wrote:
Marius Gedminas wrote:
It'd be even better if there was a command I could run to
Tres Seaver wrote:
[snip]
The reality is that the zope.app.* packages don't fit the mission of the
ZTK: they aren't widely-reusable libraries, but pieces of a particular
appserver / framework. The other reality is that nobody is stepping up
to do the work to maintain that appserver.
I
* 2009-12-29 21:54, Marius Gedminas wrote:
* Fabio Tranchitella is working to make the zope.testing.doctest
deprecation warning useful by doing scary things like converting
zope.testing.doctest from a module into a package that has all the
code in __init__.py. He asked for a
On Tue, Dec 29, 2009 at 10:54:03PM +0200, Marius Gedminas wrote:
On Tue, Dec 29, 2009 at 04:04:34PM +, Chris Withers wrote:
I hate DeprecationWarnings at the best of times, since no one actually
does anything about them until whatever they're bleating about is
actually gone anyway,
Hi there,
Tres Seaver wrote:
[snip]
Who is upgrading? There are not historical users of the ZTK, only users
of package sets with greater or lesser intersections with the ZTK.
[snip]
You are acting like we have code in the wild which needs to upgrade from
some released version of the ZTK to
On Tue, Dec 29, 2009 at 10:53 PM, Marius Gedminas mar...@gedmin.as wrote:
Ah, but then why The Official Zope 2.12 Installation Guide at
http://docs.zope.org/zope2/releases/2.12/INSTALL.html#buildout-instances
doesn't even mention plone.recipe.zope2instance?
Should it? The namespace of the
Fred Drake wrote:
On Tue, Dec 29, 2009 at 4:04 PM, Martijn Faassen faas...@startifact.com
wrote:
But right now we need to provide some guidance for how people can move
away from these packages in a sane manner. And we should make sure we
continue to test the zope.app.* packages when we make
On Tue, Dec 29, 2009 at 22:54, Martijn Faassen faas...@startifact.com wrote:
Because we have a ton of installed base out there
Do we? I think the debate is somewhat confused here, or possibly it's
only me. :)
It seems to be two separate issues here:
1. Including these packages in the ZTK.
2.
On Tue, Dec 29, 2009 at 23:11, Martijn Faassen faas...@startifact.com wrote:
I'm looking at this from the perspective of the discontinuity we will
introduce for existing users of the libraries that are now in the Zope
Toolkit but were formerly presented as Zope 3, and the guidance we offer
for
On Tue, Dec 29, 2009 at 11:11:20PM +0100, Hanno Schlichting wrote:
On Tue, Dec 29, 2009 at 10:53 PM, Marius Gedminas mar...@gedmin.as wrote:
Ah, but then why The Official Zope 2.12 Installation Guide at
http://docs.zope.org/zope2/releases/2.12/INSTALL.html#buildout-instances
doesn't even
Hey,
Tres Seaver wrote:
[snip]
You need to identify whose ox is being gored here by dropping those
packages: I don't see anybody but you arguing for their inclusion. In
particular, I don't see anybody who knows *which* zope.app packages they
need, and has a credible argument for why those
Lennart Regebro wrote:
[snip]
What difference would there be between a zopeapp KGS and a Zope3 KGS?
Not much. More sharing between Grok, Zope 3 and Zope 2? Explicitly aimed
at supporting backwards compatibility and upgrade path only?
We've been maintaining something close to a zopeapp KGS
Lennart Regebro wrote:
On Tue, Dec 29, 2009 at 22:54, Martijn Faassen faas...@startifact.com wrote:
Because we have a ton of installed base out there
Do we? I think the debate is somewhat confused here, or possibly it's
only me. :)
I agree that the debate is confused. No one intends to
Hey,
Martijn Faassen wrote:
Let me sketch out some ideas for a plan:
* we create a new project, zopeapp, with the same structure as the
zopetoolkit (sans documentation)
I've created such a project here, based on the zope.app* stuff that was
in the ZTK.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hanno Schlichting wrote:
On Tue, Dec 29, 2009 at 9:54 PM, Martijn Faassen faas...@startifact.com
wrote:
And let's please not turn this around: I'm not putting anything *in*.
Something was *removed*. Let's remove it
Marius Gedminas wrote:
* Meanwhile there are discussions about issues switching from old
zope.testing.doctest to stdlib's doctest with Windows and newlines.
* I'd rather revert back the state of things as
of zope.testing 3.8.4 with the legacy zope.testing.doctestunit
imports
On Tue, Dec 29, 2009 at 10:55:37PM +0100, Fabio Tranchitella wrote:
* 2009-12-29 21:54, Marius Gedminas wrote:
* Fabio Tranchitella is working to make the zope.testing.doctest
deprecation warning useful by doing scary things like converting
zope.testing.doctest from a module into
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fred Drake wrote:
On Tue, Dec 29, 2009 at 4:04 PM, Martijn Faassen faas...@startifact.com
wrote:
But right now we need to provide some guidance for how people can move
away from these packages in a sane manner. And we should make sure we
Marius Gedminas wrote:
Or we could put a sample zope.conf somewhere on the web (heck, in svn is
fine, using those nice *checkout* urls we've already used for
downloading buildout's bootstrap.py or the Zope 2.12.2 versions.cfg).
Sphinx also supports the ability to insert a link to a file.
Maybe
Hanno Schlichting wrote:
Well, either you use mkzopeinstance, which indeed generates an
instance for you with all things included, or if you use buildout you
use a recipe like plone.recipe.zope2instance, in which case all it
takes is:
[instance]
recipe = plone.recipe.zope2instance
eggs =
On Tue, Dec 29, 2009 at 11:28 PM, Marius Gedminas mar...@gedmin.as wrote:
What do y'all Zope-2-maintainer-people think about this patch?
[...]
Looks good.
I'll take that as a +0.
Please do.
Thanks,
Hanno
___
Zope-Dev maillist - Zope-Dev@zope.org
Hanno Schlichting wrote:
To be honest the reason that recipe isn't mentioned there, is because
Chris Withers worked on that section and didn't feel like it belongs
there. And nobody else cared a great deal.
Exactly. That section is for people who are moving existing Zope
instances to 2.12,
Marius Gedminas wrote:
What do y'all Zope-2-maintainer-people think about this patch?
Index: doc/INSTALL.rst
===
--- doc/INSTALL.rst (revision 107265)
+++ doc/INSTALL.rst (working copy)
@@ -136,11 +136,16 @@
Marius Gedminas wrote:
+1 for all the changes, but AFAICS if people move from
zope.testing.doctest to stdlib's doctest they lose at least two things:
* custom doctest exception formatting
* support for the INTERPRET_FOOTNOTES feature
and since zope.testing.doctest still reimplements
So, what's the way forward for existing Zope 3.4 (KGS) users?
Rewrite our apps so we don't depend on anything in zope.app and switch
to the ZTK?
Band together and release a Zope 3.5 KGS, which would be a strict
superset of the ZTK 1.0?
Band together and release a ZopeApp 1.0 KGS which would be
On Tue, Dec 29, 2009 at 4:19 PM, Martijn Faassen faas...@startifact.com wrote:
Let me sketch out some ideas for a plan:
Thankfully you started getting this done while I was distracted from
my email by a meeting. :-) I'll send this anyway, since there's
probably a few points of contention
Tres Seaver wrote:
Martijn Faassen wrote:
[snip]
The ZTK cannot be an excuse to just drop support for a large part of the
existing users of the ZTK. It's a *means* to do so.
What existing users does the ZTK have?
I'll rewrite that:
The ZTK cannot be an excuse to just drop support for a
Hey,
Marius Gedminas wrote:
So, what's the way forward for existing Zope 3.4 (KGS) users?
Rewrite our apps so we don't depend on anything in zope.app and switch
to the ZTK?
That's not possible as far as I can see, as the Zope 3.4 KGS doesn't
support this. No zope.container yet, for
On Tue, Dec 29, 2009 at 6:11 PM, Martijn Faassen faas...@startifact.com wrote:
* the ZTK is new, therefore the ZTK doesn't need to care about Zope 3 at
all.
I'm strongly in this camp. The other camps can readily be supported
on top of this view of the ZTK by providing new names for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
We have three perspectives:
* the ZTK is new, therefore the ZTK doesn't need to care about Zope 3 at
all.
+1
* the ZTK is a renamed, refocused Zope 3, therefore the ZTK needs to
care about Zope 3.
- -1
* both: the
Hi there,
Fred Drake wrote:
On Tue, Dec 29, 2009 at 4:19 PM, Martijn Faassen faas...@startifact.com
wrote:
Let me sketch out some ideas for a plan:
[snip]
* we make sure we have a way to regularly run the zopeapp tests in
conjunction with the ZTK.
-1 (not the problem of the ZTK
On Wed, Dec 30, 2009 at 12:11 AM, Martijn Faassen
faas...@startifact.com wrote:
I think a zopeapp KGS that will help them transition existing code from
Zope 2.12 to Zope 2.13 in working condition would be helpful to Zope 2
users.
Not really. Zope 2.12 is exactly that transitionary release
On Tue, Dec 29, 2009 at 10:50:23PM +, Chris Withers wrote:
Marius Gedminas wrote:
Now the using buildout section of INSTALL.rst leaves the user to write
one completely from scratch
Anyone using that section of the docs should be happy doing that ;-)
without any tool support or
Hanno Schlichting wrote:
On Wed, Dec 30, 2009 at 12:11 AM, Martijn Faassen
faas...@startifact.com wrote:
I think a zopeapp KGS that will help them transition existing code from
Zope 2.12 to Zope 2.13 in working condition would be helpful to Zope 2
users.
Not really. Zope 2.12 is exactly
On Wed, Dec 30, 2009 at 12:55 AM, Martijn Faassen
faas...@startifact.com wrote:
Hanno Schlichting wrote:
Not really. Zope 2.12 is exactly that transitionary release defining a
KGS for everything that was included in Zope 2.11 (~3.4.1).
Ah, I didn't realize Zope 2.12 was already based on an
Hanno Schlichting wrote:
[snip explanation of current Zope 2 and Plone plans, thanks]
So the two main upgrade paths we have are Zope 3.3.2 to ZTK 0.5. And
then at some point in maybe 12 to 18 months a ZTK 0.5 to ZTK x.y
upgrade. This also means that an actual ZTK release, that is done
anywhere
On Wed, Dec 30, 2009 at 1:46 AM, Martijn Faassen faas...@startifact.com wrote:
Assuming ZTK x.y won't have zope.app packages, this means that those
upgrading to Zope 2.13 might be helped by a list of working versions of
those zope.app.* packages (such as the one in zopeapp), or am I wrong?
Of
78 matches
Mail list logo
