On Mon, May 3, 2010 at 8:02 PM, Tres Seaver <tseaver@palladion.com> wrote:

Breakage in the following packages, but only on Python 2.4, and only in doctests:

- - zope.browserpage - - zope.viewlet - - zope.contentprovider - - zope.deferredimport

At least the first one is due to doctests not exposing an '__file__' in their faux-module globals under 2.4.  We might need to add Lennart's monkeypatch under 2.4, or else drop 2.4 support altogether.

Hhm. I'm inclined to drop 2.4 support here. Using a zope.testing that tries to be compatible all the way from 2.4 to 3.1 is quite a bit of a stretch. Hanno

Hanno Schlichting a écrit :

On Mon, May 3, 2010 at 8:02 PM, Tres Seaver <tseaver@palladion.com> wrote:

...

Breakage in the following packages, but only on Python 2.4, and only in doctests:

- - zope.browserpage - - zope.viewlet - - zope.contentprovider - - zope.deferredimport

At least the first one is due to doctests not exposing an '__file__' in their faux-module globals under 2.4. We might need to add Lennart's monkeypatch under 2.4, or else drop 2.4 support altogether.

Hhm. I'm inclined to drop 2.4 support here. Using a zope.testing that tries to be compatible all the way from 2.4 to 3.1 is quite a bit of a stretch.

Unless I missed something, the ZTK was globally compatible with Python2.4 recently, wasn't it? Do we want the latest changes and Lennart's work to be part of the ZTK 1.0? If not, the svn branches used for the ZTK 1.0dev should be updated to point to a maintenance branch. (I suppose it's our job) Christophe

Hanno _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )

On Tue, May 4, 2010 at 4:24 AM, Hanno Schlichting <hanno@hannosch.eu> wrote:

Dropping Python 2.4 supports makes most sense to me at this stage. Zope2/Plone only support Python 2.6 for any modern version.

I don't know what BlueBream and Grok want to support, but would guess they aim for Python 2.5 + 2.6 support. 2.4 is really old by now.

Python 2.4 will be supported for BB 1.0 release, but the package versions for that release is already freezed, so no problem for dropping 2.4 support. AFAIK, Grok 1.1 release versions are also freezed as a release candidate is out. Regards, Baiju M

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:

Hanno Schlichting wrote:

...

Dropping Python 2.4 supports makes most sense to me at this stage. Zope2/Plone only support Python 2.6 for any modern version.

I don't know what BlueBream and Grok want to support, but would guess they aim for Python 2.5 + 2.6 support. 2.4 is really old by now.

Grok 1.1 aims for 2.5 and 2.6. Grok 1.0 goes for 2.4 and 2.5, but Grok 1.0's stable so we don't have problems when the ZTK is updated.

Is there anybody running buildbots for those Grok releases? It would be good if the reports from such tests would make it to the zope-tests list, so that those of us not actively developing with Grok have a shot at knowing if something we did in the ZTK might have triggered breakage. Hmmm, the ZTK buildbots page[1] says that The Health Agency and Securactive are running Grok tests. The Health Agency page shows a fair number of tests for Grok sub-projects, but no one overall test which would be a sensible "smoke test" for exposing to non-Grok developers. The Securactive stuff seems to be offline (503s or non-resolvable hostnames). [1] http://docs.zope.org/zopetoolkit/process/buildbots.html 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvgIbYACgkQ+gerLs4ltQ6LoQCfYMeAHfQCC6x8VRJsfVlb+q6X MuUAoJRUDTh2vXvEvwH0ZVNuMe7QukRn =7ck1 -----END PGP SIGNATURE-----

On 4 May 2010 17:42, Sebastien Douche <sdouche@gmail.com> wrote:

On Tue, May 4, 2010 at 15:31, Tres Seaver <tseaver@palladion.com> wrote:

...

The Securactive stuff seems to be offline (503s or non-resolvable hostnames).

Hi Tres, Sorry for that, I've stopped accidentally the builbots this morning.

