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)
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
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
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. I liked
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
___
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
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
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
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
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
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,
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
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
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?
We
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'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
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
17 matches
Mail list logo
