Re: [Zope3-dev] Re: [Checkins] SVN: zope.testing/trunk/setup.cfg This file is a recipe for bad releases
On Mar 29, 2007, at 11:26 PM, Baiju M wrote: Jim Fulton wrote: Log message for revision 73922: This file is a recipe for bad releases Changed: D zope.testing/trunk/setup.cfg I am asking for a resolution here, do we want this file in svn for other packages ? No, IMO, and since I am the primary maintainer of zope.testing, my opinion counts here. :) In my experience I found this file is not required. Worse, it's potentially harmful.. If you forget it's there, you could end up releasing something with a version number other than what you expect. The only use case for which it is needed is using easy_install to install an egg directly from subversion. In understand that some people want this, especially for unstable projects. For stable projects, like zope.testing, I think it is more trouble than it's worth. To make a release with svn revision number just get the number from 'svn info' and copy-paste it in setup.py, then 'buildout setup . sdist' Oh, you don't even need to do that. You can get the version # included automatically using the -r option to egg_info, as in: python setup.py egg_info -r sdist Or, to also include dev in the version #: python setup.py egg_info -rb dev sdist I agree with Jim says in the log message. Yes, it's YAGNI ! I wouldn't object if it was just a YAGNI. It's a source of potential mistakes. YOu have to either remember to remove the file before a release or remember a special command-line incantation to defeat it. 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: [ZODB-Dev] Re: [Zope3-dev] Re: Community opinion about search+filter
Dieter Maurer wrote: Jim Washington wrote at 2007-3-27 16:28 -0400: ... Yes, I think so, at least in the implementation/algorithm I am using. There may be other implementations that do not need this. Note, however, that the canonical list does not have to be complex objects. The canonical list is just a representation of the unsorted state. It can, for example, be a proxy list of iids, list indexes, or OOBTree keys. The algorithm does not care what it is reordering. If you need to keep the canonical list around, then sort them and then keep the sorted result around (i.e. cache the sorted list). This way, you could avoid the factoradic index. Yes, if there is only one ordering that will be used. Factoradic indices may be obtained and used for any arbitrary ordering of the canonical list. It may be useful, for example, to keep an index that has books sorted by title, another one sorted by author and title, and another one in publication date order. - Jim Washington ___ 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
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
