On Sat, Nov 29, 2008 at 11:37 AM, Tres Seaver <tseaver@palladion.com> wrote:

I did notice that revision 92597, whose log message was "Revert to an older zope.testing. New one is way too new", also bumpted zope.testbrowser from 3.4.2 to 3.5.1. Reverting to 3.4.2 doesn't get the tests to pass, however.

When this topic came up a few weeks ago I looked at the zope.testbrowser tests and they passed (IIRC) on both the trunk and 3.5.1 branches, so I'm not sure what's going on here... I just reran trunk and 3.5.1 and both pass, so I'm still confused.

I started to look at the zope.testbrowser failures, but gave up when I discovered the dependency snarl which its tests create: running the tests pulls in *all* of zope.app, including even rotterdam!

I suspect our old friend zope.app.zcmlfiles is the culprit there. I don't think it'd be too hard to reduce the test dependencies. I'm also not particularly motivated to do so either. ;)

Note that this means that any other package which wants to use zope.testbrowser to run functional tests also suffers, transitively, from the hairball.

Not exactly. The "test" extra is only needed for zope.testbrowser's tests. To use testbrowser in a functional test the base dependencies should do it. Well, not exactly; I just noticed that zope.app.testing would also be required, but you have to depend on that to do functional tests anyway. I'll look into making that dependency explicit. It'll probably mean adding a "zope" extra that no one will use because things work without it anyway. -- Benji York Senior Software Engineer Zope Corporation

On Sat, Nov 29, 2008 at 2:18 PM, Benji York <benji@zope.com> wrote:

I'm working on a new package (maybe named zope.functionaltesting) that will provide only what's needed for functional testing of Zope 3 apps using testbrowser without all the baggage of zope.app.testing (see http://hannosch.eu/zope2-dependencies/zope.app.testing.jpeg).

I give up. zope.app.testing.functional.HTTPCaller depends on zope.app.testing.functional.FunctionalTestSetup which opens a huge can of worms. I believe it's possible to reduce zope.app.testing.functional's dependencies, but it'll take a lot of work tracking down just what's needed and factoring out new components to break dependencies. -- Benji York Senior Software Engineer Zope Corporation

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:

Hi.

I just looked over this and fixed one test failure in Five.

I will trust that stubbing out the assertions in the 'update' method (revision 93450) is the Right Thing (TM).

In general all tests pass now, when run from the eggified Zope in:

svn://svn.zope.org/repos/main/Zope2.buildout/trunk

I guess that the zope.testbrowser problems are a mix of test interdependencies and maybe a differing mechanize version. The eggified Zope2 does not run tests for its dependencies but only for itself, so a lot less tests are run.

Secondly the normal Zope2 trunk pulls in mechanize as a SVN checkout from the Zope repository. The eggified version has a normal egg dependency and pulls in the later mechanize 0.1.9. I have no idea what version that mechanize in our SVN is actually.

I just vendor imported mechanize 0.1.9 into the Zope SVN, and have changed the svn:external in my Z2 trunk checkout to point to it. I then made a separate tree and vendor imported ClientForm 0.2.9, including hacking on the faked-out package we are using to support svn:externals, and switched the external to point to it. At this point, the 'aqlegacy_ftest' doctest still fails in my trunk sandbox, as does the 'zope.testborwser.README' doctest. I am therefore not checking in my svn:externals changes just yet. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJM3lY+gerLs4ltQ4RAonrAKDc/4VNsX0XRkKW8p/vNTqftlsx/wCfY1Mr TxKr3hOEgOQXcyIGtKzouBY= =NXAI -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:

Tres Seaver wrote:

...

Hanno Schlichting wrote:

...

In general all tests pass now, when run from the eggified Zope in: svn://svn.zope.org/repos/main/Zope2.buildout/trunk I just vendor imported mechanize 0.1.9 into the Zope SVN, and have changed the svn:external in my Z2 trunk checkout to point to it. I then made a separate tree and vendor imported ClientForm 0.2.9, including hacking on the faked-out package we are using to support svn:externals, and switched the external to point to it.

At this point, the 'aqlegacy_ftest' doctest still fails in my trunk sandbox, as does the 'zope.testborwser.README' doctest.

Hhm, the zope.testbrowser tests aren't run in the buildout version. It doesn't run tests for egg dependencies.

I tried this again and now that aqlegacy_ftest fails for me again as well. Either a test interdependency or a timing issue I'd guess.

My hypothesis is that one or more of the 'svn:externals' changes Sidnei made to bring in 2.6-compatible packages is the culprit (maybe an interaction between several of them). I am attaching readable diff for each of 'lib/python', 'lib/python/zope', and 'lib/python/zope/app'. As an aside / vent: the reason for the now-removed EXTERNALS.txt files was to keep the canonical information about the externals in a diffable file: why subversion can't do a proper diff on its own line-oriented property is beyond me. Another benefit of an EXTERNALS.txt file was that it could be inspected in the web view of a directory, which isn't true for the svn:externals property itself. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJN/NL+gerLs4ltQ4RApouAJ0WUYuUh3btoXQaLNNBLISqXcVFJACgyhsB YP0uIear89z8b5qP2x6F6Gs= =slqV -----END PGP SIGNATURE-----

On Thu, Dec 04, 2008 at 04:21:51PM +0100, Wichert Akkerman wrote:

Previously Tres Seaver wrote:

...

As an aside / vent: the reason for the now-removed EXTERNALS.txt files was to keep the canonical information about the externals in a diffable file: why subversion can't do a proper diff on its own line-oriented property is beyond me. Another benefit of an EXTERNALS.txt file was that it could be inspected in the web view of a directory, which isn't true for the svn:externals property itself.

If only svn.zope.org had a trac-based browser, which does show those properties properly...

Like this one: http://zope3.pov.lt/trac/browser ?

Wichert.

-- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ 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 http://mail.zope.org/mailman/listinfo/zope )

-- Brian Sutherland

Previously Godefroid Chapelle wrote:

Tres Seaver wrote:

...

As an aside / vent: the reason for the now-removed EXTERNALS.txt files was to keep the canonical information about the externals in a diffable file: why subversion can't do a proper diff on its own line-oriented property is beyond me. Another benefit of an EXTERNALS.txt file was that it could be inspected in the web view of a directory, which isn't true for the svn:externals property itself.

Tres.

I want to support this. The noise made by keeping EXTERNALS.txt in svn is very low compared to the signal it provides.

I don't. EXTERNALS.txt is only useful if your tools suck. There are perfectly capable svn commit mailers and web browsers that show property changes correctly. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.