-- Sebastien Douche <sdouche@gmail.com>

Hi Tres, The Health Agency buildbots just moved office last week, will update them tomorrow. Cheers, -- Jan-Jaap Driessen

On Tue, May 4, 2010 at 00:41, Christophe Combelles <ccomb@free.fr> wrote:

Unless I missed something, the ZTK was globally compatible with Python2.4 recently, wasn't it?  Do we want the latest changes and Lennart's work to be part of the ZTK 1.0?

I think it's OK if they are not. Of course it would be cool if 1.0 does include the latest and greatest, but my changes are mostly aimed at Python 3 compatibility, and ZTK 1.0 will not have that as a whole anyway. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64

On Tue, May 4, 2010 at 12:07, Martijn Faassen <faassen@startifact.com> wrote:

For a while already people have been making changes that at least break tests on 2.4. For instance, zope.testing has some facility to pretty print a dictionary that sorts the keys, because Python 2.4's built-in pretty print module apparently doesn't do that yet, meaning random test failures can happen. But people have been updating code to use Python's built-in pretty print facility and this will only be reliable on Python 2.5 and higher.

Although that zope.testing facility has been deprecated, as far as I'm aware it's still there... If not maybe it should be reintroduced, we're suppose dto deprecate, not break in this case.

In my opinion it's time to drop Python 2.4 support anyway, but it's been going a bit haphazardly by way of bit rot..

Yeah, officially dropping is better than bitrot dropping it, that's for sure. And as mentioned, except for the "Bicycle toolkit" or whatever the name is, 2.4 is not needed any more. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64

On Mon, May 3, 2010 at 20:02, Tres Seaver <tseaver@palladion.com> wrote:

At least the first one is due to doctests not exposing an '__file__' in their faux-module globals under 2.4.  We might need to add Lennart's monkeypatch under 2.4, or else drop 2.4 support altogether.

Well, I don't want a monkey-patch product just for 2.4, and the monkeypatches was voted off from zope.testing because they are evil in the first place. The tests might pass __file__ in explicitly, maybe? Otherwise dropping 2.4 is probably the only reasonable option. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lennart Regebro wrote:

On Mon, May 3, 2010 at 20:02, Tres Seaver <tseaver@palladion.com> wrote:

...

- - zope.browserpage - - zope.viewlet - - zope.contentprovider - - zope.deferredimport

These tests all fail because as Tres pointed out, Python 2.4 doesn't set __file__ to the doctest filename in the globals. Zope.browserpage in turn uses those globals to determine the filename of the pagetemplate. So, you get an error if you create a browserpage in a DocTestFile, like so:

ErrorPage = SimpleViewClass(errorFileName, name='error.html')

Passing in file explicitly solves the problem:

ErrorPage = SimpleViewClass(errorFileName, name='error.html', offering={'__file__': 'README.txt'})

The same thing goes for ViewPagetemplateFile, but there it's called _prefix instead of offering. Yeah, none of those variable names make sense. It can also typically be fixed by passing in __file__ explicitly to the doctest:

def test_suite(): import doctest filename = os.path.join(os.pardir, 'namedtemplate.txt') return doctest.DocFileSuite( filename, setUp=pageSetUp, tearDown=zope.component.testing.tearDown, globs={'__file__': os.path.abspath(os.path.join(os.path.dirname(__file__), filename))} )

Other options is to make the usage of __file__ lazy, so that it's only looked up in the globals when accessed. Because I suspect it's not actually used except when you get errors, but I'm not 100% sure.

So for the time being, I went for passing in __file__ explicitly in globs. The tests run under Python 2.4 again.

Cool. I was afraid we were looking at something more insidious than that. 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvgFckACgkQ+gerLs4ltQ7mtwCfSlKCCD/dyzxDjT1SQTWokT5F qaAAoNYBsgA/PqKHdhnLXtRE9iJFy0Im =P4PS -----END PGP SIGNATURE-----