Re: [Zope3-dev] Re: Eggs for deprecated packages
I think we need to have a much more basic discussion. IMO deprecation was a reasonable thing to try that hasn't really worked out well. People find deperecation warnings to be very annoying and I don't think it's going to be practical to make backward-concompatable changes when eggs are used. I suggest that generally, in the future, eggs should not be deprecated but just end- of-lifed. When we are tempted to make a backward cincompatible to a package, we should create a new one. Generally, there is little cost in just leaving old packages around. Unfortunately, there are two poitentially significant costs in keeping obsolete eggs: 1. They may break with newer Python versions. :( 2. The may be in the dependencies of other eggs. If they are used internally, then, of course, the dependent eggs can be rewritten to use newer non-obsolete eggs. In other cases, like zope.app, the dependency exists to provide some feature and can't be removed without introducing a backward-incompatible change to the dependent egg. Honestly, I'm not sure how to deal with these issues, especially the later. Maybe for collection eggs like zope.app, we have to accept deprecation and backward-incompatible changes, at least for a while. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Eggs for deprecated packages
Jim Fulton wrote: I think we need to have a much more basic discussion. IMO deprecation was a reasonable thing to try that hasn't really worked out well. People find deperecation warnings to be very annoying and I don't think it's going to be practical to make backward-concompatable changes when eggs are used. I suggest that generally, in the future, eggs should not be deprecated but just end- of-lifed. When we are tempted to make a backward cincompatible to a package, we should create a new one. Generally, there is little cost in just leaving old packages around. Unfortunately, there are two poitentially significant costs in keeping obsolete eggs: 1. They may break with newer Python versions. :( 2. The may be in the dependencies of other eggs. If they are used internally, then, of course, the dependent eggs can be rewritten to use newer non-obsolete eggs. In other cases, like zope.app, the dependency exists to provide some feature and can't be removed without introducing a backward-incompatible change to the dependent egg. Honestly, I'm not sure how to deal with these issues, especially the later. Maybe for collection eggs like zope.app, we have to accept deprecation and backward-incompatible changes, at least for a while. Are you talking only about whole eggs here, or also about changes to APIs within eggs that are deemed to have a right to exist? Deprecation of APIs within a package works reasonably well as we do it now, imho. If you look at other systems, e.g. the Java APIs, deprecations tend to take place, though often deprecated APIs are never removed (which has the downside that they continue to clutter the namespace and sometimes they could be harmful by design). Deprecation warnings are important here, because it gives people a fighting chance of forward migrating their code. Without warnings, we'll have a lot of people that simply get locked into a version, and find that two or three versions down the line an upgrade would really mean a rewrite. Deprecation of entire eggs (e.g. we don't need it anymore, or we think it needs to move to a different namespace, or we want to break it up into smaller pieces or amalgamate with some other pieces to make a bigger package) is kind of a non-issue as far as eggs are concerned. Eggs are versioned, and people can always depend on specific old eggs even if they're not actively maintained or ship as part of the main Zope 3 distribution. As far as the system is concerned (whatever you want to call the system, but let's say that we mean the collection of eggs that we ship as Zope 3 and promote as a cohesive platform for people to develop on top of) I think we still need some type of deprecation when we decide to stop packaging up particular eggs. Say someone is used to downloading and using the standard Zope 3 distribution (or a particular distribution) - they will assume that all those packages remain there. When they upgrade, they don't want to suddenly find that something's gone missing. That's where I suggest we have a deprecated-in-version-x meta-egg that someone can depend on if they need to get particular packages that no longer exist in the form they used to. It can ship with Zope 3, ship disabled, or not ship but be documented as the way to get back the things that were moved, so that developers can understand the implications of package removals/end-of-life on their own code and have time to take action accordingly. Martin -- View this message in context: http://www.nabble.com/Eggs-for-deprecated-packages-tf3485561.html#a9751811 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Eggs for deprecated packages
Baiju M wrote: There are few deprecated packages in zope.app namespace, should we create individual eggs for those packages ? -1 What about creating a single egg with all deprecated packges ? +1 :) If so, what should be the name of that all-deprecated-in-one package name ? We don't need to decide a *package name* (the package names are clear), we need to decide a name for the *egg*. Often the name of the egg and the name of the package are the same, but when an egg contains several packages, it doesn't have to be. Here is some names: zope.app -1 if that's the only thing the 'zope.app' egg would contain. zope.app.deprecated zope.app.obsolete zope.app.back35 -1 to all. Every one of those names suggest that they contain a package with that name, which they don't. How about ZopeAppBBB35 ? By the way, I've seen that you guys are creating eggs of some stuff that's really meant for spring cleaning (e.g. zope.app.externaleditor, zope.app.css off of the top of my head). Instead of linking the external to the Zope 3 tree, how about actually *moving* this stuff *out* of the Zope 3 tree into their egg? Note that this stuff has never been part of a Zope 3 release anyway. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Eggs for deprecated packages
Jim Fulton wrote: On Mar 29, 2007, at 6:30 AM, Baiju M wrote: Hi, There are few deprecated packages in zope.app namespace, should we create individual eggs for those packages ? Yes. What about creating a single egg with all deprecated packges ? -1. We should be able to create the deprecated eggs once and forget about them. One possible benefit of having all deprecated things grouped somehow (perhaps not necessarily in one egg, what about having a BBB virtual egg that has dependencies on all the deprecated things?) is that it makes it easier for developers to test the effects of deprecation on their code. For example, the standard Zope 3 distribution could come with this egg not installed or not activated. If your code breaks on upgrade, you try to install/activate the deprecated egg, in which case you know you'll need to do something about your code, soonishly. Alternatively, it comes installed but you try to remove it to see if your package will survive the next version upgrade. We do similar things with skins in Plone, having a skin layer called plone_deprecated. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
