Hi,
Following an earlier discussion on this list, I've made changes to
zope.filerepresentation to incorporate two new interfaces, IRawReadFile
and IRawWriteFile. These allow file representation adapters which behave
like Python standard library 'file' objects. This in turn allows
Fabio Tranchitella wrote:
Hello,
* 2009-10-05 12:15, Martin Aspeli wrote:
Would anyone mind making a 3.5.1 release, or else give me PyPI rights so
that I can do it myself.
Shouldn't this be 3.6.0?
I don't care one way or the other. 3.6.0 is fine by me.
Martin
--
Author
Hi,
In my travails through the ZPublisher and WebDAV, I've come up with
another fun thing.
As far as I can tell, traversal via acquisition doesn't make any sense
for a WebDAV request. If I have /foo and /bar, but not /bar/foo, then
traversal to /bar/foo over WebDAV should not acquire /foo and
Martin Aspeli wrote:
Martin Aspeli wrote:
Martin Aspeli wrote:
Hi,
In my travails through the ZPublisher and WebDAV, I've come up with
another fun thing.
As far as I can tell, traversal via acquisition doesn't make any sense
for a WebDAV request. If I have /foo and /bar, but not /bar/foo
Shane Hathaway shane at hathawaymix.org writes:
Martin Aspeli wrote:
Can anyone explain why that condition is there? Otherwise, I'll rip it
out.
As I recall, this code is convoluted because it's hard to tell whether
an HTTP request is a WebDAV request. If there is now a way
Hi,
I came across this trying to implement WebDAV support for some content in Zope
2.
The ZPublisher will always traverse to the return value from 'browserDefault()'
(either from a custom IBrowserPublisher adapter, or the DefaultPublishTraverse
object hardcoded in ZPublisher.BaseRequest) when
Andreas Jung wrote:
I am pleased to announce the launch of a new website dedicated to the
Zope 2 application server:
zope2.zope.org
This site gives the Zope 2 application a much better representation on
the web (which was more than necessary after having lived for years
Hanno Schlichting wrote:
On Thu, Oct 1, 2009 at 2:13 AM, Martin Aspeli optilude+li...@gmail.com
wrote:
Hanno Schlichting wrote:
Is there any reason to invent a new API and not just use Python's file API?
I don't know. IReadFile and IWriteFile have been around for ever and are
used
Hi,
I'm doing some work with WebDAV representations in Zope 2, among other
things, and I'm trying to see if we should use zope.filerepresentation
as the central abstraction for file read/write operations.
However, I find myself lacking a couple of things:
1) A way for an IReadFile to return
Hanno Schlichting wrote:
Is there any reason to invent a new API and not just use Python's file API?
I don't know. IReadFile and IWriteFile have been around for ever and are
used by a number of things in Zope. They have read(), write() and
size(). The first two are on file, the last one
Hi,
- What is the current version of ZTK? 1.0? 1.0-something? 3.5? Note
that docs.zope.org/zopetoolkit talks about 3.5.
- What is the canonical location of a ZTK KGS? I'm locking for a
buildout [versions] block in particular.
- What is the plan for Zope 2.12 final? Is it going to rely
Gerhard Weis wrote:
Hi,
Sorry if this is the wrong list, but as plone.z3cform is in the
zope-svn. I thought it may be Ok.
There is a small problem in plone.z3cform. The class
plone.z3cform.fieldsets.extensible.ExtensibleForm has a class attribute
groups, which is changed by the
Christian Theune wrote:
On 08/01/2009 01:35 AM, Godefroid Chapelle wrote:
Sidnei da Silva wrote:
On Thu, Jul 30, 2009 at 9:33 PM, Martin Aspelioptilude+li...@gmail.com
wrote:
Unfortunately, I've got other packages that depend on a newer
zope.testing (specifically,
Sidnei da Silva wrote:
On Thu, Jul 30, 2009 at 9:33 PM, Martin Aspelioptilude+li...@gmail.com
wrote:
Unfortunately, I've got other packages that depend on a newer
zope.testing (specifically, collective.testcaselayer). But I thought
zope.testing aimed to be able to run any valid tests, so it
Hi,
I'm running the plone.z3cform tests in a Zope 2.10 instance with
zope.testing 3.8 installed.
All other tests seem to work OK, but with plone.z3cform's tests, I get:
$ ./bin/instance test -s plone.z3cform
Running tests at level 1
Running plone.z3cform.testing_zcml_layer tests:
Set up
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Hi,
I'm running the plone.z3cform tests in a Zope 2.10 instance with
zope.testing 3.8 installed.
All other tests seem to work OK, but with plone.z3cform's tests, I get:
$ ./bin/instance test -s
Hi,
It seems that an integration test written using ZopeTestCase (and
PloneTestCase) does not support using zope.security.checkPermission().
The problem is that the interaction threadlocal isn't set up, so you get
an AttributeError.
It's easy to fix: just call
Hanno Schlichting wrote:
Hi.
I'd like to push code and ZCML from Products.Five into the appropriate
places in Zope2.
For example event.zcml registering events for OFS items, should live
in the OFS package. i18n.zcml setting up stuff for the request or the
publisher should live in the
Hanno Schlichting wrote:
On Sun, Jul 26, 2009 at 5:21 PM, Martin Aspelioptilude+li...@gmail.com
wrote:
The problem is that the interaction threadlocal isn't set up, so you get
an AttributeError.
It's easy to fix: just call Products.Five.security.newInteraction()
before the test is run.
Wichert Akkerman wrote:
On 6/30/09 7:03 PM, Stephan Richter wrote:
It is needed for the latest-versions script as this parses XML. I consider
lxml pretty much the standard tool to do XML in Python these days. Who is not
using lxml?
I suspect the majority of people who use OSX as their main
Hi,
Is there any documentation on zope.proxy other than the test? I don't
speak C anymore. :)
Basically, I'm curious if it would be possible to implement translation
proxies that would allow getting and setting translated values for
certain fields.
Cheers,
Martin
--
Author of `Professional
Hi Christian,
Thanks for this!
Have a look at the attached file, it contains the code that I extracted
from a project in a hurry, but if the approach sounds reasonable to you,
I'd be happy to put that into SVN.
Can you tell me a bit more about how this is hooked into publication?
Where do
Patrick Gerken wrote:
Hello,
I am a bit confused about self.request and self.REQUEST.
Can anybody point me to an explanation of the different tasks that both
have?
Googling for request vs REQUEST is not helpful...
D'oh! :-)
REQUEST is a Zope2-ism. When you do self.REQUEST somewhere, you
Maurits van Rees wrote:
Adam GROSZER, on 2009-05-24:
Hello,
Following just happened. The project has KGS 3.4 versions as a base,
locally I wanted to override lxml to = 2.1.1.
[...snip...]
extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg
versions = versions
[versions]
lxml
Hi,
So, we determined that OFS.Traversable's unrestrictedTraverse()
shouldn't grow support for IPublishTraverse, which is fair enough. We're
now using an ITraversable adapter instead (++namespace++).
However, we found another inconsistency. In URL traversal, this works:
Jan Hackel wrote:
Some days ago I ran into the same problem, and have been pointed to this
thread. Maybe you are interested in my solution. It's ugly, but I needed it
for a test-case, where I wanted to access
@@plone_context_state/is_view_template:
from ZPublisher.HTTPRequest import
Hi,
There's currently a funny inconsistency in Zope's Traversable class. If
you have a URL like http://localhost:8080/path/to/@@aview/foo, and
@@aview implements IPublishTraverse (and, I presume, if there's a custom
IPublishTraverse adapter for any other path component), URL traversal
will
Tres Seaver wrote:
The burden of proof *is* the work you just signed up the preserve
2.4 group for: monitoring the packages they care about for things
which break under 2.4, and proposing 2.4-compatible fixes.
Sure. That's different to saying officially that ZTK does not support
Python 2.4,
Martijn Faassen wrote:
Hey,
Martijn Faassen wrote:
In order to get to a conclusion:
I haven't seen convincing arguments yet *not* to drop the Python 2.4 for
new releases of the Zope Toolkit libraries.
I'd like to phrase the debate in those terms instead of the reverse,
because
Lennart Regebro wrote:
On Tue, May 5, 2009 at 11:55, Martin Aspeli optilude+li...@gmail.com wrote:
We've had some more discussions about this and the Plone release
schedule. The upshot is that if Zope 3/Toolkit drops Python 2.4 support,
it will effectively render it inaccessible to Plone users
Martijn Faassen wrote:
As I pointed out, it is effectively inaccessible for Plone users anyway,
as Zope 3 is already installed. You *cannot* mix Zope Toolkit and Zope 3
libraries just like that and expect anything to work.
Why not? We upgrade Zope 3.3 packages to 3.4+ all the time to access
Martijn Faassen wrote:
So I see two responses for Plone developers:
* they know that they need new versions of zope.app.container and
zope.app.component too and require people to upgrade those too. This
might work fairly well, but does require the upgrade of more than just a
*few*
Chris Withers wrote:
plohn.
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
Hi folks,
I've written a small Google App Engine application to help manage and
publish buildout configuration that provide a known good [versions] block.
I'm not sure this approach is good, and the application is not well
tested, but it may be of interest to some people here.
Martijn Faassen wrote:
Hi there,
What do people feel about dropping Python 2.4 support in the Zope
Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave
vaguely as we *still* don't have a canonical list) only have to work in
Python 2.5 (and preferably 2.6), not Python 2.4
Gary Poster wrote:
I'm concerned about the state of the zc.buildout template recipes. I
want one. I want some one-off files, specific to a certain project,
for which writing a standalone recipe feels very heavy.
Here are the template recipes I found:
collective.recipe.template
Uli Fouquet wrote:
In the beginning my code should go into collective.recipe.template
itself (Wichert agreed), but I wasn't granted committer access to the
collective repository yet. Of course I requested to be approval and
waited for weeks, but nothing happened.
I'm sorry to hear that! In
Andreas Jung wrote:
What would be disappointing?
To be unable to use new packages from an updated Zope Toolkit.
It may be that some (many?) packages won't work with Zope 2.10, but if
we get the kind of dependency isolation we're talking about, I'd wager
that quite a few packages would work
Andreas Jung wrote:
On 27.04.2009 17:07 Uhr, Martin Aspeli wrote:
Andreas Jung wrote:
What would be disappointing?
To be unable to use new packages from an updated Zope Toolkit.
It may be that some (many?) packages won't work with Zope 2.10, but if
we get the kind of dependency
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
Martin Aspeli wrote:
The Plone 3.x series will stay on Python 2.4 for a long time yet, so
this would be very disappointing. I can understand it if the maintenance
burden becomes large
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Tres Seaver wrote:
Thinking further on this: there is actually not much shiny about the
ZTK: it is going to be equivalent to a cut-down, dependency-stripped,
bbb-cruft-sanded version of the packages
Laurence Rowe wrote:
Martin Aspeli wrote:
Hi,
First - a quick question: can we treat __name__ and id/getId()/_setId()
as the same, always? OFS.SimpleItem has some support for letting id and
name be the same, but the link is lost once both __name__ and id are
set. Why isn't __name__ just
Hi,
First - a quick question: can we treat __name__ and id/getId()/_setId()
as the same, always? OFS.SimpleItem has some support for letting id and
name be the same, but the link is lost once both __name__ and id are
set. Why isn't __name__ just a property that reflects self.id ?
Then, the
Stephan Richter wrote:
On Sunday 19 April 2009, Tres Seaver wrote:
-1. As a branding choice (as opposed to a technology), Zope 3 *is* a
dead-end: it implies a strategy (replacing Zope 2) which we no longer
believe in. I think the consequences of the brand confusion are hard
for those uf us
Martijn Faassen wrote:
Hey,
Martin Aspeli wrote:
[snip]
I do realise that this derails Maritjn's focus slightly, but I don't
think we've lost the idea that there may be value in maintaining a
larger KGS.
The whole idea of whatever-Zope 3-is-designated-as just being a larger
KGS
Martijn Faassen wrote:
If we want to do this right we need to come up with a good way to get
the message out.
I think the only way you're going to manage to do that, is if you have a
website with a clear and unambiguous message on it.
It's like deja-vu all over again...
Martin
--
Author
Rob Miller wrote:
Gary Poster wrote:
This message seems like a reasonable start to me: Zope 3 has become
focused on supporting frameworks and applications, rather than trying
to be one itself. It is now called the Zope Toolkit. Parts of it are
used by Zope 2, Plone, Grok, Repoze.bfg,
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Log message for revision 99146:
Let the permission / directive auto-register permissions that don't
exist already
This kind of test is a poster child for why doctests with lots of
output
Hanno Schlichting wrote:
By now I count three people using Zope 3 for a small number of projects.
But none of them seems to have the resources to continue the maintenance
or future development of Zope 3.
Whilst you're absolutely right, just a word of warning: a lot of people
do not read
Martijn Faassen wrote:
Hey,
Martin Aspeli wrote:
[snip]
- In ZCML (or a grok.require() directive) use the Zope 3 name
Grok also has a grok.Permission you can subclass, and those subclasses
can also be passed to grok.require().
I know, but I kind of consider creating permissions
Dieter Maurer wrote:
Martin Aspeli wrote at 2009-4-12 18:31 +0800:
Finally, there is not total parity between Zope 2 security and Zope 3
security. Zope 2 cannot protect 'property set', for example.
Since Zope 2.8, Zope 2 could in principle -- and until quite recently
I thought
Martin Aspeli wrote:
I've now implemented 1 and 2 on trunk, since they seem pretty
non-controversial.
1) Use an event handler to ensure that any permission / declared in
ZCML actually creates a valid, Zope 2 permission. I have working code
for this here which we could put
Hermann Himmelbauer wrote:
-1 from my standpoint. Two of my projects are fully based on the Zope 3
server, and switching to something else would be quite some pain.
FWIW, I think you're absolutely right. We can't just declare it dead
because it is convenient to our goal of having clearer
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
I've not done this yet:
3) Change the Permission class in AccessControl so that it tries to
look up an IPermission utility and use the title of that utility as the
permission name, falling back
Hi all,
For a while now, people have had to contend with two ways of doing
certain things, depending on whether the code they are working with is
in Zope 2 land or Zope 3 land. We're getting closer to a world where
people don't need to be so intimately aware of the differences,
especially
Stephan Richter wrote:
On Thursday 09 April 2009, Martin Aspeli wrote:
Clearly, I'm getting too new a version of RestrictedPython, but this is
running against the 3.4 KGS, so I don't see how that could really happen.
This is not a problem. Ignore those errors as they happen in the Python 2.6
Adam GROSZER wrote:
Hello,
I would add TEMPORARYLY (for testing) the KGS to buildout.cfg:
[buildout]
extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg
versions = versions
develop = . benchmark
parts = test checker coverage-test coverage-report docs i18n benchmark python
Wichert Akkerman wrote:
Previously Shane Hathaway wrote:
discussion type=bikeshed
Tres Seaver wrote:
WRT the Framework name: framework is a misleading name for the
collection of packages salvaged from the new Coke effort: it is
actually a *bunch* of frameworks, in the classic software
Wichert Akkerman wrote:
Previously Martin Aspeli wrote:
Wichert Akkerman wrote:
To stir things up: I would like to suggest renumbering the next Zope 2
release to Zope 4. That reflects the large refactoring that is being
done to clean up the codebase and fully eggify Zope. There are enough
Hi,
I just tried to check out the new 1.9.x branch of z3c.form (thanks
Stephan!), but it won't build with Python 2.4 (I need this to work with
Plone, so 2.4 is a must):
$ ./bin/buildout
Develop: '/users/optilude/Development/Plone/Code/Products/z3c.form/.'
Unused options for buildout:
Martijn Faassen wrote:
Let's talk about Zope Classic and see whether renaming Zope 2 to that is
a step we can realistically take in the near future. Who is in favor of
that?
-100
Zope 2 is an incredibly established name. It's been around forever.
Renaming something that has been out there
Martijn Faassen wrote:
Hey,
Okay, in the interests of making this discussion go quickly, there has
been enough negative feedback about renaming Zope 2 to think we have no
realistic chance of renaming it.
We are still stuck with the following perceived sequence:
Zope 2, Zope 3
Wichert Akkerman wrote:
To stir things up: I would like to suggest renumbering the next Zope 2
release to Zope 4. That reflects the large refactoring that is being
done to clean up the codebase and fully eggify Zope. There are enough
changes to warrant a new major version bump.
-100 again.
Hi,
Today, I found a bug in ChoiceTerms: it will only bind the field if
field.vocabulary is None, which breaks uses of an IContextSourceBinder.
I thought to fix that in svn, but there's no 1.9.x branch, and 2.0
(trunk) is a very different beast.
Tracking 2.0 trunk is not an option right now.
Chris Rossi wrote:
from zope.interface import Constant
class IHttpResponse(Interface):
Models an HTTP 1.1 response.
HTTP_OK = Constant(200 Ok, An HTTP Ok response.)
HTTP_NOT_FOUND = Constant(404 Not Found, An HTTP Not Found response)
status = Attribute(HTTP status
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Zope community, I am pleased to announce the creation
of the Zope 4.0 project. After extensive discussion with the Zope
wizards in conclave at PyCon 2009, the new project's website has been
launched:
Hi,
I'd like to add support for the following:
1) Provider decorator:
@provider(IFoo)
def some_function(context)
pass
This is an alternative to doing a separate alsoProvides() on the function.
2) An interfaceProvides directive:
class IFoo(Interface):
Stephan Richter wrote:
On Tuesday 17 March 2009, Martijn Faassen wrote:
If a package defines a *lot* of ZCML, we will have to wonder about the
purpose of the package (is this really a library-like package or more
like an application defining a UI or something?), and we'll have to
think about
Andreas Jung wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16.03.2009 1:17 Uhr, Martin Aspeli wrote:
Andreas Jung wrote:
As mentioned earlier: use buildout. easy_install support has no high
priority right now.
Whilst I understand that we don't have the capacity to test all
Hi,
I *think* this is a bug in zc.relationship, but I'm not quite sure.
I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install
plone.app.relations, which depends on zc.relationship 1.0.2. In
particular, it subclasses zc.relationship.shared.Container, and stores
a
Gary Poster wrote:
On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote:
Hi,
I *think* this is a bug in zc.relationship, but I'm not quite sure.
I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install
plone.app.relations, which depends on zc.relationship 1.0.2. In
particular
Martin Aspeli wrote:
Gary Poster wrote:
On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote:
Hi,
I *think* this is a bug in zc.relationship, but I'm not quite sure.
I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install
plone.app.relations, which depends on zc.relationship 1.0.2
Hi Gary,
zc.relationship 2.0 trunk is now essentially a wrapping of zc.relation
code for backwards compatibility.
I see. But 2.0dev on pypi isn't?
What's the story behind zc.relation and the evolution of zc.relationship?
You guys are the main clients for zc.relationship at this point, I
Hi Gary,
Thanks for being so helpful!
What's the difference between 1.1.1 and 2.0dev on pypi?
I intended that 1.1.1 would simply make the absolutely minimal changes
necessary for you to be able to use the 1.1 branch. It would not have
any of the 2.x changes at all.
But we're saying
Gary Poster wrote:
Hopefully. Do we know that zc.relationship 1.1 works with both ZODB
versions?
That would be a significant point of its existence, so I certainly
hope so. I'm 80%+ confident that it does, and would regard not
supporting 3.7 as a bug that I'd be willing to fix.
Martin Aspeli wrote:
Gary Poster wrote:
Hopefully. Do we know that zc.relationship 1.1 works with both ZODB
versions?
That would be a significant point of its existence, so I certainly
hope so. I'm 80%+ confident that it does, and would regard not
supporting 3.7 as a bug that I'd
Gary Poster wrote:
Yes, +1. Thank you. I was about to write to your other message that
this was quite possibly the only 3.8 dependency.
Cool. Committed.
If we do that, then we can let plone.relations depend on
zc.relationship
1.1.1 explicitly and have support for both ZODB versions,
Dieter Maurer wrote:
Hanno Schlichting wrote at 2009-3-15 11:10 +0100:
Dieter Maurer wrote:
The Zope 2.12 documention tells that the test command was removed
from zopectl.
test was a convenient way to test products and packages in the
context of the instance. How is this use case now
Andreas Jung wrote:
As mentioned earlier: use buildout. easy_install support has no high
priority right now.
Whilst I understand that we don't have the capacity to test all
different configurations now, I think it's a good principle to try to
avoid a 'hard' dependency on zc.buildout. If we
Stephan Richter wrote:
On Thursday 12 March 2009, Martin Aspeli wrote:
I'm writing a custom file widget for z3c.form that works like the
Archetypes file widget that Plone uses and the formlib widget in
collective.namedfile. That is, after you've uploaded a file once, you're
given a radio
Stephan Richter wrote:
On Thursday 12 March 2009, Martin Aspeli wrote:
Could I maybe create a custom validator that checks for a magic
constant? If so, how? I have both a custom field (in the zope.schema
sense) and a custom widget.
Yeah. I could swear I implemented this before. A validator
Laurent Mignon wrote:
Hi,
2 weeks ago, I've implemented a support for nested group into the
branch svn://svn.zope.org/repos/main/z3c.form/branches/sagblmi-nestedgroup
All test pass and no compatibility issue.
Can I merge it to the trunk?
What's the use case for this?
Martin
--
Hi,
Sorry for doing this by email rather than unit test, but I'm a bit
over-stretched at the moment.
plone.z3cform has a backport of z3c.form trunk's TextLines widget
(when's that release coming, any ideas?).
In using it, I discovered that the converter (converter.py on z3c.form
trunk) does
Martin Aspeli wrote:
Hi,
Sorry for doing this by email rather than unit test, but I'm a bit
over-stretched at the moment.
plone.z3cform has a backport of z3c.form trunk's TextLines widget
(when's that release coming, any ideas?).
In using it, I discovered that the converter
Paul Everitt wrote:
When I read Martin's post, I had a similar reaction. Namely, that the
convenience of the Uberthing (Plone in this case) will always trump the
desire of packages trying to survive on their own for new audiences. At
the time of the configuration scolding, I remember
Lennart Regebro wrote:
I'm talking about a group of people who act as if they're responsible,
not your mythical committee. We should be able to find a bunch of people
with a sense of responsibility, right?
Yes. But I don't think making them a steering group is going to help.
Just to take
Martijn Pieters wrote:
Would it be possible to focus this discussion around clearer lines?
Create counter proposals if you have to, discuss things on their
merits, but if you cannot add more than a vague +1 and -1, please
refrain.
I think that would be easier if we had a shorter proposal. I
Chris McDonough wrote:
Sorry, the you above in you scolded was Martin Aspeli, not Faassen.
Note that the scolding had something to do with you breaking Plone
trunk due to a transitive change in Chameleon, and the realisation that
from this point on, any package shared between repoze.bfg
Tres Seaver wrote:
Different participants will report differently about the success, no
doubt. One unexpected outcome (for some) was classifying the
decisions taken at the PSPS as advisory, just talk, etc: having
no force in governing the more tactical decisions.
I don't know why this
Martijn Faassen wrote:
Okay, I guess we do differ here. I think a leader can provide
encouragement and stimulate people into action, point out interesting
outstanding tasks, and make sure that people who are motivated actually
get grip on improving the project and don't get discouraged. Of
Tres Seaver wrote:
- - The branch kills off both the use of 'zope.deferredimport' and the
'bbb' subpackage, leaving something which could be used in Jython, or
IronPython, or the GAE.
Why is zope.deferredimport a problem? Does it do something CPython
specific? As a small utility, I don't
Chris McDonough wrote:
I'm pretty sure a steering group and a rebranding of existing software is not
going to make us more effective. Here's what I believe would make us more
effective:
First of all, I'm not sure what Martijn is saying is necessarily in
dichotomy with what you're saying, so
Tres Seaver wrote:
It is a nightmare, but not one which a KGS can really fix: sometimes
your project needs its *own* KGS. Honestly, the only safe thing for
anybody trying to support a large application in production is to run
their own index, and do the gatekeeping of packages into it
Martijn Faassen wrote:
What is going to make us more effective is:
* a recognition of current reality, i.e. the Zope Framework is not the
same as the Zope 3 application server and it serves a far wider audience.
* leadership
I really couldn't agree more. There's unfortunately a bit of a
Stephan Richter wrote:
On Monday 02 March 2009, Martin Aspeli wrote:
Plone, by the way, had a similar problem, and solved it by creating the
framework team. This is a rolling body of people who are responsible
for putting out calls for and reviewing improvements proposals. They
basically
Chris McDonough wrote:
Sure. We can be careful, grown-up, conservative, and all that. But I'll note
that a) there just really aren't that many people using Zope 3 b) the people
that *are* using Zope 3 by itself are capable of maintaining their own index
c)
the people who *aren't* capable
Chris McDonough wrote:
Martijn Faassen wrote:
Hi there,
I just realized the irony in this:
[Martijn spends a lot of time in trying to solve problems in our
community, bothering to consult lots of people and writing up a document]
[Chris]
I'm pretty sure a steering group and a rebranding
Shane Hathaway wrote:
Martin Aspeli wrote:
I'm used to using Paste Deploy ini files to configure a WSGI pipeline.
Is this simply an alternative to that? If so, do we really need our own
alternative, or could we try to use the Paste Deploy stuff directly?
Yes, you can just use Paste Deploy
Hanno Schlichting wrote:
Shane Hathaway wrote:
Roger Ineichen wrote:
Do you know something about the performance of WSGI?
I whould be happy to see some perfomance tests comparing
WSGI with other server concepts.
WSGI is extremely lightweight, so WSGI itself isn't going to affect
Lennart Regebro wrote:
On Sat, Feb 21, 2009 at 05:14, Martin Aspeli optilude+li...@gmail.com wrote:
The new.zope.org initiative died because no-one could write any content.
Even then 5-10 pages of content requires for a very basic microsite was
too much, and several separate calls
201 - 300 of 440 matches
Mail list logo
