extras are a terrible feature. They aren't fully supported by
setuptools and they make it more complicated. Did you write tests
for every permutation of your extras?
Jim
On Sep 15, 2007, at 9:44 PM, Stephan Richter wrote:
On Saturday 15 September 2007 08:48, Benji York wrote:
1) introdu
On Saturday 15 September 2007 08:48, Benji York wrote:
> 1) introduce a "zope" extra that everyone will have to use (basically
> just rename "test" to "zope";
I prefer this solution. I have done this before for z3c.rml, where I put the
page template support into a "pagetemplate" extra declaration
Hi Benji. I don't like the first option. I am already using a zope
extras to group packages for other reasons and don't really want to mix
this with the test extra. I am trying to use extras as much as possible
opposed to listing reams of packages in buildout.cfg to keep it cleaner
and simpler.
I have a small issue with zope.testbrowser packaging I'd like to get
some input on. If I were to have started the project today, it would
likely have been zc.testbrowser, which would have no Zope 3 dependencies
(or functionality) and zc.testbrowser.zope, which would have, and
depended on zc.te
zope.testrowser 3.4.1 generates non-backward-compatible tracebacks for
HTTP errors. 3.4.2 will be released soon(-ish) to fix this, in the mean
time please continue to use 3.4.0. Thanks.
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope
Hey folks,
Two part question:
1) What's the maintenance status of zope.testbrowser on cheeseshop?
2) If people are too busy to keep it updated, I'd be willing to
package it and post it whenever a new version of zope is released.
The reason I ask is that I was demoing some testing work for someo
Adam Groszer wrote:
Happened to pass a unicode instead of str URL to browser.open().
That caused a nasty exception in Cookie.py.
Might be worth an assert()?
I don't think so, but it's really more of a question for the mechanize
list: [EMAIL PROTECTED]
--
Benji York
Senior Software Engineer
Zo
Hello,
Happened to pass a unicode instead of str URL to browser.open().
That caused a nasty exception in Cookie.py.
Might be worth an assert()?
--
Best regards,
Adam
--
Quote of the day:
Look and you will find it-what is unsought will go undetected.
- Sophocles
___
On Monday 26 June 2006 19:29, Martin Aspeli wrote:
> This works fine through the web, but using zope.testbrowser, the # gets
> converted to %23 (which is the correct urlencoding of #). The url
> /pat/to/foo/%23bar is not valid, and I get a 404.
I have experienced this error with our namespaces (++
Hi,
I've got a situation where a form submit will eventually end up in an
action that does (in Zope 2):
context.REQUEST.RESPONSE.redirect('/path/to/foo/#bar')
This works fine through the web, but using zope.testbrowser, the # gets
converted to %23 (which is the correct urlencoding of
Benji York wrote:
I actually don't want to support any exposure of mechanize
functionality in zope.testbrowser. Mechanize is an implementation
detail (although a very important one) and may change in the future.
I think the documentation I added makes this clear.
It doesn't,
"""
testbrow
Benji York wrote:
Jim Fulton wrote:
I'd rather not see it force a 2.4 requirement in 3.2.
Definitely. If it's the only thing in 3.2 that wants 2.4, then it'll be
back ported.
Does mechanize depend on 2.4? How much work would it take to convert out code?
Certainly not much. Can we pleas
Jim Fulton wrote:
I'd rather not see it force a 2.4 requirement in 3.2.
Definitely. If it's the only thing in 3.2 that wants 2.4, then it'll be
back ported.
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-de
I've put up the first cut of a proposal to include zope.testbrowser in
3.2 at
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/BrowserObjectForFunctionalTests
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing
Benji York wrote:
Now that 3.1 has been branched, I was planning on merging
zope.testbrowser into the trunk, but because it depends on 2.4 I'm
unsure about that now. Should I just merge it and back port it to 2.3
if necessary, or should I just wait and see?
Unless there's a deep reason why i
On Monday 01 August 2005 09:04, Benji York wrote:
> Now that 3.1 has been branched, I was planning on merging
> zope.testbrowser into the trunk, but because it depends on 2.4 I'm
> unsure about that now. Should I just merge it and back port it to 2.3
> if necessary, or should I just wait and see?
Now that 3.1 has been branched, I was planning on merging
zope.testbrowser into the trunk, but because it depends on 2.4 I'm
unsure about that now. Should I just merge it and back port it to 2.3
if necessary, or should I just wait and see?
--
Benji York
Senior Software Engineer
Zope Corporatio
17 matches
Mail list logo
