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 doc
Hi there,
On Fri, Feb 6, 2009 at 12:10 PM, Dan Korostelev 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 they
> need to u
On Fri, Feb 6, 2009 at 1:10 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Martijn Faassen wrote:
>> Fred Drake wrote:
>>> On Thu, Feb 5, 2009 at 12:52 PM, Tres Seaver wrote:
>>>> I'm fixing dependent package
Hey,
On Fri, Feb 6, 2009 at 11:32 AM, Dan Korostelev 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 of course plac
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: zope.app.component
Fred Drake wrote:
> On Thu, Feb 5, 2009 at 12:52 PM, Tres Seaver 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 Script that he can
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
Date: Wed, Feb 4, 2009 at 9:12 AM
Subject: Re: [Checkins] SVN: zope.app.broken/trunk/setup.py
zope.app.appsetup is o
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.
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
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
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 l
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.
>> * Us
Dan Korostelev wrote:
> Also, there's a bug in zope.traversing:
>
> The getParents function of zope.traversing.api uses the "getParents"
> method of IPhysicallyLocatable, which really is new ILocationInfo, but
> this interface doesn't even declare getParents method and the
> RootPhysicallyLocatabl
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 tomo
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
http://mail.zope.org/mailman/listinfo/zope-dev
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
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,
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 tes
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 -
http://mail.zope.org/mailman/listinfo/zope-a
Benji York wrote:
> On Fri, Jan 30, 2009 at 12:01 PM, Martijn Faassen
> 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
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 s
Chris Withers wrote:
> Fred Drake wrote:
>> On Thu, Jan 29, 2009 at 4:01 AM, Martijn Faassen
>> 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
>>> so
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 zope.cont
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 i
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.
Unf
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,
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. Tak
Hey,
Dan Korostelev wrote:
[snip]
>>
>> What about the other use case of , i.e. declaring implemented
>> interfaces, as in
>>
>>
>>
>>
>
> +1. That's kinda strange to have it in zope.security.
>
> I think, the better place to move zcml directives is zope.component,
> as it already depend
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 oth
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
directive from zope.app.component and and the
directive from zope.app.security into
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 Zop
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
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 indiv
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.
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
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 mo
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 bet
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
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 standard
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*
Hey,
On Fri, Jan 16, 2009 at 11:37 AM, Tim Cook 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
>&g
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
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 whi
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 buildi
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 ra
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
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 s
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 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 thi
Fred Drake wrote:
> On Wed, Dec 17, 2008 at 6:36 PM, Tres Seaver 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 problems I
>> outline
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
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
>> s
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:
"- zope.a
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'l
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 encour
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
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
&
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 an added dependency to zope.browser tha
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
>&g
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 se
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
&g
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
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 se
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 Pytho
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
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. The
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
Malthe Borch wrote:
> 2008/9/9 Philipp von Weitershausen <[EMAIL PROTECTED]>:
+- Make e.g. and
etc.
+ work
>>> Are we sure we want this? It's (afaik) not correct XML;
>> It's not? How so?
>
> If the element belongs to some namespace, then attributes from this
> namespace should b
Hey,
On Thu, Sep 4, 2008 at 4:52 PM, Jim Fulton <[EMAIL PROTECTED]> wrote:
> On Sep 4, 2008, at 8:49 AM, Fred Drake wrote:
>
>> On Thu, Sep 4, 2008 at 8:16 AM, Martijn Faassen <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Does the hidden status explai
Hi there,
On Thu, Sep 4, 2008 at 4:29 PM, Jim Fulton <[EMAIL PROTECTED]> wrote:
[snip]
>> I discovered today I think the time is ripe for a "blank buffer" rewrite
>> of the testrunner: it is so full of "twisty passages" that my
>> confidence in its own internal correctness is seriously depleted.
Hi there,
On Thu, Sep 4, 2008 at 1:42 PM, Andreas Jung <[EMAIL PROTECTED]> wrote:
[snip]
> zope.testing 3.6.0 was marked as hidden on PyPI. It's now visible again -
> together with 3.5.6.
Does the hidden status explain it not being picked up by buildout?
Anyway, sorry for getting confused there.
Hi there,
There appears to be a release of zc.recipe.testrunner 1.1.0 which
requires zope.testing 3.6.0, but zope.testing 3.6.0 was not released as
far as I can see. This means zc.recipe.testrunner 1.1.0 cannot be installed.
Regards,
Martijn
___
Zop
Hermann Himmelbauer wrote:
[snip]
> - The real reason I need the interfaces is that I have to include them in my
> configure.zcml in order to make the underlying objects read/writeable. But
> this is in my case only annoying, but not helpful at all.
Ah, interesting! This is a problem that doesn'
Hermann Himmelbauer wrote:
[snip]
> Although ZODB may not be useable for a specific case, why not use a
> Zope3-style design process? So I'd start out with interfaces that describe my
> content objects, then I'd model relations, with interfaces too. And when I'm
> done, I'd derive the SQLAlchemy
Hi there,
Roger Ineichen wrote:
[snip]
> We have different kind of refactorings which all solve some
> problems. I think we should not start with the browser views.
> There are some core dependencies we need to cleanup first.
>
> Right now I'm working forward with small refactorings
> which sol
Roger Ineichen wrote:
[snip]
> Most packages which are interesting for reuse
> provide more or less only ZMI related views.
>
> What about zope.zmi if they provide views for
> the ZMI. This views are allmost unuseable
> outside the ZMI (know as Rotterdam skin)
Why not simply leave the ZMI stuff i
Hi there,
On Wed, Sep 3, 2008 at 7:55 PM, Philipp von Weitershausen
<[EMAIL PROTECTED]> wrote:
> Benji York wrote:
[snip]
>> Maybe we should create a new namespace package for "browser" code.
>>
>> How about "zope.browser"?
>
> My general sentiment is against creating more structure than we alread
Hey,
On Wed, Sep 3, 2008 at 5:41 PM, Stephan Richter
<[EMAIL PROTECTED]> wrote:
[snip]
> Jim must have read your message with a big smile on his face. He was arguing
> for this approach of flat package names about 2-3 years ago and I shot that
> proposal down. I hate when I only realize design mis
Hi there,
On Wed, Sep 3, 2008 at 4:34 PM, Hermann Himmelbauer <[EMAIL PROTECTED]> wrote:
[snip]
>> In megrok.rdb we've sketched out the reverse of your approach: derive
>> the Zope 3 schemas from the SQLAlchemy table definitions. This because
>> it's more easy to derive a basic schema from a table
Hey Hermann,
Hermann Himmelbauer wrote:
> In my current SQLAlchemy / Zope-based design, I need the following:
>
> - SQLAlchemy table definitions
> - classes + mappers
> - Zope interfaces
>
> The problem with this design is that much data has to be defined twice, e.g.
> the datatype "varchar(50)
Benji York wrote:
> On Wed, Sep 3, 2008 at 8:40 AM, David Pratt <[EMAIL PROTECTED]> wrote:
>
>> I am trying to avoid the need for selective forking that Chris has found
>> necessary to make progress with bfg. I want to continue using zope [...]
>
> +1 Experimental forks to help determine what re
Hi there,
Roger Ineichen wrote:
[snip]
> Is someone willing to help doing that task?
I'm very interested in this topic as well, especially from the
perspective of Grok of course.
There are many strategies to go ahead in doing this. I'll list just one
observation I've had here.
One observation
Hi there,
I just looked at the PyPI page of 'transaction':
http://pypi.python.org/pypi/transaction
And I see some weirdnesses:
* it's called 'transaction 1.0a1'
* the 'changes' claim however:
1.0 (unreleased)
What's up? Clearly something went wrong during the releasing of this
package, a
Hi there,
On Fri, Aug 22, 2008 at 4:03 PM, Chris Withers <[EMAIL PROTECTED]> wrote:
> Martijn Faassen wrote:
>>
>> The Grok project actually make this stuff (pinning down versions, etc)
>> easy.
>
> How does it do this?
It has a tool similar to zopeproject called
Chris Withers wrote:
> Philipp von Weitershausen wrote:
>>> and why does buildout pick it over a stable release?
>> Because buildout, like easy_install, will pick the newest available
>> version for a distribution. Fortunately, buildout has a prefer-stable
>> option so that you can tell it to pre
Benji York wrote:
[snip]
I also have inclinations to clean up the tests that don't fail, but have
other downsides (random confusing output to stderr, not supporting
layer teardown). I don't consider them to be release blockers, but I
think these would be nice to have in a 3.4.0 final.
3.4.0 is
Hey Stephan,
Thanks for doing all the work on KGS and the Zope 3.4.0 release.
There are unfortunately a few things in this process that have me
somewhat confused. I hope we can work out a way to clarify the process
for 3.4.x and helping to clarify the process for 3.5.x.
Firstly, could you ad
Hey,
On Mon, Jul 21, 2008 at 8:40 AM, ranjith kannikara
<[EMAIL PROTECTED]> wrote:
> During the porting of Zope2 I have now stuck with a failure in the
> module Products. in the file..
> /home/user-name/ztrunk25/lib/python/Products/Five/browser/tests/aqlegacy.py
> in line no: 96 assert self.aq_
Hey,
On Mon, Jul 21, 2008 at 9:55 AM, Malthe Borch <[EMAIL PROTECTED]> wrote:
> Martijn Faassen wrote:
>>
>> Thanks for the offer. I think this is up to Laurence to decide, I'd
>> say. I'm aiming my work at the 0.5 series so I'm fine with requiring
Hi there,
Thanks for the offer. I think this is up to Laurence to decide, I'd
say. I'm aiming my work at the 0.5 series so I'm fine with requiring
0.5.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/z
Stephan Richter wrote:
On Wednesday 16 July 2008, Philipp von Weitershausen wrote:
this came out of the ST project, where we constantly repeated this sort
of code.
Not that it matters much, but I think it was Martijn Faassen who wrote it.
... who worked on ST at the time and saw this pattern
Laurence Rowe wrote:
This is now fixed in trunk. For the moment I'm depending on SQLAlchemy
trunk for the new after_attach hook until beta3 is released.
Maybe it's time to start depending on 0.5?
No problem with that from my side, though of course I think this means
beta3 should be released
[taking some cc-s out, taking it also to grok-dev]
Brandon Craig Rhodes wrote:
[snip]
Do I sound on-target, or like I'm missing something?
I think there is definite room for improvement. Before you write
anything new though, you should explore z3c.pagelet. We started
discussing integrating t
Hi there,
On Thu, Jul 17, 2008 at 9:19 PM, Malthe Borch <[EMAIL PROTECTED]> wrote:
> Martijn Faassen wrote:
>> Could you be more explicit about what exactly in Grok was making too many
>> assumptions?
>
> First a word on terminology: I mean Grok, the framework, not t
Hey,
Chris McDonough wrote:
[snip]
Correct, if you're talking about using the Z3 publisher, although repoze.bfg is
based on zope.component and zope.interface internally.
I wasn't primarily thinking about the publisher, more about such things
like existing utilities, events, existing content t
Malthe Borch wrote:
Chris McDonough wrote:
I've been working on a new web framework named (provisionally)
repoze.bfg.
This looks very interesting; I'd be curious to see if this could be
useful for Vudo. I'd like it very much if Vudo could sit on top of a
more general framework (not just the
Hey,
Chris McDonough wrote:
[snip]
It's unlike Grok inasmuch as:
- It doesn't try to hide ZCML for configuration.
Hiding is the wrong word. Grok doesn't hide ZCML for configuration. It
simply replaces ZCML with a different configuration mechanism that I for
one think is an improvement. One
Baiju M wrote:
Hi all,
Few weeks back Buildout site become live, Jens Vagelpohl setup the
site at http://buildout.zope.org/ But I couldn't work further on the site.
If anyone want contribute to the content please add it here:
svn co svn://svn.zope.org/repos/main/buildout-website/trunk/
Hey,
Thanks Baiju for getting it this far and Jens for helping to set it up!
Jens Vagelpohl wrote:
On Jul 17, 2008, at 14:02 , Baiju M wrote:
Few weeks back Buildout site become live, Jens Vagelpohl setup the
site at http://buildout.zope.org/ But I couldn't work further on the
site.
I
Hi there,
Okay, so we can safely add Chris (and also Philipp) to the list of
people maintaining our windows binary eggs. Awesome! Chris, do you
think you can take it from here in getting an environment set up?
Regard,
Martijn
___
Zope-Dev maillist -
701 - 800 of 1205 matches
Mail list logo
