Hey,
Dan Korostelev wrote:
2009/2/25 Martijn Faassen faas...@startifact.com:
I hope in fact zope.app.* will soon become a dumping ground for
deprecated packages providing legacy ZMI support. Of course that will
need the consensus that the ZMI *is* legacy software. I think do we
already have
Shane Hathaway wrote:
Dan Korostelev wrote:
Also, how easy is to integrate existing non-zopeish WSGI middlewares
into the zope.pipeline? Like some resource injectors or XHTML slimmers
and so on. It would be really great to be able to do that with single
ZCML directive.
You can do that with
Hey,
Tres Seaver wrote:
[snip]
In general, if you need full-on backward compatibility with the existing
behavior of Zope2 / Zope3 / Grok, switching to a paste-driven WSGI
pipeline doesn't gain you much speed (but it is not a loss, either).
If, for a given application, you can relax the BBB
Hey,
Shane Hathaway wrote:
Martin Aspeli wrote:
[snip]
create_request -- should this maybe have some compatibility with WebOb
requests?
I've looked at WebOb, and my impression is that Zope requests and WebOb
requests serve completely different purposes. A Zope request is
essentially
Shane Hathaway wrote:
Log message for revision 97183:
New library for OpenID auth in Zope 3
Changed:
A zope.app.openidconsumer/
One question: why is this in zope.app? I think there's a consensus we're
trying to pull as much from zope.app as possible.
Is this going to provide a
Hey Shane,
+1 on separating out zope.publisher.interfaces, as it seems low-hanging
fruit.
Shane Hathaway wrote:
It is less clear what we should do with BrowserView and BrowserPage.
They depend on zope.location, unlike the rest of zope.publisher, so they
don't really fit there. Perhaps
Jim Fulton wrote:
On Feb 24, 2009, at 3:08 AM, Shane Hathaway wrote:
I've been working on the dependencies to and from zope.publisher.
Refining the dependencies should make it easier to integrate
zope.pipeline when it's ready.
Can you elaborate on this a bit?
He has, though perhaps not
Hey,
On Tue, Feb 24, 2009 at 6:33 PM, Stephan Richter
srich...@cosmos.phy.tufts.edu wrote:
In general I am worried that we are creating too many packages. However, here
is my order of importance:
1. Minimize dependencies.
2. Minimize packages.
+1
I think on the longer term better
Hi there,
Hanno Schlichting wrote:
[snip]
P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for the
dependency graph ;)
That's a cool resource! (the general dependencies folder there)
Are you removing indirect dependencies before generating the graphs? I
think it is valuable
Hey,
Shane Hathaway wrote:
[snip]
After thinking this over last night, I realize that the idea to move
BrowserView, BrowserPage, and TestRequest is driven by the desire to
clarify the dependency graph. That's more complex than what I'm trying
to do and I don't think I need to do that for
Hi there,
I hope in fact zope.app.* will soon become a dumping ground for
deprecated packages providing legacy ZMI support. Of course that will
need the consensus that the ZMI *is* legacy software. I think do we
already have a consensus that packages that provide other useful
functionality
Jim Fulton wrote:
On Feb 24, 2009, at 12:33 PM, Hanno Schlichting wrote:
P.S. See http://hannosch.eu/dependencies/zope/zope.publisher.svg for
the
dependency graph ;)
That's cool, although wildly inaccurate.
What's wildly inaccurate about it? Missing transitive dependencies or
Hey,
On Tue, Feb 24, 2009 at 11:26 PM, Jim Fulton j...@zope.com wrote:
[snip]
The graph only shows direct dependencies on zope.i18n and zope.security, but
there are many other direct dependencies.
Ah, agreed, yes, I think this is because of the transitive dependency
functionality removal
Hey Andreas,
Andreas Jung wrote:
There are basically two options: create a dedicated microsite (similar
to grok.zope.org) or follow the Zope 3 approach on wiki.zope.org. Unless
someone provides enough resources in helping, I would like to go with
the wiki approach since it is much easier to
Jim Fulton wrote:
BTW, I strongly discourage from imports. (I didn't always have this
opinion, but have seen the error of my ways. Thanks to Fred Drake for
nudging me in this direction.) IMO, this is wildly more important than
any of the issues raised in this thread.
I like from
Hey,
Joachim König wrote:
import zope.interface as interface
Surprisingly enough this actually has a subtly different behavior than:
from zope import interface
the former can create circular import situations where the latter doesn't.
Regards,
Martijn
Jim Fulton wrote:
On Feb 19, 2009, at 2:07 PM, Marius Gedminas wrote:
...
-1 for repeating
english.adjective.fully english.adverb.qualified english.noun.package
english.noun.names all over the place in the code
If you have package hierarchies remotely that deep, you have bigger
Hey Christian,
You do realize you started a bikeshed discussion right?
Suddenly people wake up and spout opinions because everybody has an
opinion about this. :)
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Hey,
Andreas Jung wrote:
I followed the whole thread with some amusement. There are too many
personal coding styles on the market which makes it impossible to
regulate all all and everything. At least this discussion about
about how to write imports properly appears esoteric to me.
Yeah, I
Hi there,
Names exported to a containing package cause circular import problems
whether or not from imports are used. I've seen from imports make this
worse. I believe you've seen cases where they make it better. I think the
only way to avoid this is to use a deferred import mechanism such
Hey,
On Fri, Feb 20, 2009 at 5:05 PM, Jim Fulton j...@zope.com wrote:
[snip]
You will still likely have other problems unless you use deferred imports
which will generally solve this problem in a robust way.
I've created quite a few packages that have this structure without any
problems in my
Hi there,
Jim Fulton wrote:
[snip]
I suspect there are two possibilities:
* no API defined in __init__.py and absolute imports
* API defined in __init__.py and dotted.package.name.references
don't work.
In what way don't they work?
I don't see how this has anything to do with from
Christian Theune wrote:
On Fri, 2009-02-20 at 18:18 +0100, Martijn Faassen wrote:
We discovered this when Christian Theune said he wanted his package
__init__.py empty as otherwise he runs into circular import issues. Some
of the others including myself were puzzled as we put APIs
Simon Michael wrote:
Martijn Faassen wrote:
and a Sphinx-based website for official documentation maintained in SVN.
+1 of course,
Anyway, overall I'm a big supporter of the microsite approach. It's
the only approach that actually got us to new web sites over the last years.
I must
Hey,
The Zope Foundation would be happy to see people organize this. I
personally won't be spending time on the summer of code this year
however, so don't count on my helping to organize it this time.
While some projects went fairly well, overall I wasn't happy with the
results visible in our
Hey,
+1 for getting rid of zope.app.locales as a centralized point for
translations.
+1 also to have a way to *see* the translations as a single whole, with
the possibility to define a message id that is used by many packages.
I'm not sure I get all the details. One question is whether
Hey,
So the general idea would be to remove the complication extras
introduce in reasoning about packages. Extras can be removed in two
ways:
* carefully restructure dependency relationships between packages so
that extras are no longer needed (typically for test extras this can
be done)
*
Hey,
Tres Seaver wrote:
[snip]
repoze.bfg takes yet another approach.
I'm sure there are new ZCML directives it introduces, but it also forked
the current ZCML directives that are in zope.component for basic
component registration, to reduce its dependencies. Perhaps that fork
can be
Martin Aspeli wrote:
[snip]
I see no problem with starting with zope.component, but I'd consider
both naming conventions and package structure conventions in a wider
context before making the leap with zope.component, to reduce the chance
of inconsistencies in the future.
We already had a
Hi there,
We've recently had some discussions on where to place the implementation
of various ZCML directives. This post is to try to summarize the issue
and analyze the options we have.
Right now ZCML directives are implemented in packages that contain other
implementation. For example,
Hey Hanno,
Thanks for your feedback!
Hanno Schlichting wrote:
Martijn Faassen wrote:
[snip]
a) continue with the current extra dependencies situation like in
zope.component, and in fact clean up other packages that define ZCML to
declare ZCML extra dependencies.
-1 from me.
[snip
Hi there,
On Fri, Feb 6, 2009 at 12:10 PM, Dan Korostelev nad...@gmail.com wrote:
[snip]
For ZODB objects I think its okay for now not to use deprecations and
to use the upgrade tool, but for the imports of other things that were
moved elsewhere, I still think we need to bug developers that
Dan Korostelev wrote:
I just committed a new section to zope3docs about migration to newer
Zope 3 releases.
I think we should maintain a list of most important changes that could
break backward-compatibility, like recent changing exception types
used in zope.container in a separate
Hey Dan and everybody,
I've taken the document Dan started and have reorganized it a bit and
added bits I know of what happened at the sprint last week. I've also
introduced an 'introduction' section which discusses the aim of many of
the changes made and the general response a developer
Hey,
On Fri, Feb 6, 2009 at 11:32 AM, Dan Korostelev nad...@gmail.com wrote:
[snip]
Okay, reuse of directive definitions and implementations is more
widespread than I thought initially. Which is silly of me, as Grok
itself also reuses directive actions (but not definitions) in some
places.
But
On Fri, Feb 6, 2009 at 1:10 AM, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Fred Drake wrote:
On Thu, Feb 5, 2009 at 12:52 PM, Tres Seaver tsea...@palladion.com wrote:
I'm fixing dependent packages broken by my changes
Hi there,
On Fri, Feb 6, 2009 at 5:47 PM, Tres Seaver tsea...@palladion.com wrote:
[snip]
Martijn hoped for a tool which would help developers find places in
their code which used the BBB locations, in order to help them
modernize.
And to repeat, this tool was mostly created last week in the
Fred Drake wrote:
On Thu, Feb 5, 2009 at 12:52 PM, Tres Seaver tsea...@palladion.com wrote:
I'm fixing dependent packages broken by my changes: could you add me to
zope.app.container as well?
Done.
Great work in further reducing dependencies Tres!
Note that Stephan Richter has a Magic
Dan Korostelev wrote:
Log message for revision 96156:
Please, don't just remove things that could be used in users code.
Changed:
U zope.app.component/trunk/CHANGES.txt
U zope.app.component/trunk/src/zope/app/component/metadirectives.py
-=-
Modified:
Hi there,
This kind of stuff should really be discussed on zope-dev, so I
forwarded this here as I didn't see it.
-- Forwarded message --
From: Wolfgang Schnerring w...@gocept.com
Date: Wed, Feb 4, 2009 at 9:12 AM
Subject: Re: [Checkins] SVN: zope.app.broken/trunk/setup.py
Hey,
Roger Ineichen wrote:
First, thanks to the great refactoring work!
Can someone give a summary about what got moved or is there
another way to find out what I need to change in z3c and own
packages?
I guess there must be an update strategy since we skipped the
deprecation message
Christophe Combelles wrote:
Stephan Richter a écrit :
Hi everyone,
I have setup a KGS for Zope 3.5, so that people can test the development KGS.
http://download.zope.org/zope3.5/
I have updated all packages to the latest version available. I have not
tested
anything. I would like
Hey,
Stephan Richter wrote:
[snip]
- Improve project setup
As Shane pointed out, it is hard to get started. The solution could be a
combination of documentation and tools, like zopeproject.
It's not hard to get started as long as you use Zope 3 in the form of
Grok. :) Grok has done a lot
Stephan Richter wrote:
On Saturday 31 January 2009, Martijn Faassen wrote:
Would people be interested in working on making use of this platform? We
could use it for testing of a wide range of packages. Perhaps the ZODB
would be an interesting package to start with. If so we should approach
Yay! Thanks for all that work, Stephan!
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 -
Hi there,
Recently there was a project called snakebite revealed:
http://www.snakebite.org/
http://mail.python.org/pipermail/python-committers/2009-January/000331.html
It's basically a whole bunch of machines that open source projects, in
particular Python related ones, can make use of for
Hey,
[snip plan to clean up more dependencies]
Awesome! As Christian said, this is pretty much what we've been doing.
You might want to mess around with z3c.recipe.compattest to run
compatibility tests after your changes, though it's still a bit finicky
and rather slow. But if you try it out,
Hey,
Dan Korostelev wrote:
Well, I chose packages that are kind of separated from most of zope
the application packages, because there aren't many packages that
depend on either zope.app.catalog or zope.app.intid/keyreference. So I
think we can do that work at the same time. However, it may
Hey,
I've released our changes in zope.app.intid. We hadn't touched
zope.app.catalog and zope.app.keyreference.
Anyway, the trunks are yours.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
Hi there,
I've just made a lot of releases as the result of our dependency cleanup
sprint. There are more releases to be made, but I think I've released
the most important affected packages now. Christian Theune is going to
follow up and release some more packages that we touched, probably
Hey,
Dan Korostelev wrote:
That's a great piece of work you did, thanks!
I've been following package releases and have noticed some mistakes
mainly in changelog formatting:
zope.proxy
=
3.5.0 (unreleased)
* Added support to bootstrap on Jython.
* Use zope.container
Hey,
Thanks for this feedback. It's a good sign that such feedback is now
possible due to us having a saner dependency graph!
We won't be taking action on these issues during this sprint as we're
trying to wrap it up and make releases of our changes. At least the
dependency graph for
Chris Withers wrote:
Fred Drake wrote:
On Thu, Jan 29, 2009 at 4:01 AM, Martijn Faassen faas...@startifact.com
wrote:
I believe it'd be nicer to extract any ZCML related stuff from
zope.component at some point and put it into zope.componentzcml or
something like that. We could then decide
Hi there,
In our dependency refactoring we realized that the main reason for the
existence of zope.app.folder is the mixing in of site management
facilities into a container implementation. Unfortunately it *also*
provides a container implementation that is like zope.container's, but
not the
Benji York wrote:
On Fri, Jan 30, 2009 at 12:01 PM, Martijn Faassen
faas...@startifact.com wrote:
No, not there either, as zope.configuration doesn't define *any*
directives except the basic ones like 'include' and 'configure'. If you
would implement zope 3's directives
Hey,
Dan Korostelev wrote:
[snip]
What about the other use case of class, i.e. declaring implemented
interfaces, as in
class class=.foreignmodule.SomeClass
implements interface=.interfaces.ISomeInterface /
/class
+1. That's kinda strange to have it in zope.security.
I think, the
Tres Seaver wrote:
W! zope.container is a new module, not in zope.app: why are we
injecting a dependency on zope.app.folder here? Logically,
zope.app.folder ought to depend on zope.container, and not vice versa.
We should be mocking those objects, I think.
One step at the time. Take a
Stephan Richter wrote:
On Thursday 29 January 2009, Wolfgang Schnerring wrote:
@@ -5,6 +5,8 @@
3.4.2 (unreleased)
--
+- Use zope.container instead of zope.app.container.
+
I think that changing a dependency like this, should cause a new major
release, in this case
Hi there,
We're currently updating references to zope.app.container to
zope.container where appropriate. We just ran into zope.app.locales,
which contains translations for various strings with the id
zope.app.container.
The tool to update the zope.pot file is installed in bin/i18nextract.
Hi there,
After a lot of work we have progress to report on the dependency
reduction front:
http://faassen.n--tree.net/blog/view/weblog/2009/01/29/0
It's been a lot of work to get this far and there's a huge amount of
work to be done still, but there is progress!
The second dependency graph
Hi there,
In the dependency cleanup effort we've got going on at the Grok
cavesprint here at my house, we have moved code around some more.
zope.security was already defining ZCML directives so we've moved the
class directive from zope.app.component and and the module
directive from
Hi there,
Here at the Grok dependency reduction sprint Sylvain and Wolfgang have
been working on a buildout recipe called 'z3c.recipe.compattest':
http://pypi.python.org/pypi/z3c.recipe.compattest
What this brings to Zope development is a way to test changes in one
package against a lot of
Stephan Richter wrote:
[snip]
I will retroactively change the locations for all zope3.4 KGS releases.
Thus, I am very interested to hear from the consuming communities: How
painful
is that for you? I am particularly interested to hear from Grok, Zope 2 and
Plone, but also from
Hi there,
We're working (at a small Grok sprint) on refactoring bits of Zope to
reduce the insane dependency relations that exist between some packages.
The goal is a nice layered dependency structure for Zope 3 packages.
To that purpose Brandon Rhodes and myself started extracting things from
Hey,
Hanno Schlichting wrote:
Martijn Faassen wrote:
We're working (at a small Grok sprint) on refactoring bits of Zope to
reduce the insane dependency relations that exist between some packages.
The goal is a nice layered dependency structure for Zope 3 packages.
This is awesome news
Shane Hathaway wrote:
[snip]
Also, every encrypted password should have a scheme name prefix in curly
braces, such as {SSHA}, as discussed earlier in this thread. That
makes it possible to support multiple schemes in a single database,
which is essential for migration to new schemes.
+1
Shane Hathaway wrote:
Uli Fouquet wrote:
while working on a password manager tool (commandline) for Grok I
stumbled over the usage of salts in the password managers of
`zope.app.authentication`.
In short, they seem to generate (and store) a salt number but do not
make any use of it when it
Hi there,
Oh joy, a naming discussion. :)
A namespace isn't a framework. Be careful we don't start pretending that
the zope.* namespace is a framework. If you start judging which packages
belong in the zope.* namespace and which are not, what standards are
really being used?
The only
Andreas Jung wrote:
On 17.01.2009 8:39 Uhr, Dieter Maurer wrote:
[snip]
It is good to be able to access both site and request in
a standard way.
And it similiar accessing the current transaction using
import transaction
tx = transaction.get()
So: +1
+1 too. For Zope 2 and for Zope 3.
Hi there,
Roger Ineichen wrote:
[snip]
Why should someone use a global request if he has a request
available? This package does nothing else then offer a request
if non is available. And if you need a request if non is available
there is something wrong with the application design. Or better
Hi there,
Uli Fouquet wrote:
I'd be glad to provide a fix for this, but I am undecided how we could
support administrators best to upgrade their password bases.
I'm speaking here mostly from a position of ignorance of these affairs,
but is it possible to upgrade the current passwords to a
Hey,
On Fri, Jan 16, 2009 at 11:37 AM, Tim Cook timothywayne.c...@gmail.com wrote:
On Mon, 2009-01-12 at 22:05 +0100, Martijn Faassen wrote:
Okay, I'll take another look then and look at ObjectRef. Ah, yes, Dan
pointed out to you that you are using a zope.schema.Field in a class
instead
Hey,
To debug this
problem, a developer will need the smallest possible example of code
that demonstrates the problem. That means, I take it, just 2 schemas
and a single form. Describe briefly what you expect to happen and what
in fact happens. If that example can be done *without*
Chris McDonough wrote:
[snip]
lazr.delegates looks very cool, is a small package, and compliments
zope.interface well. However, it seems to me that zope.interface stands on
its
own without it and the two should remain separate.
I agree for the same reasons -1.
Me too, -1
Regards,
Hey Gary,
Very cool to be hearing from the Launchpad project!
Am I correct in that lazr.delegates implements a form of the decorator
pattern? If so it'd be good if the documentation mentioned this somewhere.
I know that Launchpad's use of Zope 3 has been evolving in its own
direction for a
Hi there,
Tim Cook wrote:
On Fri, 2009-01-09 at 11:05 +, Chris Withers wrote:
[snip]
So again, referring to the subject line. What are the next steps?
I am trying to understand the history of the discussion, which has a lot
of text and is widespread.
I think Dan Korostelev tried
Shane Hathaway wrote:
Martijn Faassen wrote:
Besides an
import checker you'd need a system that would be able to thrawl through
a ZODB and report deprecated classes. The drawback is that it'd need to
thrawl through a ZODB, so that's rather costly.
Thrawl = thrashing crawl? Never heard
The Grok team is happy to announce the release of Grok 1.0a1. This is
the first step on the way to the release of Grok 1.0! With Grok 1.0 we
will deliver a stable, powerful, featureful framework for Python-based
web development. Grok 1.0a1 is a preview of the 1.0 release and a
continuation of the
Hey there,
Roger Ineichen wrote:
[snip]
I don't like that. Probably we should use the existing devmode
or something like that? Devmode whould allow us to use it at
runtime and during testing. What about a deprecation mode?
I really like to use such deprecation messages in production too.
I
Hi there,
All right, I was getting a bit confused when it appeared you were
arguing against moving things at all, but you're basically in favor of
leaving the old APIs intact without explicitly breaking them.
I think we need to think of some way to signal that the preferred
import location of
Hi there,
Tres, please tell me what I should be doing as opposed to moving
things around and deprecating them.
I want a version of Grok with far less dependencies than it pulls in
now. I believe there are a lot of advantages in doing that, and I'm
not going to go into them here as I'm sure you
Hey,
On Fri, Dec 19, 2008 at 7:50 PM, Dieter Maurer die...@handshake.de wrote:
Martijn Faassen wrote at 2008-12-18 16:27 +0100:
...
You should, and likely are, shipping your package with a recommended
list of versions.
Apparently, grok was forced to go this route.
But, in principle
Hey,
Tres Seaver wrote:
[snip]
I take cleaning up deprecation warnings seriously: I want all tests for
my packages, for instance, to run without emitting *any* of them.
Deprecation warnings have a non-trivial downside: consider the case
wher one of *my* downstream users updates Roger's
Fred Drake wrote:
On Wed, Dec 17, 2008 at 6:36 PM, Tres Seaver tsea...@palladion.com wrote:
If we just leave the name importable from the old location, what is
hurt? The major downside is that people won't learn about the new
location. I consider this to be less an issue than the two
Marius Gedminas wrote:
On Tue, Dec 16, 2008 at 03:45:01PM -0500, Tres Seaver wrote:
[why would we ever want to avoid giving deprecation warnings?]
One issue is that adding deprecation messages for importing symbols from
the old makes all downstream code add ugly BBB warts in order to
suppress
Christian Zagrodnick wrote:
[snip]
Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html
Weird. At first glance I do not understand the context of that decision.
There was a decision to avoid deprecation made by it doesn't seem to
be motivated in the discussion:
-
Hey,
Christian Zagrodnick wrote:
[snip]
That's good. One thing which is not good is that you deprecated the use
of ITerms from zope.app.form. I'd just leave the reference/import there
like we did with ISite in zope.app.component.
Why is such a deprecation warning bad? Wouldn't this
Malthe Borch wrote:
Martijn Pieters wrote:
I object as well, and have asked for Malthe to provide his reasoning
here at the Plone Performance Sprint in Bristol, but so far his only
motivation is that he wants to see if he can get this to work without
a C-extension. I am sceptical he'll be
Martijn Faassen wrote:
Hi there,
I saw that Roger Ineichen created and released a package called
zope.browser.
I assume that this package is intended to reduce dependencies, which is
a project I applaud. So far I don't see any effect of this - in fact
several packages now have
Hi there,
Robert Niederreiter wrote:
[snip]
We have written browser helper tools in a package named
cornerstone.browser. especially IRequestMixin here
http://dev.plone.org/collective/browser/cornerstone.browser/trunk/cornerstone/browser/interfaces.py
might be a candidate for this or such
Hey,
On Fri, Nov 28, 2008 at 12:12 PM, Chris Withers [EMAIL PROTECTED] wrote:
Martijn Faassen wrote:
It's clearly the case that people who are reading this thread know how
to avoid download.zope.org. The people who are not reading this thread
just get tough luck from the Zope community when
Hey,
Christian Zagrodnick wrote:
when I include an egg with extras (like gocept.foo[server]) the
dependencies from the extra are not automatically included with
autoinclude.
I'm posting this here, because there is no other obvious place (no
project for this on lauchpad).
I only see
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
[snip]
-1 to removing it. There is actually code out there that explicitly
relies on versions of packages that can only be found in this place. Now
of course that should be fixed, but even
Hey,
On Thu, Nov 20, 2008 at 10:40 PM, Chris Withers [EMAIL PROTECTED] wrote:
Martijn Faassen wrote:
If we released a version of Grok, say, back in the day that relied on an
egg that's in that location, and someone built an application back in the
day that relies on that version of Grok
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Zagrodnick wrote:
On 2008-11-12 23:41:55 +0100, Jim Fulton [EMAIL PROTECTED] said:
http://download.zope.org/distribution was set up as a place to publish
distributions while we were learning about setuptools, eggs,
Hi there,
Before noticing svn.zope.org was down, I noticed that buildouts seem
to be failing/hanging somewhere in httplib. I now suspect this is
possibly because various setup.py's have a 'url' entry that references
svn.zope.org and setuptools might go off and try to read it, resulting
in a hang
Hi there,
On Wed, Oct 15, 2008 at 3:35 PM, Andreas Jung [EMAIL PROTECTED] wrote:
[snip]
If Python 2.6 is the latest official Python version of the 2.X line that
there is a chance that this version will be supported by the Python
community in the long term. So supporting Python 2.4 or Python
Sidnei da Silva wrote:
On Tue, Oct 14, 2008 at 2:16 PM, Andreas Jung [EMAIL PROTECTED] wrote:
Thanks for starting the discussion. Going for Python 2.6 also requires that
we get the ZCA running on top of Python 2.6 until some time next year.
FWIW, that's what I've been working on. There's
Hi there,
On Wed, Oct 15, 2008 at 2:30 PM, Andreas Jung [EMAIL PROTECTED] wrote:
If the latter,
what about the security review for untrusted code?
You mean the review of RestrictedPython?
Yes.
If RestrictedPython is to be reviewed for changes, it *might* be
easier to do this for 2.4 - 2.5
Hi there,
Could we add dates to the KGS releases on the KGS page?
http://download.zope.org/zope3.4/intro.html
Where are the KGS versions listings tagged in SVN again? A link on the
KGS page would be good too.
Regards,
Martijn
___
Zope-Dev maillist
601 - 700 of 1200 matches
Mail list logo
