Hi there, What do people feel about dropping Python 2.4 support in the Zope Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave vaguely as we *still* don't have a canonical list) only have to work in Python 2.5 (and preferably 2.6), not Python 2.4 anymore. (this won't affect Zope 3.4 or below) One issue that came up recently was that .tgz releases to PyPI sometimes break with Python 2.4 due to a bug in Python 2.4. Using --zip is a workaround. And Plone currently depends on Python 2.4. Is it possible to work around this by *also* uploading a zip if we discover there's a problem with a package and it's pointed out there? If not, are there other workarounds? What do Zope 2 and Plone people in general think about moving to Python 2.5 for the newer releases? I'll note we're shuffling around the dependency structure so much in the Zope Toolkit it's unlikely everything will remain compatible for that reason as well. Regards, Martijn
Martijn Faassen wrote:
Hi there,
What do people feel about dropping Python 2.4 support in the Zope Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave vaguely as we *still* don't have a canonical list) only have to work in Python 2.5 (and preferably 2.6), not Python 2.4 anymore.
(this won't affect Zope 3.4 or below)
One issue that came up recently was that .tgz releases to PyPI sometimes break with Python 2.4 due to a bug in Python 2.4. Using --zip is a workaround. And Plone currently depends on Python 2.4. Is it possible to work around this by *also* uploading a zip if we discover there's a problem with a package and it's pointed out there? If not, are there other workarounds?
What do Zope 2 and Plone people in general think about moving to Python 2.5 for the newer releases? I'll note we're shuffling around the dependency structure so much in the Zope Toolkit it's unlikely everything will remain compatible for that reason as well.
The Plone 3.x series will stay on Python 2.4 for a long time yet, so this would be very disappointing. I can understand it if the maintenance burden becomes large, or if there are compelling features of 2.5/2.6 that we really want to make use of. The tgz issue seems like a pretty weak reason, though, especially since there are workarounds. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On 27.04.2009 16:48 Uhr, Martin Aspeli wrote:
Martijn Faassen wrote:
Hi there,
What do people feel about dropping Python 2.4 support in the Zope Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave vaguely as we *still* don't have a canonical list) only have to work in Python 2.5 (and preferably 2.6), not Python 2.4 anymore.
(this won't affect Zope 3.4 or below)
One issue that came up recently was that .tgz releases to PyPI sometimes break with Python 2.4 due to a bug in Python 2.4. Using --zip is a workaround. And Plone currently depends on Python 2.4. Is it possible to work around this by *also* uploading a zip if we discover there's a problem with a package and it's pointed out there? If not, are there other workarounds?
What do Zope 2 and Plone people in general think about moving to Python 2.5 for the newer releases? I'll note we're shuffling around the dependency structure so much in the Zope Toolkit it's unlikely everything will remain compatible for that reason as well.
The Plone 3.x series will stay on Python 2.4 for a long time yet, so this would be very disappointing.
What would be disappointing? Andreas
Andreas Jung wrote:
What would be disappointing?
To be unable to use new packages from an updated Zope Toolkit. It may be that some (many?) packages won't work with Zope 2.10, but if we get the kind of dependency isolation we're talking about, I'd wager that quite a few packages would work if pulled in independently. It's also generally silly to break compatibility with a platform if there's not a compelling reason to do so. I suspect there may be compelling reasons, but the TAR file issue isn't one of them. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On 27.04.2009 17:07 Uhr, Martin Aspeli wrote:
Andreas Jung wrote:
What would be disappointing?
To be unable to use new packages from an updated Zope Toolkit.
It may be that some (many?) packages won't work with Zope 2.10, but if we get the kind of dependency isolation we're talking about, I'd wager that quite a few packages would work if pulled in independently.
Would it be much work bringing Plone 3.X to Zope 2.12? Andreas
Andreas Jung wrote:
On 27.04.2009 17:07 Uhr, Martin Aspeli wrote:
Andreas Jung wrote:
What would be disappointing?
To be unable to use new packages from an updated Zope Toolkit.
It may be that some (many?) packages won't work with Zope 2.10, but if we get the kind of dependency isolation we're talking about, I'd wager that quite a few packages would work if pulled in independently.
Would it be much work bringing Plone 3.X to Zope 2.12?
It would be interesting to make it optional. I don't think we can make it required - too big a change for people using Plone 3.x and expecting forwards compatibility with new versions. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote:
Andreas Jung wrote:
What would be disappointing?
To be unable to use new packages from an updated Zope Toolkit.
It may be that some (many?) packages won't work with Zope 2.10, but if we get the kind of dependency isolation we're talking about, I'd wager that quite a few packages would work if pulled in independently.
Probably less than you think, unless you pulled in *all* of the new packages. If not, you tend to get loops where package A depends on B which depends on A.app (which got moved to A, but B doesn't know that are you only use the new A, not the new B). And then you'll pull in other versions of the same code that now lives in A, and tests will break.
It's also generally silly to break compatibility with a platform if there's not a compelling reason to do so. I suspect there may be compelling reasons, but the TAR file issue isn't one of them.
The reasons would be the familiar ones of "we have limited resources" combined with "we got to get a move on to Python 2.6, and then possibly on to Python 3, probably through 2.7", with a dash of "it'd be cool to be able to use the 'with' statement" and "some packages might only work in Python 2.5". Compelling? That depends on whether any of the objections to such a move are compelling enough. :) Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote:
The Plone 3.x series will stay on Python 2.4 for a long time yet, so this would be very disappointing. I can understand it if the maintenance burden becomes large, or if there are compelling features of 2.5/2.6 that we really want to make use of. The tgz issue seems like a pretty weak reason, though, especially since there are workarounds.
"Stability or goodies, pick one". If you can't upgrade to a newer Python / Zope, you can't use the ZTK, which *cannot* be constrained by backwared compatiblity with pre-2.12 Zope versions: those versions are stuck with using the Zope 3.3 / 3.4 trees on which they were originally based, just as they are stuck with Python 2.4. 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 iD8DBQFJ9c/5+gerLs4ltQ4RAn3OAJ44lr3NpqK4zsqJB4tqxq0Df9yyIACgzeEV gxn1gqQeduZaFKqE2GERbSg= =ippb -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote:
Martin Aspeli wrote:
The Plone 3.x series will stay on Python 2.4 for a long time yet, so this would be very disappointing. I can understand it if the maintenance burden becomes large, or if there are compelling features of 2.5/2.6 that we really want to make use of. The tgz issue seems like a pretty weak reason, though, especially since there are workarounds.
"Stability or goodies, pick one". If you can't upgrade to a newer Python / Zope, you can't use the ZTK, which *cannot* be constrained by backwared compatiblity with pre-2.12 Zope versions: those versions are stuck with using the Zope 3.3 / 3.4 trees on which they were originally based, just as they are stuck with Python 2.4.
Thinking further on this: there is actually not much "shiny" about the ZTK: it is going to be equivalent to a cut-down, dependency-stripped, bbb-cruft-sanded version of the packages already shipping with Zope 2.10.x / 2.11.x. Until Plone quits using Zope2 altogether (likely never, AFAIK) Plone has no direct interest in the ZTK, which is just a layer of the Zope2 stack from Plone's perspective. 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 iD8DBQFJ9daE+gerLs4ltQ4RAtmvAJsGD68zXZUod1LIyD1/B1oYfSlZOwCgiR+e eNQ2a+aI8VtZMxgQe+M+p60= =7jUW -----END PGP SIGNATURE-----
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tres Seaver wrote:
Martin Aspeli wrote:
The Plone 3.x series will stay on Python 2.4 for a long time yet, so this would be very disappointing. I can understand it if the maintenance burden becomes large, or if there are compelling features of 2.5/2.6 that we really want to make use of. The tgz issue seems like a pretty weak reason, though, especially since there are workarounds. "Stability or goodies, pick one". If you can't upgrade to a newer Python / Zope, you can't use the ZTK, which *cannot* be constrained by backwared compatiblity with pre-2.12 Zope versions: those versions are stuck with using the Zope 3.3 / 3.4 trees on which they were originally based, just as they are stuck with Python 2.4.
Thinking further on this: there is actually not much "shiny" about the ZTK: it is going to be equivalent to a cut-down, dependency-stripped, bbb-cruft-sanded version of the packages already shipping with Zope 2.10.x / 2.11.x. Until Plone quits using Zope2 altogether (likely never, AFAIK) Plone has no direct interest in the ZTK, which is just a layer of the Zope2 stack from Plone's perspective.
In practice, though, people are using packages from newer Zope releases in third party products, and, possibly, in Plone core. One example is z3c.form, which requires you to upgrade zope.i18n and zope.component That works fine, FWIW. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote:
Tres Seaver wrote:
Thinking further on this: there is actually not much "shiny" about the ZTK: it is going to be equivalent to a cut-down, dependency-stripped, bbb-cruft-sanded version of the packages already shipping with Zope 2.10.x / 2.11.x. Until Plone quits using Zope2 altogether (likely never, AFAIK) Plone has no direct interest in the ZTK, which is just a layer of the Zope2 stack from Plone's perspective.
In practice, though, people are using packages from newer Zope releases in third party products, and, possibly, in Plone core.
One example is z3c.form, which requires you to upgrade zope.i18n and zope.component That works fine, FWIW. :)
But it won't be "supported". Mix-and-match is not what the toolkit (or the related KGS / index stuff) is designed for. 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 iD8DBQFJ9d6++gerLs4ltQ4RAiYnAKDJFrQ2Bp4Bd6mwJjXoZqVJuSMzigCglARB VrBWI/9TEvGrDuS8YV+/86o= =Z+vD -----END PGP SIGNATURE-----
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Aspeli wrote:
Tres Seaver wrote:
Thinking further on this: there is actually not much "shiny" about the ZTK: it is going to be equivalent to a cut-down, dependency-stripped, bbb-cruft-sanded version of the packages already shipping with Zope 2.10.x / 2.11.x. Until Plone quits using Zope2 altogether (likely never, AFAIK) Plone has no direct interest in the ZTK, which is just a layer of the Zope2 stack from Plone's perspective. In practice, though, people are using packages from newer Zope releases in third party products, and, possibly, in Plone core.
One example is z3c.form, which requires you to upgrade zope.i18n and zope.component That works fine, FWIW. :)
But it won't be "supported". Mix-and-match is not what the toolkit (or the related KGS / index stuff) is designed for.
Sure. Which is why I said it would be disappointing (as opposed to negligent) if Python 2.4 support were dropped. ;) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On 27.04.2009 16:44 Uhr, Martijn Faassen wrote:
Hi there,
What do people feel about dropping Python 2.4 support in the Zope Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave vaguely as we *still* don't have a canonical list) only have to work in Python 2.5 (and preferably 2.6), not Python 2.4 anymore.
New releases should mean new major releases e.g. 3.X -> 3.X+1
(this won't affect Zope 3.4 or below)
One issue that came up recently was that .tgz releases to PyPI sometimes break with Python 2.4 due to a bug in Python 2.4. Using --zip is a workaround. And Plone currently depends on Python 2.4. Is it possible to work around this by *also* uploading a zip if we discover there's a problem with a package and it's pointed out there? If not, are there other workarounds?
What do Zope 2 and Plone people in general think about moving to Python 2.5 for the newer releases?
Zope 2.12 already *requires* Python 2.5 or 2.6. Python 2.4 support in Zope 2.12 is inofficial. Zope 2.12 will ship with those Z3 modules there are compatible and stable. Andreas
Martijn Faassen wrote:
What do people feel about dropping Python 2.4 support in the Zope Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave vaguely as we *still* don't have a canonical list) only have to work in Python 2.5 (and preferably 2.6), not Python 2.4 anymore.
Btw. I just updated the Zope2 KGS over the weekend again at http://svn.zope.org/*checkout*/Zope/trunk/versions.cfg It contains the latest released version of everything Zope2 depends on at least. So it should be a good base for deciding what exactly the Zope Toolkit is.
What do Zope 2 and Plone people in general think about moving to Python 2.5 for the newer releases? I'll note we're shuffling around the dependency structure so much in the Zope Toolkit it's unlikely everything will remain compatible for that reason as well.
As others mentioned as long as there's no good compelling reason to drop support for a Python version I'd rather not do it. Andreas mentioned the policy for Zope 2.12: It ain't officially supported, but we won't break it without a good reason. The Plone policy is: For 3.x is: stuck with Python 2.4 For 4.0: We require Python 2.6 and won't even support 2.5. But Plone 4.0 is future-ware that will be released sometime next year. Hanno
Am Montag 27 April 2009 16:44:17 schrieb Martijn Faassen:
Hi there,
What do people feel about dropping Python 2.4 support in the Zope Toolkit? I.e. new releases of packages in the Zope Toolkit (handwave vaguely as we *still* don't have a canonical list) only have to work in Python 2.5 (and preferably 2.6), not Python 2.4 anymore.
It may well be that people (even I myself) use e.g. zope.interfaces or some other package in some Zope related or unrelated product where it is necessary due to some other dependencies to maintain Python 2.4 compatibility. Therefore I would rather not suggest to drop support for Python 2.4, however, if this is a major blocker, it's acceptable (for me). Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Hey, On Mon, Apr 27, 2009 at 6:39 PM, Hermann Himmelbauer <dusty@qwer.tk> wrote:
It may well be that people (even I myself) use e.g. zope.interfaces or some other package in some Zope related or unrelated product where it is necessary due to some other dependencies to maintain Python 2.4 compatibility.
Therefore I would rather not suggest to drop support for Python 2.4, however, if this is a major blocker, it's acceptable (for me).
That's a good point; zope.interface and zope.component probably should remain 2.4 compatible as they are so low in the stack and have the most "outside" use. Regards, Martijn
Hey, In order to get to a conclusion: I haven't seen convincing arguments yet *not* to drop the Python 2.4 for new releases of the Zope Toolkit libraries. I'd like to phrase the debate in those terms instead of the reverse, because ensuring Python 2.4 compatibility is an additional burden for developers and we need good arguments for *not* dropping this burden. There is some discussion that Plone 3.x on Zope 2.10 could maybe use Zope Toolkit libraries somehow and that there would be a problem if we dropped Python 2.4 support. I still don't quite see how this can happen, as it already uses Zope 3.x, right? You can't use multiple versions of both libraries at the same time. I tried to explain how it's problematic to mix libraries that are post-dependency-refactoring with libraries from *before* the dependency refactoring. I think we have two libraries with a special status that should retain Python 2.4 support for the time being: zope.interface and zope.component. Any other arguments against dropping Python 2.4 support for the other libraries? If not, I'll record this as a Zope Toolkit Steering Group decision soon. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Hey,
In order to get to a conclusion:
I haven't seen convincing arguments yet *not* to drop the Python 2.4 for new releases of the Zope Toolkit libraries.
I'd like to phrase the debate in those terms instead of the reverse, because ensuring Python 2.4 compatibility is an additional burden for developers and we need good arguments for *not* dropping this burden.
There is some discussion that Plone 3.x on Zope 2.10 could maybe use Zope Toolkit libraries somehow and that there would be a problem if we dropped Python 2.4 support. I still don't quite see how this can happen, as it already uses Zope 3.x, right? You can't use multiple versions of both libraries at the same time. I tried to explain how it's problematic to mix libraries that are post-dependency-refactoring with libraries from *before* the dependency refactoring.
I agree strongly that using the ZTK isn't going to be feasible for Plone unless / until they move it to a post-dependency-factored version of Zope2.
I think we have two libraries with a special status that should retain Python 2.4 support for the time being: zope.interface and zope.component.
I would argue for a couple more, which make up the "under the bicycle seat" version of the ZTK likely to see wider use outside of zope: - zope.event (a dependency of zope.component) - zope.schema - zope.i18nmessageid (a dependency of zope.schema) BFG, which currently supports Python 2.4, uses some other zope.* packages: - zope.configuration - zope.deferredimport - zope.deprecation - zope.hookable - zope.i18n - zope.proxy - zope.testing That isn't an argument to keep those packages in the "must support Python 2.4" camp, as long as newer versions bump their major version numbers: BFG installs from its own index, which would just exclude those newer versions untill BFG drops 2.4 support. 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 iD8DBQFJ9xdp+gerLs4ltQ4RAi9bAJ9MQYZUTxAo/43OyKimfW/LNqxv6ACfatWW FYA+EX5ATlreRrRZkiSv/Vw= =G/Dl -----END PGP SIGNATURE-----
Hey, Martijn Faassen wrote:
In order to get to a conclusion:
I haven't seen convincing arguments yet *not* to drop the Python 2.4 for new releases of the Zope Toolkit libraries.
I'd like to phrase the debate in those terms instead of the reverse, because ensuring Python 2.4 compatibility is an additional burden for developers and we need good arguments for *not* dropping this burden.
Since I haven't seen such arguments besides the Plone 3.x related ones, I will amend the zope toolkit decisions about this. Regards, Martijn
Martijn Faassen wrote:
Hey,
Martijn Faassen wrote:
In order to get to a conclusion:
I haven't seen convincing arguments yet *not* to drop the Python 2.4 for new releases of the Zope Toolkit libraries.
I'd like to phrase the debate in those terms instead of the reverse, because ensuring Python 2.4 compatibility is an additional burden for developers and we need good arguments for *not* dropping this burden.
Since I haven't seen such arguments besides the Plone 3.x related ones, I will amend the zope toolkit decisions about this.
We've had some more discussions about this and the Plone release schedule. The upshot is that if Zope 3/Toolkit drops Python 2.4 support, it will effectively render it inaccessible to Plone users for the next 12-18 months. We're not comfortable moving to Zope 2.12 for the 3.x series. We may be able to move to Zope 2.11, which *may* work with Python 2.5, but this is not clear. That makes the potential user base for new-and-dependency-isolated Zope components quite a bit smaller. I agree that some of the refactored ZTK components don't make sense if they're bundled with Zope 2.10 in pre-refactored form. However, the idea is surely also to support new and more focused components in the toolkit. At the end of the day, it may not make much of a difference. However, I am still puzzled as to why we you are trying to base a decision on arguments *against* breaking compatibility. The main argument *for* dropping compatibility seems to be a hand-wave towards an added maintenance burden. Is that really so? Are we struggling to release components that work across Python versions? If there are Python 2.5 features we really want to use, then I understand. Otherwise, I think as a general principle it makes sense to always aim for the widest amount of compatibility possible, at least when it comes to the core Zope Toolkit, which, by its very nature, aims to underpin a number of heterogeneous platforms with different constraints. I'd rather hope Plone was considered one of those platforms. ;) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Tue, May 5, 2009 at 11:55, Martin Aspeli <optilude+lists@gmail.com> wrote:
We've had some more discussions about this and the Plone release schedule. The upshot is that if Zope 3/Toolkit drops Python 2.4 support, it will effectively render it inaccessible to Plone users for the next 12-18 months. We're not comfortable moving to Zope 2.12 for the 3.x series. We may be able to move to Zope 2.11, which *may* work with Python 2.5, but this is not clear.
Can you expand on this argument, because I don't understand it. Zope 2.10 doesn't stop working because Zope 2.12 no longer supports Python 2.4. And you are not expected to use Zope Toolkit with Zope 2.10, as Zope 2.10 uses Zope 3.3 rather than Zope Toolkit. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Previously Lennart Regebro wrote:
On Tue, May 5, 2009 at 11:55, Martin Aspeli <optilude+lists@gmail.com> wrote:
We've had some more discussions about this and the Plone release schedule. The upshot is that if Zope 3/Toolkit drops Python 2.4 support, it will effectively render it inaccessible to Plone users for the next 12-18 months. We're not comfortable moving to Zope 2.12 for the 3.x series. We may be able to move to Zope 2.11, which *may* work with Python 2.5, but this is not clear.
Can you expand on this argument, because I don't understand it. Zope 2.10 doesn't stop working because Zope 2.12 no longer supports Python 2.4. And you are not expected to use Zope Toolkit with Zope 2.10, as Zope 2.10 uses Zope 3.3 rather than Zope Toolkit.
But you can use a lot of the Zope Toolkit with Zope 2.10, which is an enormous benefit. If that was not possible a lot of the things people want to do with Plone would not be possible. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote: [snip]
But you can use a lot of the Zope Toolkit with Zope 2.10, which is an enormous benefit.
No, you can't, as far as I can tell. You'd have to remove Zope 3 entirely from Zope 2.10, and Plone relies on Zope 3, so this sounds unfeasible. The burden of evidence is on the people making this claim.
If that was not possible a lot of the things people want to do with Plone would not be possible.
I don't understand what you're saying here. Regards, Martijn
Martijn Faassen wrote:
Wichert Akkerman wrote: [snip]
But you can use a lot of the Zope Toolkit with Zope 2.10, which is an enormous benefit.
No, you can't, as far as I can tell. You'd have to remove Zope 3 entirely from Zope 2.10, and Plone relies on Zope 3, so this sounds unfeasible. The burden of evidence is on the people making this claim.
Sorry, but we do this all the time. Thanks to buildout and explicit version pins its a piece of cake to get a zope.i18n 3.6 or whatever version used instead of the zope.i18n shipped inside the Zope2 tarball. I haven't done a project for more than two years now where I didn't upgrade one of the zope.* packages with some newer version. Hanno P.S. Note that to make this happen we added the whole fake-zope-eggs story to the zope2install recipe, so all the zope.* packages inside the tarball are exposed as if they where installed as eggs.
Hey, Hanno Schlichting wrote:
Martijn Faassen wrote:
Wichert Akkerman wrote: [snip]
But you can use a lot of the Zope Toolkit with Zope 2.10, which is an enormous benefit. No, you can't, as far as I can tell. You'd have to remove Zope 3 entirely from Zope 2.10, and Plone relies on Zope 3, so this sounds unfeasible. The burden of evidence is on the people making this claim.
Sorry, but we do this all the time. Thanks to buildout and explicit version pins its a piece of cake to get a zope.i18n 3.6 or whatever version used instead of the zope.i18n shipped inside the Zope2 tarball.
I haven't done a project for more than two years now where I didn't upgrade one of the zope.* packages with some newer version.
Since we moved stuff around a lot, it isn't just a matter of upgrading a few packages here and there. Matters can be quite surprising. See elsewhere in the thread where I describe troublesome scenarios. Perhaps even with these surprises things work well enough for people to have a working Plone install after this is done. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wichert Akkerman wrote:
Previously Lennart Regebro wrote:
On Tue, May 5, 2009 at 11:55, Martin Aspeli <optilude+lists@gmail.com> wrote:
We've had some more discussions about this and the Plone release schedule. The upshot is that if Zope 3/Toolkit drops Python 2.4 support, it will effectively render it inaccessible to Plone users for the next 12-18 months. We're not comfortable moving to Zope 2.12 for the 3.x series. We may be able to move to Zope 2.11, which *may* work with Python 2.5, but this is not clear. Can you expand on this argument, because I don't understand it. Zope 2.10 doesn't stop working because Zope 2.12 no longer supports Python 2.4. And you are not expected to use Zope Toolkit with Zope 2.10, as Zope 2.10 uses Zope 3.3 rather than Zope Toolkit.
But you can use a lot of the Zope Toolkit with Zope 2.10, which is an enormous benefit. If that was not possible a lot of the things people want to do with Plone would not be possible.
What benefit? The ZTK is a mostly-equivalent subset of the Zope 3.3 shipped with Zope 2.10.x already. There is nothing "shiny" about using the ZTK (new features, etc.). If Plone 3.x can't afford to move the Zope 2.12, then it *definitely* can't use the ZTK. Moving the ZTK creates *wildly* more BBB issues / instability risks than 2.12 ever would. Constraining the ZTK to fit this weird pattern you guys have of trying to cherry pick bits of it is an anti-goal. 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 iD8DBQFKAIwd+gerLs4ltQ4RAn4BAJ41Fw5D0dMYxYlm2a+2naeIiyXlLACeJdAR 9hGT5evpf4nOZRIomcxorYI= =bfcl -----END PGP SIGNATURE-----
On Tue, May 5, 2009 at 13:27, Wichert Akkerman <wichert@wiggy.net> wrote:
But you can use a lot of the Zope Toolkit with Zope 2.10, which is an enormous benefit. If that was not possible a lot of the things people want to do with Plone would not be possible.
Let's be clear here: Do you mean that you need, in Plone, to use the latest versions of many zope.* packages? When I look in the eggs directory of a new Plone buildout, there are no zope.* packages there. That seems to indicate that Plone is happy to use the versions that come with Zope 2.10. These will not stop working with 2.4 just because later versions do so. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Previously Lennart Regebro wrote:
On Tue, May 5, 2009 at 13:27, Wichert Akkerman <wichert@wiggy.net> wrote:
But you can use a lot of the Zope Toolkit with Zope 2.10, which is an enormous benefit. If that was not possible a lot of the things people want to do with Plone would not be possible.
Let's be clear here: Do you mean that you need, in Plone, to use the latest versions of many zope.* packages?
No, I need to use some later versions of some packages than included in Zope 2.10 to be able to use things like z3c.form and dexterity. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Wed, May 6, 2009 at 09:55, Wichert Akkerman <wichert@wiggy.net> wrote:
No, I need to use some later versions of some packages than included in Zope 2.10 to be able to use things like z3c.form and dexterity.
Well, mixing versions and using versions of packages that differ several years in release dat will always be possible, but "on your own risk" so to speak. We do seem to have reached the conclusion now that 2.4 support should continue and be handled by 2.4 buildbots, which is good. But as a principle we can't expect zope.anything from 2009 to work with zope.everything from 2006, even if both run under Python 2.4 (Which is why we have KGS's). Keeping that sort of compatibility is going to be more work than keeping 2.4 compatibility, and is practically untestable in the general case (but well testable in the specific case, of course). -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro wrote:
On Tue, May 5, 2009 at 11:55, Martin Aspeli <optilude+lists@gmail.com> wrote:
We've had some more discussions about this and the Plone release schedule. The upshot is that if Zope 3/Toolkit drops Python 2.4 support, it will effectively render it inaccessible to Plone users for the next 12-18 months. We're not comfortable moving to Zope 2.12 for the 3.x series. We may be able to move to Zope 2.11, which *may* work with Python 2.5, but this is not clear.
Can you expand on this argument, because I don't understand it. Zope 2.10 doesn't stop working because Zope 2.12 no longer supports Python 2.4. And you are not expected to use Zope Toolkit with Zope 2.10, as Zope 2.10 uses Zope 3.3 rather than Zope Toolkit.
- I think that as a principle, dropping support for a Python version that's commonly used in our community, should be a decision that requires a strong argument *for*, not a strong argument *against*. - The Zope Tool Kit aims to be a bridge between our different communities, and possibly other communities that may want to consume Zope software (are all of those using Python 2.5?). That means that those of us who are not in a position to move to Python 2.5+ soon deserve to be heard. Of course, Plone's point of view shouldn't be overriding to other concerns, but see point 1. - If you count the "Zope community" as those who also maintain Zope 2, we need to recognise that there's been no viable way for Plone to get to Python 2.5 until now, and the other changes in 2.12 mean it's not feasible to upgrade to it in the 3.x series. This is nobody's fault, of course, but it does leave a chasm that'll only widen as time goes on. - Once the ZTK is decreed to no longer need to support Python 2.4, I suspect no new development on the Zope platform will bother with it either. That means users of Plone can't use these packages. That in turn deprives those Zope packages of testers and potential contributors. - We are using Zope 3.4+ packages successfully with Zope 2.10 right now. I don't see that the ZTK will be any different. In fact, ZTK should help here, because we're getting a saner dependency structure. The Plone community is working hard to move to Python 2.5, but reality is we won't get there for another 12-18 months, in part because Zope 2.12 is only now entering alpha and incorporates a lot of other (good!) changes that we need more time to integrate and work out a migration story for. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Tue, May 5, 2009 at 8:07 AM, Martin Aspeli <optilude+lists@gmail.com<optilude%2Blists@gmail.com>
wrote:
Lennart Regebro wrote:
Can you expand on this argument, because I don't understand it. Zope 2.10 doesn't stop working because Zope 2.12 no longer supports Python 2.4. And you are not expected to use Zope Toolkit with Zope 2.10, as Zope 2.10 uses Zope 3.3 rather than Zope Toolkit.
- I think that as a principle, dropping support for a Python version that's commonly used in our community, should be a decision that requires a strong argument *for*, not a strong argument *against*.
- The Zope Tool Kit aims to be a bridge between our different communities, and possibly other communities that may want to consume Zope software (are all of those using Python 2.5?). That means that those of us who are not in a position to move to Python 2.5+ soon deserve to be heard. Of course, Plone's point of view shouldn't be overriding to other concerns, but see point 1.
- If you count the "Zope community" as those who also maintain Zope 2, we need to recognise that there's been no viable way for Plone to get to Python 2.5 until now, and the other changes in 2.12 mean it's not feasible to upgrade to it in the 3.x series. This is nobody's fault, of course, but it does leave a chasm that'll only widen as time goes on.
- Once the ZTK is decreed to no longer need to support Python 2.4, I suspect no new development on the Zope platform will bother with it either. That means users of Plone can't use these packages. That in turn deprives those Zope packages of testers and potential contributors.
- We are using Zope 3.4+ packages successfully with Zope 2.10 right now. I don't see that the ZTK will be any different. In fact, ZTK should help here, because we're getting a saner dependency structure.
The Plone community is working hard to move to Python 2.5, but reality is we won't get there for another 12-18 months, in part because Zope 2.12 is only now entering alpha and incorporates a lot of other (good!) changes that we need more time to integrate and work out a migration story for.
Martin
+1 Speaking from the context of my own primary zopey project (Py2.4-only OpenCore, which depends directly on Plone and increasingly on various zope.* packages) and as a user of Plone, I hope that the main-line ZTK would continue to support Py2.4 for a while longer. Announcing a "dropping Py2.4 support" deadline of, say, a year from now would give those of us still on Py2.4 time to prepare for that future, whether by getting our products onto 2.5 in time, or by gathering together a community to maintain 2.4-compatible versions of the necessary packages. I think that in the medium term, maintaining 2.4 support (at least during a smooth transition period) could theoretically *lower* the ZTK maintenance burden significantly -- for example if the Plone community has the ability to experiment with newer versions of the ZTK or ZTK packages than Zope2, this could provide forward momentum for Zope2's own ZTK dependency as the results of those experiments feed back upstream to Zope2's stable KGS. I know we're talking about unspecified future additions to a still fuzzy set of packages, so, to be as concrete as possible, I've been increasingly hoping to track at least zope.i18n development as closely as possible in OpenCore, using the ZTK/Zope2/Plone KGSes as a baseline rather than a hard requirement. I've been looking forward to trying out other packages in that context as well as the ZTK and dependency unravelling makes casual experimentation easier. egj
On Tuesday 05 May 2009, Martin Aspeli wrote:
Since I haven't seen such arguments besides the Plone 3.x related ones, I will amend the zope toolkit decisions about this.
We've had some more discussions about this and the Plone release schedule. The upshot is that if Zope 3/Toolkit drops Python 2.4 support, it will effectively render it inaccessible to Plone users for the next 12-18 months. We're not comfortable moving to Zope 2.12 for the 3.x series. We may be able to move to Zope 2.11, which *may* work with Python 2.5, but this is not clear.
Hi Martijn, I do think that we should care a lot about the Plone user base. Right now it is by far the largest sub-community we have. Let me give you an example, where I think that dropping Python 2.4 support in general will actually massively increase the compatibility burden elsewhere. Plone is using z3c.form. We are currently in the process of releasing z3c.form 2.0, which has a massive amount of new features, which are very useful. As a z3c.form developer I want to stay compatible with the current Plone release, because (a) the code gets tested in a very different environment, and (b) it probably represents my largest user base. By dropping Python 2.4 support for the Toolkit, I now have stay compatible with 2 or 3 versions of the KGS (Zope 3.3?, Zope 3.4, Zope Toolkit 1.0) and 2 or 3 Python versions (2.4, 2.5, 2.6?). This is a major burden. The problem is that I have this burden for every package that I care about to be usable in Plone. As a corollary, I Think it is important that a Plone developer is on the Toolkit Steering committee. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter wrote:
Plone is using z3c.form. We are currently in the process of releasing z3c.form 2.0, which has a massive amount of new features, which are very useful. As a z3c.form developer I want to stay compatible with the current Plone release, because (a) the code gets tested in a very different environment, and (b) it probably represents my largest user base. By dropping Python 2.4 support for the Toolkit, I now have stay compatible with 2 or 3 versions of the KGS (Zope 3.3?, Zope 3.4, Zope Toolkit 1.0) and 2 or 3 Python versions (2.4, 2.5, 2.6?). This is a major burden. The problem is that I have this burden for every package that I care about to be usable in Plone.
As a side note, we just started the community discussion about moving at least to Zope 2.11 / 3.4 for Plone in a release by the end of this year. This should take away some of the burden with Zope 3.3, but will not change the Python 2.4 situation.
As a corollary, I Think it is important that a Plone developer is on the Toolkit Steering committee.
I offered my help to Martijn in the beginning if he'd had trouble to get an odd numbered group together. I might have disqualified myself with recent "don't care" opinions on this list however ;) Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
Stephan Richter wrote:
Plone is using z3c.form. We are currently in the process of releasing z3c.form 2.0, which has a massive amount of new features, which are very useful. As a z3c.form developer I want to stay compatible with the current Plone release, because (a) the code gets tested in a very different environment, and (b) it probably represents my largest user base. By dropping Python 2.4 support for the Toolkit, I now have stay compatible with 2 or 3 versions of the KGS (Zope 3.3?, Zope 3.4, Zope Toolkit 1.0) and 2 or 3 Python versions (2.4, 2.5, 2.6?). This is a major burden. The problem is that I have this burden for every package that I care about to be usable in Plone.
As a side note, we just started the community discussion about moving at least to Zope 2.11 / 3.4 for Plone in a release by the end of this year. This should take away some of the burden with Zope 3.3, but will not change the Python 2.4 situation.
Why don't you plan to leapfrog 2.11 and go straight to 2.12 (which I thought you were planning to do anyway)? That gets you onto a "supported" version of Python (2.4 is in lockdown), and makes the ZTK relevant to you. Plone's policies are in conflict, here: - - Ultra-stable about the Zope version: you claim you can't update the version of Zope used in a 3.x release from the version used in 3.0. - - Completely unsupported use of "cherry-picked" updates to the packages which shipped with that Zope. If you can reasonably do the QA to ensure that the second policy doesn't break Plone, the you can equally well update the Zope / Python versions. 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 iD8DBQFKAI5R+gerLs4ltQ4RAmKeAKCFZjDVV5QH6x9jhBXa2/NlJp95CwCbBgv4 HTJV9w01p7GES62e/mTschs= =ivKo -----END PGP SIGNATURE-----
Tres Seaver wrote:
Hanno Schlichting wrote:
As a side note, we just started the community discussion about moving at least to Zope 2.11 / 3.4 for Plone in a release by the end of this year. This should take away some of the burden with Zope 3.3, but will not change the Python 2.4 situation.
Why don't you plan to leapfrog 2.11 and go straight to 2.12 (which I thought you were planning to do anyway)? That gets you onto a "supported" version of Python (2.4 is in lockdown), and makes the ZTK relevant to you.
Zope 2.12 with its many changes is seen as too risky to introduce into our current stable series or into any release that aims to be released as final by the end of this year.
Plone's policies are in conflict, here:
- Ultra-stable about the Zope version: you claim you can't update the version of Zope used in a 3.x release from the version used in 3.0.
- Completely unsupported use of "cherry-picked" updates to the packages which shipped with that Zope.
The conflict arises from Plone the product and its conservative policy and the desire of a minority of community members aiming for latest and greatest. Plone the product itself never steps out of the tight boundaries of the Zope release. But whoever wants to innovate on top of Plone using Zope or Z3C technologies often does. The innovators are who speak up here and try to keep it possible for them to work. But the vast majority of Plone users has no interest in these and prefers the ultra-stable policy of the product. Plone has that conflict of developer and end-user interest in many situations - this is just another example of it. Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
Tres Seaver wrote:
Hanno Schlichting wrote:
As a side note, we just started the community discussion about moving at least to Zope 2.11 / 3.4 for Plone in a release by the end of this year. This should take away some of the burden with Zope 3.3, but will not change the Python 2.4 situation. Why don't you plan to leapfrog 2.11 and go straight to 2.12 (which I thought you were planning to do anyway)? That gets you onto a "supported" version of Python (2.4 is in lockdown), and makes the ZTK relevant to you.
Zope 2.12 with its many changes is seen as too risky to introduce into our current stable series or into any release that aims to be released as final by the end of this year.
For what value of "risky"? If you are that risk-averse, then the entire ZTK is beyond the event horizon and into the black hole of risk for you.
Plone's policies are in conflict, here:
- Ultra-stable about the Zope version: you claim you can't update the version of Zope used in a 3.x release from the version used in 3.0.
- Completely unsupported use of "cherry-picked" updates to the packages which shipped with that Zope.
The conflict arises from Plone the product and its conservative policy and the desire of a minority of community members aiming for latest and greatest. Plone the product itself never steps out of the tight boundaries of the Zope release. But whoever wants to innovate on top of Plone using Zope or Z3C technologies often does.
The innovators are who speak up here and try to keep it possible for them to work. But the vast majority of Plone users has no interest in these and prefers the ultra-stable policy of the product. Plone has that conflict of developer and end-user interest in many situations - this is just another example of it.
If Plone 3.x doesn't cherry pick anything which replaces packages shipped with Zope 2.10, then the folks who are arguing that we should retain BBB cruft / Python 2.4 compatibility are not speaking for the broader Plone community, but only for their own individual applications running on top of it. At that point, there is no guarantee that we can even identify the set of packages which need this compatibility, because every Plone-based buildout.cfg in the world will have a different (possibly empty) set of cherries. 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 iD8DBQFKAJkg+gerLs4ltQ4RAh57AKDK+V3t2q5zzeu/MTD/zlb9g4YfiwCghxSS Sna30wzjHnqp6gYe7f2jajc= =UfkU -----END PGP SIGNATURE-----
Tres Seaver wrote:
Hanno Schlichting wrote:
Tres Seaver wrote: Zope 2.12 with its many changes is seen as too risky to introduce into our current stable series or into any release that aims to be released as final by the end of this year.
For what value of "risky"? If you are that risk-averse, then the entire ZTK is beyond the event horizon and into the black hole of risk for you.
We are using the ZTK / 2.12 for Plone trunk to be released sometime next year. But we need to balance of the risk that change introduces with some actual big value for our end-users. That takes a bit of time and is currently in the making.
If Plone 3.x doesn't cherry pick anything which replaces packages shipped with Zope 2.10, then the folks who are arguing that we should retain BBB cruft / Python 2.4 compatibility are not speaking for the broader Plone community, but only for their own individual applications running on top of it. At that point, there is no guarantee that we can even identify the set of packages which need this compatibility, because every Plone-based buildout.cfg in the world will have a different (possibly empty) set of cherries.
So far nobody tried to identify particular packages that should be kept more compatible but argued against the general application of the Python 2.4 is unsupported rule. Personally I don't care if the ZTK doesn't officially support Python 2.4 anymore, as long as nobody will try to actively remove Python 2.4 support. For my part I'd be happy to take care of the BBB support for those packages I use. Hanno
Hanno Schlichting wrote:
Personally I don't care if the ZTK doesn't officially support Python 2.4 anymore, as long as nobody will try to actively remove Python 2.4 support. For my part I'd be happy to take care of the BBB support for those packages I use.
I think this would be acceptable as well, *if* supporting Python 2.4 in ZTK became more of a burden than an inconvenience. We can run the tests before a release. We don't need every developer to do everything in triplicate just because we support different versions. And of course, those who are interested in Python 2.4 compatibility should cough up and contribute to make that work. And as I've said all along: if some package really want or need to use things that are part of 2.5 but not 2.4, then that's a good argument *for* breaking compatibility in those cases. I just have a problem with putting the "burden of proof" on those who argue for not breaking with the platforms we currently support. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote:
Hanno Schlichting wrote:
Personally I don't care if the ZTK doesn't officially support Python 2.4 anymore, as long as nobody will try to actively remove Python 2.4 support. For my part I'd be happy to take care of the BBB support for those packages I use.
I think this would be acceptable as well, *if* supporting Python 2.4 in ZTK became more of a burden than an inconvenience.
We can run the tests before a release. We don't need every developer to do everything in triplicate just because we support different versions. And of course, those who are interested in Python 2.4 compatibility should cough up and contribute to make that work.
And as I've said all along: if some package really want or need to use things that are part of 2.5 but not 2.4, then that's a good argument *for* breaking compatibility in those cases. I just have a problem with putting the "burden of proof" on those who argue for not breaking with the platforms we currently support.
The "burden of proof" *is* the work you just signed up the "preserve 2.4" group for: monitoring the packages they care about for things which break under 2.4, and proposing 2.4-compatible fixes. If that group doesn't self-organize, then 2.4 compatibility is literally moot, because the core developers are never going to know that they have broken something under 2.4. Note as well that the mere presence of certain kinds of BBB code is a burden on the core maintainers. Conditional imports, for instance, create untestable code paths, as do other kinds of "capability" checks. Removing that kind of cruft increases the quality of the codebase, at the expense of backward compatibility. Note as well that users who cannot upgrade Python (or Zope) ought not to feel obliged to upgrade the underlying bits, either: stability requires non-trivial tradeoffs. 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 iD8DBQFKAcu++gerLs4ltQ4RAqzeAJ9B/xUTiV9f8aUsm/Jita+tmOpkLgCgsLaU Az5NP5WvMeouVW69sS9Uj6M= =2oSJ -----END PGP SIGNATURE-----
Tres Seaver wrote:
The "burden of proof" *is* the work you just signed up the "preserve 2.4" group for: monitoring the packages they care about for things which break under 2.4, and proposing 2.4-compatible fixes.
Sure. That's different to saying officially that ZTK does not support Python 2.4, though, which is where we were going before.
Note as well that the mere presence of certain kinds of BBB code is a burden on the core maintainers. Conditional imports, for instance, create untestable code paths, as do other kinds of "capability" checks. Removing that kind of cruft increases the quality of the codebase, at the expense of backward compatibility.
Agree. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Hey, Stephan Richter wrote: [snip]
I do think that we should care a lot about the Plone user base. Right now it is by far the largest sub-community we have.
I care about the Plone user base, but would you really have said: "okay, we should not move to Python 2.5 for Zope 3.5, because people on Plone which is still based on Zope 3.3 may want to use bits from Zope 3.5?" I don't think you would have. I seriously think that people who think they can just drop in Zope Toolkit components into an existing Plone release might not see the true difficulties involved. If this is the only argument to stay compatible with Python 2.4, then it is a bad one. You give another argument, which is a better one:
Let me give you an example, where I think that dropping Python 2.4 support in general will actually massively increase the compatibility burden elsewhere.
Plone is using z3c.form. We are currently in the process of releasing z3c.form 2.0, which has a massive amount of new features, which are very useful. As a z3c.form developer I want to stay compatible with the current Plone release, because (a) the code gets tested in a very different environment, and (b) it probably represents my largest user base.
By dropping Python 2.4 support for the Toolkit, I now have stay compatible with 2 or 3 versions of the KGS (Zope 3.3?, Zope 3.4, Zope Toolkit 1.0) and 2 or 3 Python versions (2.4, 2.5, 2.6?). This is a major burden. The problem is that I have this burden for every package that I care about to be usable in Plone.
This is an argument of wanting to build a single component that stays compatible with rather wide range of versions of the underlying libraries. Perhaps Martin Aspeli was hinting at this earlier. Looking at the z3c.form trunk and it's setup.py, I see it relies on zope.site. This is a component developed in the context of the Zope Toolkit (or at least post-Zope 3.4). It depends on zope.container, also new. We released a backwards compatible zope.app.container (not in the Toolkit) which relies on zope.container now for its implementation. The previous version didn't, so you'll need to use this newer version of zope.app.container too, otherwise you'll end up with two implementations of Container in a single codebase, which seems dangerous. There's also a similar issue with zope.app.component (where some of the functionality moved to zope.site, some to other places). So, mixing zope.app.container old-style with zope.site newstyle is a recipe for trouble, and it's not very obvious trouble. The Plone developers are used to trouble though, so let's continue... Plone 3.2 relies on Zope 2.10.7. This pulls in the full Zope 3.3. Assuming you can override individual Zope 3 packages in this setup (I don't know whether this is possible as it just installs Zope 3.3 as a whole, but I assume you can), you'll have to override *all* of those packages in Zope 3 that are also in the Zope Toolkit, otherwise you'll have trouble. This might work. It might even work by accident if you replace less libraries, but I'd certainly worry quite a bit doing that... But it does mean replacing huge parts of the Zope 3 underneath of a release of Plone just so people can install a new version of z3c.form... And hoping that the zope.app.* packages (not in the toolkit) will continue to work. What I'm trying to point out that using the Zope Toolkit with an existing release of Plone is risky. In general, I don't think we can realistically support existing releases of complicated applications of Plone with new releases of our libraries. Of course we try to stay compatible, but you'd expect those applications to do some testing before they can upgrade to the new versions in a new release. Anyway, if I'm correct, the argument in favor of Python 2.4 support in the Zope Toolkit is as follows: * Plone is still on Python 2.4 and Zope 2.10 * Plone would like to use libraries like z3c.form 2.0 that already are on the Zope Toolkit * in order to do this, Plone developers will tell users of z3c.form-based code on Plone to replace vast amounts of libraries in their Plone install with Zope Toolkit libraries. * the Plone developers will make sure that this works so that the Zope Toolkit developers don't have to worry about it. * the Plone developers are asking not to drop Python 2.4 support in the Zope Toolkit now because they want to do such a thing. The question now is whether this is realistic from the Plone perspective. Have people tried this? Do the z3c.form tests run, and the Plone tests? Have people done this with Zope 3.4 libraries (which have been released for a while)? Or have things just worked based on luck and magic? (since Plone never actually uses a Zope Toolkit container implementation it hasn't been an issue that there are two versions in the same codebase, say) How hypothetical are the scenarios we're talking about here? All too often in the past we've *not* done things because someone somewhere has an argument, possibly quite weak and unrealistic, to hold up the process. I'm all for listening to people's arguments, but in order to make progress we must also be willing to disappoint people sometime. Regards, Martijn
Previously Martijn Faassen wrote:
This is a component developed in the context of the Zope Toolkit (or at least post-Zope 3.4). It depends on zope.container, also new. We released a backwards compatible zope.app.container (not in the Toolkit) which relies on zope.container now for its implementation. The previous version didn't, so you'll need to use this newer version of zope.app.container too, otherwise you'll end up with two implementations of Container in a single codebase, which seems dangerous. There's also a similar issue with zope.app.component (where some of the functionality moved to zope.site, some to other places).
Looking at a project I'm working on I use the following zope packages: zope.sqlalchemy trunk zope.location 3.4.0 zope.component 3.4.0 zope.security 3.5.2 zope.testing 3.7.1 zope.i18n 3.4.0 zope.proxy 3.5.0 zope.intid 3.7.0 zope.app.zcmlfiles 3.5.3 zope.securitypolicy 3.4.0 zope.container 3.8.1 zope.app.publisher 3.5.2 zope.keyreference 3.6.1 zope.broken 3.5.0 zope.browser 0.5.0 This works today in Plone 3.3. It's a bit painful to find a set of versions which work well together with all the current refactoring, but as you can see it is possible, and extremely valuable for us.
But it does mean replacing huge parts of the Zope 3 underneath of a release of Plone just so people can install a new version of z3c.form... And hoping that the zope.app.* packages (not in the toolkit) will continue to work.
What I'm trying to point out that using the Zope Toolkit with an existing release of Plone is risky. In general, I don't think we can realistically support existing releases of complicated applications of Plone with new releases of our libraries. Of course we try to stay compatible, but you'd expect those applications to do some testing before they can upgrade to the new versions in a new release.
Anyway, if I'm correct, the argument in favor of Python 2.4 support in the Zope Toolkit is as follows:
* Plone is still on Python 2.4 and Zope 2.10
* Plone would like to use libraries like z3c.form 2.0 that already are on the Zope Toolkit
* in order to do this, Plone developers will tell users of z3c.form-based code on Plone to replace vast amounts of libraries in their Plone install with Zope Toolkit libraries.
* the Plone developers will make sure that this works so that the Zope Toolkit developers don't have to worry about it.
We do expect some help. If we end up in a situation where people can not use Plone with more recent ZTK goodness, and they can't use ZTK without all the benefits of Plone we will loose them to non-zope systems.
* the Plone developers are asking not to drop Python 2.4 support in the Zope Toolkit now because they want to do such a thing.
The question now is whether this is realistic from the Plone perspective.
To some degree I consider it essential even. At the moment we are in a position were we have to deal with the fact that Plone runs on Zope 2.10 while we want to be able to use ZTK components in order to be productive and have a modern environment. Just like Hanno almost all my Plone projects over the last year have had to do this. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Am Tue, 05 May 2009 16:22:44 +0200 schrieb Martijn Faassen: [...]
I care about the Plone user base, but would you really have said: "okay, we should not move to Python 2.5 for Zope 3.5, because people on Plone which is still based on Zope 3.3 may want to use bits from Zope 3.5?"
Unfortunately Plone is still based on Zope 2.10. We may have a release based on Zope 2.11 at end of year or maybe earlier. But the power of extending and using newer version of some libraries is essential.
I don't think you would have.
I seriously think that people who think they can just drop in Zope Toolkit components into an existing Plone release might not see the true difficulties involved. If this is the only argument to stay compatible with Python 2.4, then it is a bad one.
I feel the difficulties in my every days work. I love to work with ZTK i.e for AGX (no web context at all) or our recent preparing works for Devilstick (data centric model-runtime) or together with repoze.bfg (integration web-app work). Then back in CMS Plone-business reality strikes back, using Zope 3.4 (or 3.5dev KGS) or ZTK is introduces headaches. I use the newer techs because they simplify a bunch of things. Also I can reuse my packages and dont need to reinvent everything everyday. [...]
Anyway, if I'm correct, the argument in favor of Python 2.4 support in the Zope Toolkit is as follows:
* Plone is still on Python 2.4 and Zope 2.10
reality sucks. but stabilty is essential.
* Plone would like to use libraries like z3c.form 2.0 that already are on the Zope Toolkit
yes
* in order to do this, Plone developers will tell users of z3c.form-based code on Plone to replace vast amounts of libraries in their Plone install with Zope Toolkit libraries.
or zope 3.4 libs as we were used to in past.
* the Plone developers will make sure that this works so that the Zope Toolkit developers don't have to worry about it.
well, Zope3/ZTK code is usally good and tested code. most of the time (except something like Five steps in ;) ) it works.
* the Plone developers are asking not to drop Python 2.4 support in the Zope Toolkit now because they want to do such a thing.
+1
The question now is whether this is realistic from the Plone perspective. Have people tried this? Do the z3c.form tests run, and the Plone tests? Have people done this with Zope 3.4 libraries (which have been released for a while)? Or have things just worked based on luck and magic? (since Plone never actually uses a Zope Toolkit container implementation it hasn't been an issue that there are two versions in the same codebase, say)
z3c.form is one example. Yes we tried this, yes Zope 3.4 libs are working in most cases. Yes it was luck, and became magic if Five was involved. And no, I dont tried to make it work with ZTK except for some very core and low-dependecy packages.
How hypothetical are the scenarios we're talking about here?
Since we have buildout and version pinning we used newer libraries from zope 3.4. This is for about 2 years. Nothing hypothetical. Those scenarios are reality.
All too often in the past we've *not* done things because someone somewhere has an argument, possibly quite weak and unrealistic, to hold up the process. I'm all for listening to people's arguments, but in order to make progress we must also be willing to disappoint people
I like how you push ZTK forward. Its great work. But at some point you have to give other slower species the chance to move with you. So possibly the point is reached to settle down a bit again. Give ZTK the chance to be used by a broad community. just my 0.02 Eur Jens -- Jens W. Klein - Klein & Partner KEG - BlueDynamics Alliance
On Tue, May 5, 2009 at 15:30, Stephan Richter <srichter@cosmos.phy.tufts.edu> wrote:
[...] I think that dropping Python 2.4 support in general will actually massively increase the compatibility burden elsewhere.
That would indeed be bad, and in practice remove the benefit of dropping 2.4 support.
Plone is using z3c.form. We are currently in the process of releasing z3c.form 2.0, which has a massive amount of new features, which are very useful. As a z3c.form developer I want to stay compatible with the current Plone release, because (a) the code gets tested in a very different environment, and (b) it probably represents my largest user base. By dropping Python 2.4 support for the Toolkit, I now have stay compatible with 2 or 3 versions of the KGS (Zope 3.3?, Zope 3.4, Zope Toolkit 1.0) and 2 or 3 Python versions (2.4, 2.5, 2.6?).
But.... don't you have to be compatible with these anyway? With ZTK 1.0 supporting 2.4 z3c.form needs to support: Zope 3.3 on Python 2.4. Zope 3.4 on Python 2.4 and 2.5 ZTK 1.0 on Python 2.4, 2.5 and 2.6 If ZTK drops 2.4 support, you need to be compatible with: Zope 3.3 on Python 2.4 (For Plone 3 support) Zope 3.4 on Python 2.4 and 2.5 (For Grok support) ZTK 1.0 on Python 2.5 and 2.6 (For bleeding edge support) That doesn't sound like a *bigger* burden. It sounds like a *smaller* burden. Not *much* smaller, but still. :) Or did I misunderstand something? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Martin Aspeli wrote:
Martijn Faassen wrote:
Martijn Faassen wrote:
In order to get to a conclusion:
I haven't seen convincing arguments yet *not* to drop the Python 2.4 for new releases of the Zope Toolkit libraries.
I'd like to phrase the debate in those terms instead of the reverse, because ensuring Python 2.4 compatibility is an additional burden for developers and we need good arguments for *not* dropping this burden. Since I haven't seen such arguments besides the Plone 3.x related ones, I will amend the zope toolkit decisions about this.
We've had some more discussions about this and the Plone release schedule. The upshot is that if Zope 3/Toolkit drops Python 2.4 support, it will effectively render it inaccessible to Plone users for the next 12-18 months.
As I pointed out, it is effectively inaccessible for Plone users anyway, as Zope 3 is already installed. You *cannot* mix Zope Toolkit and Zope 3 libraries just like that and expect anything to work.
I agree that some of the refactored ZTK components don't make sense if they're bundled with Zope 2.10 in pre-refactored form.
Yup, they won't.
However, the idea is surely also to support new and more focused components in the toolkit.
There are no such new and more focused components even on the drawing board yet. I highly doubt that the first release of the Zope Toolkit will contain such components.
We're not comfortable moving to Zope 2.12 for the 3.x series. We may be able to move to Zope 2.11, which *may* work with Python 2.5, but this is not clear.
That makes the potential user base for new-and-dependency-isolated Zope components quite a bit smaller.
I don't believe in this Plone (for *existing Plone releases*) user base anyway, so I don't think it's getting smaller. If we'd have released a Zope 3.5 that didn't have Python 2.4 support, would you have complained that you cannot use Zope 3.5 with an existing Plone release? This is the same as trying to use Zope 3.4 and Zope 3.3 components together (though the changes from Zope 3.4 to the Toolkit are *bigger* as we move things around). It *might* just work in some cases, but it's unlikely it will.
At the end of the day, it may not make much of a difference. However, I am still puzzled as to why we you are trying to base a decision on arguments *against* breaking compatibility. The main argument *for* dropping compatibility seems to be a hand-wave towards an added maintenance burden. Is that really so? Are we struggling to release components that work across Python versions?
Sorry, I won't let you turn this back around again. :) Arguments for increased maintenance burden will need to be realistic. I will note that Grok 1.0 won't work with the Zope Toolkit either; we're sticking with Zope 3.4. Only after 1.0 will we go over to the toolkit.
If there are Python 2.5 features we really want to use, then I understand. Otherwise, I think as a general principle it makes sense to always aim for the widest amount of compatibility possible, at least when it comes to the core Zope Toolkit, which, by its very nature, aims to underpin a number of heterogeneous platforms with different constraints. I'd rather hope Plone was considered one of those platforms. ;)
It is, but again, it's just wishful thinking that the toolkit libraries as they are released today will work in combination with a existing release of Plone. Regards, Martijn
Martijn Faassen wrote:
As I pointed out, it is effectively inaccessible for Plone users anyway, as Zope 3 is already installed. You *cannot* mix Zope Toolkit and Zope 3 libraries just like that and expect anything to work.
Why not? We upgrade Zope 3.3 packages to 3.4+ all the time to access bug fixes or new features. It's rarely completely painful, but once you've got an understanding of what versions work and don't work together, you do have the option of selectively upgrading parts of the zope.* namespace. Also, I'm expecting there to be completely new packages that are not a like-for-like replacement of the Zope 3.3 set. Whether these would work is of course a case-by-case evaluation. But let's not make it a no by default, unless there's a good reason.
There are no such new and more focused components even on the drawing board yet. I highly doubt that the first release of the Zope Toolkit will contain such components.
What about packages that build on the ZTK? Stephan just gave a great example with z3c.form. Surely, that's the kind of innovation and code sharing we want to encourage.
We're not comfortable moving to Zope 2.12 for the 3.x series. We may be able to move to Zope 2.11, which *may* work with Python 2.5, but this is not clear.
That makes the potential user base for new-and-dependency-isolated Zope components quite a bit smaller.
I don't believe in this Plone (for *existing Plone releases*) user base anyway, so I don't think it's getting smaller.
I think you're wrong about that. For example, the known-good-set of packages required to get Dexterity 1.0a1 to install on Plone 3.3 will look something like this: http://good-py.appspot.com/release/dexterity/1.0a1?plone=3.3rc2 Most of the zope.* upgrades there are caused by a z3c.form dependency, plus z3c.relationfield.
If we'd have released a Zope 3.5 that didn't have Python 2.4 support, would you have complained that you cannot use Zope 3.5 with an existing Plone release?
Yes.
This is the same as trying to use Zope 3.4 and Zope 3.3 components together (though the changes from Zope 3.4 to the Toolkit are *bigger* as we move things around). It *might* just work in some cases, but it's unlikely it will.
It does. ;) And Plone is likely to see Zope 2.11 (which uses Zope 3.4) before 2.12. As far as I know, Zope 2.11 is still supported only on Python 2.4, but being based on Zope 3.4, we are much closer to ZTK as a starting point. Typically, there'll be three reasons to upgrade packages: - either, we depend on a bug fix (quite common, e.g. with zope.i18n) - or, we depend on a package that depends on a newer version of a core package that's backwards compatible (c.f. z3c.form) - or, we need a new feature (less common, in practice)
Sorry, I won't let you turn this back around again. :) Arguments for increased maintenance burden will need to be realistic.
What is the increased burden? I mean, are we feeling this pain today? Do we have evidence that we'll be feeling it going forward? I'm not saying your argument is invalid - instinctively, it makes a lot of sense. But it feels like we're taking that argument for granted with little actual evidence and justification, and ignoring the counter-argument as invalid, which makes this conversation a bit difficult to have.
I will note that Grok 1.0 won't work with the Zope Toolkit either; we're sticking with Zope 3.4. Only after 1.0 will we go over to the toolkit.
Right. And Plone won't ship with ZTK by default for a while yet, I reckon, but we want people to be able to use the new code and experiment with it early and often.
It is, but again, it's just wishful thinking that the toolkit libraries as they are released today will work in combination with a existing release of Plone.
I hope that's not true. It'd probably be true if ZTK packages have no regards for BBB with older versions of the library. If that's the case, you really should rename the packages in question, though. I once recall Jim saying "the more I think about it, the more I think we can just never break backwards compatibility". That's the way it works in many other platforms, e.g. Java and .NET. And Python, maybe. Why do we have a urllib2? :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote:
Martijn Faassen wrote:
As I pointed out, it is effectively inaccessible for Plone users anyway, as Zope 3 is already installed. You *cannot* mix Zope Toolkit and Zope 3 libraries just like that and expect anything to work.
Why not? We upgrade Zope 3.3 packages to 3.4+ all the time to access bug fixes or new features. It's rarely completely painful, but once you've got an understanding of what versions work and don't work together, you do have the option of selectively upgrading parts of the zope.* namespace.
The reason why it is a lot more subtle after Zope 3.4 is because we've moved stuff around between packages a lot. Things might, of course, work but I'd certainly not feel very safe doing this. z3c.form relies on zope.site If you install z3c.form, you'll get zope.site, which wasn't in Zope 3.3 yet. zope.site relies on zope.container. You'll get that too, and it wasn't in Zope 3.3. So you are running happily and think everything works. But wait. zope.app.container *is* in Zope 3.3. It has an implementation of Container. The *new* zope.app.container however doesn't have this implementation, and instead imports (for backwards compatibility) from zope.container. But wait. zope.app.component *is* in Zope 3.3. It has an implementation of some stuff that's in zope.site now. The *new* zope.app.component however doesn't have this implementation, and instead imports (for backwards compatibility) from zope.container. So zope.site doesn't depend on zope.app.component nor on zope.app.container. But installing zope.site does affect the integrity of your codebase. There are suddenly multiple duplicate implementations around. Now if some code does this:
from zope.container import Container
and some other code does this:
from zope.app.container.container import Container as OldContainer
then surprisingly enough we'll get this:
Container is OldContainer False
unless people also installed a newer version of zope.app.container. This can get tremendously confusing and tests can break for rather subtle reasons. And this is just the case I'm familiar with. There are probably a lot more issues like this that I don't know about. So I see two responses for Plone developers: * they know that they need new versions of zope.app.container and zope.app.component too and require people to upgrade those too. This might work fairly well, but does require the upgrade of more than just a *few* packages, with the increased risk of breakage. * they try to ignore this issue (because they don't know or care) and things may continue to work. Perhaps nobody ever uses Container in Plone anyway, and in practice everything's just fine. Based on a lot of luck. Regards, Martijn
Martijn Faassen wrote:
So I see two responses for Plone developers:
* they know that they need new versions of zope.app.container and zope.app.component too and require people to upgrade those too. This might work fairly well, but does require the upgrade of more than just a *few* packages, with the increased risk of breakage.
Or we can manage this with known good sets and careful testing.
* they try to ignore this issue (because they don't know or care) and things may continue to work. Perhaps nobody ever uses Container in Plone anyway, and in practice everything's just fine. Based on a lot of luck.
It's never going to be pretty, but it may be necessary given that the innovation that's going to happen "further down the stack" seems to move in an backwards-incompatible (or compatibility-challenge) direction. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Am Tue, 05 May 2009 15:45:31 +0200 schrieb Martijn Faassen: [...]
As I pointed out, it is effectively inaccessible for Plone users anyway, as Zope 3 is already installed. You *cannot* mix Zope Toolkit and Zope 3 libraries just like that and expect anything to work.
I dont expect them to work. I try an test. And if it works, why not? Its not that painful. [...]
I don't believe in this Plone (for *existing Plone releases*) user base anyway, so I don't think it's getting smaller.
Oh, I dont believe in much, but I know a good bunch of active developers and interators using Plone this way.
If we'd have released a Zope 3.5 that didn't have Python 2.4 support, would you have complained that you cannot use Zope 3.5 with an existing Plone release?
If I'd have read the dicussion at the right time: yes.
This is the same as trying to use Zope 3.4 and Zope 3.3 components together (though the changes from Zope 3.4 to the Toolkit are *bigger* as we move things around). It *might* just work in some cases, but it's unlikely it will.
Using Zope 3.4 within Zope 3.3 (like Zope 2.10) works almost fine.
I will note that Grok 1.0 won't work with the Zope Toolkit either; we're sticking with Zope 3.4. Only after 1.0 will we go over to the toolkit.
Well, Grok is not as complex as Plone is. Also it has a smaller user-base.
It is, but again, it's just wishful thinking that the toolkit libraries as they are released today will work in combination with a existing release of Plone.
As a whole: No. Little parts: Yes. And yes, I wish it would be much simpler to use ZTK-bits in Plone. regards Jens -- Jens W. Klein - Klein & Partner KEG - BlueDynamics Alliance
Hey, Martijn Faassen wrote:
Martijn Faassen wrote:
In order to get to a conclusion:
I haven't seen convincing arguments yet *not* to drop the Python 2.4 for new releases of the Zope Toolkit libraries.
I'd like to phrase the debate in those terms instead of the reverse, because ensuring Python 2.4 compatibility is an additional burden for developers and we need good arguments for *not* dropping this burden.
Since I haven't seen such arguments besides the Plone 3.x related ones, I will amend the zope toolkit decisions about this.
A few more arguments popped up since then, as I half expected, so I'll remove that decision and re-open the discussion for a while. I don't want to upset a whole lot of Plone folks. I'll ask a different question to the Plone people. What is the date that you would feel comfortable about giving up Python 2.5 compatibility in Zope Toolkit packages? I'm not leaving this thread without at least *some* decision about this. :) Regards, Martijn
Martijn Faassen wrote:
What is the date that you would feel comfortable about giving up Python 2.5 compatibility in Zope Toolkit packages? I'm not leaving this thread without at least *some* decision about this. :)
Oops, I meant of course giving up Python 2.4 compatibility. Giving up Python 2.5 compatibility is a bit further away. Regards, Martijn
Martijn Faassen wrote:
Martijn Faassen wrote:
What is the date that you would feel comfortable about giving up Python 2.5 compatibility in Zope Toolkit packages? I'm not leaving this thread without at least *some* decision about this. :)
Oops, I meant of course giving up Python 2.4 compatibility. Giving up Python 2.5 compatibility is a bit further away.
Given the Zope2 supported Python release situation, giving up Python 2.4 and 2.5 is practically the same matter for us. It looks like we will have a Plone release by the end of the year that will be based on Zope 2.11. Sometime in the next year we will get a Plone release that is based on Zope 2.12 and will require Python 2.6 (that's indeed an additional requirement Plone makes over Zope 2.12). Given those dates the most commonly used Plone version will be based on Python 2.4 up until end of next year by the looks of it. Hanno
Hey, Hanno Schlichting wrote: [snip]
Given those dates the most commonly used Plone version will be based on Python 2.4 up until end of next year by the looks of it.
What about implementing the dropping of Python 2.4 compatibility in september, then? To give you guys a bit more time? Regards, Martijn
On 5/5/09 11:16 AM, Martijn Faassen wrote:
Hey,
Hanno Schlichting wrote: [snip]
Given those dates the most commonly used Plone version will be based on Python 2.4 up until end of next year by the looks of it.
What about implementing the dropping of Python 2.4 compatibility in september, then? To give you guys a bit more time?
Were this some other project, I'd ask the Plone folks or some other group that cares about Zope packages under 2.4 to set up a buildbot that tested "the ZTK" under Python 2.4. Then I'd ask the same folks to to pay attention to the buildbot output and fix issues exposed by the buildbot over time. Then, as a community, decree that all packages in the ZTK should be kept 2.4 compatible until such time as the decree is lifted, but don't make each developer test using Python 2.4 by hand. Instead, leave that job to the buildbot and let it catch errors. Personally, as long as I know some code breaks under 2.4 because someone put some 2.5-ism in it, I usually find it pretty easy to fix. Once the decree is lifted, 2.4-ifying code becomes a negotiation between the committer and the folks who want that bit of code to still be 2.4-compatible. There doesn't need to be a "d-day" where everything becomes 2.4-incompatible. - C
Hey, Chris McDonough wrote:
On 5/5/09 11:16 AM, Martijn Faassen wrote:
Hanno Schlichting wrote: [snip]
Given those dates the most commonly used Plone version will be based on Python 2.4 up until end of next year by the looks of it. What about implementing the dropping of Python 2.4 compatibility in september, then? To give you guys a bit more time?
Were this some other project, I'd ask the Plone folks or some other group that cares about Zope packages under 2.4 to set up a buildbot that tested "the ZTK" under Python 2.4. Then I'd ask the same folks to to pay attention to the buildbot output and fix issues exposed by the buildbot over time.
I'm all for people setting up a buildbots. And people do sometimes set up buildbots. But I think we forget to actually document where the buildbot is, what it is doing, and who to contact about it. People sometimes ask *me* about buildbots when I bring up the topics as if I somehow know how they work and what to do with them. So I keep trying to delegate it to someone who can make sure that: * there's a buildbot * that someone's listening to this mailing list and reminds people about the buildbot and tells people what the buildbot can and cannot do * that someone extends the Zope Toolkit documentation telling people about the buildbot, where to find it, how to use it, etc. Doesn't have to be much, just a page. I should probably make this clearer. Not rely on my memory of who all were talking about a buildbot and having to dig through a mailbox to find the URL to one. Regards, Martijn
On Tue, May 5, 2009 at 23:51, Martijn Faassen <faassen@startifact.com> wrote:
Were this some other project, I'd ask the Plone folks or some other group that cares about Zope packages under 2.4 to set up a buildbot that tested "the ZTK" under Python 2.4. Then I'd ask the same folks to to pay attention to the buildbot output and fix issues exposed by the buildbot over time.
I'm all for people setting up a buildbots. And people do sometimes set up buildbots. But I think we forget to actually document where the buildbot is, what it is doing, and who to contact about it. People sometimes ask *me* about buildbots when I bring up the topics as if I somehow know how they work and what to do with them. So I keep trying to delegate it to someone who can make sure that:
* there's a buildbot
http://zope.buildbot.securactive.org/ http://grok.buildbot.securactive.org/ (missing repoze and zc.builout) regards -- Sebastien Douche <sdouche@gmail.com>
Hey, Sebastien Douche wrote: [snip]
* there's a buildbot
http://zope.buildbot.securactive.org/ http://grok.buildbot.securactive.org/ (missing repoze and zc.builout)
Thanks. Could you add a page to the zopetoolkit documentation about this please? Otherwise again I will look through the email archives to remember. If you want to, please add yourself as a point of contact. :) Regards, Martijn
Chris McDonough wrote:
Were this some other project, I'd ask the Plone folks or some other group that cares about Zope packages under 2.4 to set up a buildbot that tested "the ZTK" under Python 2.4. Then I'd ask the same folks to to pay attention to the buildbot output and fix issues exposed by the buildbot over time.
Then, as a community, decree that all packages in the ZTK should be kept 2.4 compatible until such time as the decree is lifted, but don't make each developer test using Python 2.4 by hand. Instead, leave that job to the buildbot and let it catch errors. Personally, as long as I know some code breaks under 2.4 because someone put some 2.5-ism in it, I usually find it pretty easy to fix.
Once the decree is lifted, 2.4-ifying code becomes a negotiation between the committer and the folks who want that bit of code to still be 2.4-compatible. There doesn't need to be a "d-day" where everything becomes 2.4-incompatible.
I'd be happy with that kind of policy. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Hey, Martin Aspeli wrote:
I'd be happy with that kind of policy.
Maybe you can help Sebastien Douche document the existing infrastructure in the zopetoolkit website. It just has to be a page with a few paragraphs so we won't keep *forgetting* that this exists and people can find out about without reading everything on this list... Regards, Martijn
On Tuesday 05 May 2009, Chris McDonough wrote:
Were this some other project, I'd ask the Plone folks or some other group that cares about Zope packages under 2.4 to set up a buildbot that tested "the ZTK" under Python 2.4. Then I'd ask the same folks to to pay attention to the buildbot output and fix issues exposed by the buildbot over time.
Then, as a community, decree that all packages in the ZTK should be kept 2.4 compatible until such time as the decree is lifted, but don't make each developer test using Python 2.4 by hand. Instead, leave that job to the buildbot and let it catch errors. Personally, as long as I know some code breaks under 2.4 because someone put some 2.5-ism in it, I usually find it pretty easy to fix.
Once the decree is lifted, 2.4-ifying code becomes a negotiation between the committer and the folks who want that bit of code to still be 2.4-compatible. There doesn't need to be a "d-day" where everything becomes 2.4-incompatible.
I think this is a totally fair requirement. I do not test with Py 2.4 anymore either and rely on buildbots and people to tell me about incompatibilities. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Am Dienstag 05 Mai 2009 16:46:03 schrieb Martijn Faassen:
Hey,
Martijn Faassen wrote:
Martijn Faassen wrote:
In order to get to a conclusion:
I haven't seen convincing arguments yet *not* to drop the Python 2.4 for new releases of the Zope Toolkit libraries.
I'd like to phrase the debate in those terms instead of the reverse, because ensuring Python 2.4 compatibility is an additional burden for developers and we need good arguments for *not* dropping this burden.
Since I haven't seen such arguments besides the Plone 3.x related ones, I will amend the zope toolkit decisions about this.
A few more arguments popped up since then, as I half expected, so I'll remove that decision and re-open the discussion for a while. I don't want to upset a whole lot of Plone folks.
Hmmm, maybe I'll come up with my suggestion publicly: If I understood the problem right, one main reason for dropping Python 2.4 is some error in .tar.gz compression. I don't know anything about it, but I estimate that such a bug may be relatively easy to fix in the Python 2.4 source code itself? If yes, perhaps there's a way to have the Python people release a Python 2.4.6 release? Perhaps this may be a lot better solution than endless arguing, speculating and eventually breaking other peoples code? I personally still somehow miss strong arguments for dropping Python 2.4 (except for the above bug). Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Tue, May 5, 2009 at 1:03 PM, Hermann Himmelbauer <dusty@qwer.tk> wrote:
Am Dienstag 05 Mai 2009 16:46:03 schrieb Martijn Faassen:
Hey,
Martijn Faassen wrote:
Martijn Faassen wrote:
In order to get to a conclusion:
I haven't seen convincing arguments yet *not* to drop the Python 2.4 for new releases of the Zope Toolkit libraries.
I'd like to phrase the debate in those terms instead of the reverse, because ensuring Python 2.4 compatibility is an additional burden for developers and we need good arguments for *not* dropping this burden.
Since I haven't seen such arguments besides the Plone 3.x related ones, I will amend the zope toolkit decisions about this.
A few more arguments popped up since then, as I half expected, so I'll remove that decision and re-open the discussion for a while. I don't want to upset a whole lot of Plone folks.
Hmmm, maybe I'll come up with my suggestion publicly:
If I understood the problem right, one main reason for dropping Python 2.4 is some error in .tar.gz compression.
That was the trigger, but not the primary reason.
I personally still somehow miss strong arguments for dropping Python 2.4 (except for the above bug).
The motivators seem to be: - 2.4 is old (it's more than 3.5 years old, people want to use new features) - no further bug fix releases will be made for it (the fact that a major bug was introduced in 2.4.5 with no hope of it ever being fixed) - including 2.4 we have to support 3 major versions Python Most people seem to be moving to 2.5 or 2.6 and we (the community) don't have a good infrastructure to support 2.4, 2.5, and 2.6 on each of the platforms we want. -- Benji York Senior Software Engineer Zope Corporation
participants (14)
-
Andreas Jung -
Benji York -
Chris McDonough -
Ethan Jucovy -
Hanno Schlichting -
Hermann Himmelbauer -
Jens W. Klein -
Lennart Regebro -
Martijn Faassen -
Martin Aspeli -
Sebastien Douche -
Stephan Richter -
Tres Seaver -
Wichert Akkerman