On Tue, Dec 9, 2008 at 9:01 AM, Gary Poster <[EMAIL PROTECTED]> wrote: > > On Dec 9, 2008, at 8:43 AM, Benji York wrote: > >> On Mon, Dec 8, 2008 at 12:23 PM, Tres Seaver <[EMAIL PROTECTED]> >> wrote: >> >>> Stripping all versions from the dependencies in setup.py only works if >>> users are willing to run their own package indexes, and figure out edge >>> cases such as the ones you describe by themselves: >> >> The above claim appears false. Every project (both the open and closed) >> I work on has virtually no versions in setup.py and we don't use a >> private package index. We use a version section in the buildout. > > The "virtually" is the catch here. They do have some.
Yep. I maintain that we'd (or at least I) would be better off with fewer (but quite possibly not none, see below). > They are typically introduced when an older version of a dependency *does > not work with the software*. To me, "does not work" == "breaks tests". > Because our community, and others, try for backwards compatibility, this > kind of assertion happens relatively rarely. > > These setup.py assertions are always, or almost always, not "pinning" but > saying "I work with X or better." I'm advocating these sorts of "X or > better" assertions. The problem arises when your definition of "works" (the tests pass) conflicts with another user of the package's idea of "works". Individual packages do many things for all those things to work simultaneously, then yes, the tests should pass. However, some users of that package may not need (or want) all of the things that a package does. Let me try an example. Lets say that a new version of a package (A) that I use comes out and it has some new features. Some features I would like to use, others I'm not interested in. Upon trying the new version setuptools/buildout complains that there is a version conflict because there are minimums in package A's setup.py. The new package's declared minimum for package B is higher than what I'm using, so I upgrade package B. After doing so I run my tests and find that they fail. After investigating, I find that the new version of package B has changed behavior or introduced a bug such that it is unusable for me. However, I find that if I use the previous version of package B my tests pass and the new features of package A that I want also work, then I'm happy; even though package A is "broken" it still works for me. I now have time to track down the problem(s) in packages A and B and reconsile them with their author(s) while still benefiting from the new features I need in package A. Of course, since the versions are specified in setup.py, I have to fork project B, so that's a little irritating. Let me re-run that scenario with no versions in setup.py: Upon trying the new version setuptools/buildout does not complain that there is a version conflict. I run my tests and find that they pass. I declare my upgrade a success and go on about my life. Someone might come back with a rejoinder that when I want to use the features of package A that don't work with the version of package B that I'm using I'll have a problem. True. Is this better or worse than the alternative? I think it's better because I only deal with version issues if I must, not just because version minimums are forced on me. I'm sure someone with a better imagination can come up with additional/better examples. > Christian's zope.testbrowser change fits these characteristics. Do you, or > Stephan, or anyone else with your opinions, have some other additional line > that must be crossed, or do you assert that setup.py should never have any > version numbers? The only time I can imagine a version number in a setup.py being a good idea is if a lower version of the dependency will have truly detrimental affects (like it has been turned into a trojan) or if every conceivable use of a package is broken without that minimum version. But even "being able to import an interface" is a conceivable -- and common -- use of a package, and that works no matter what version of dependencies are used (normally). > For instance, if you have a project that requires a newer API in, say, > zope.component, do you assert that it is inappropriate to specify a > zope.component of "X or better" in your setup.py for that project? That sounds like something that should be documented in the CHANGES for the project, but I don't think forcing the version number is warranted even in that case (e.g. "I just want to import an interface why do I have to upgrade a dependency"). I wonder if the best possible world might be one in which setup.py versions are overridable by buildout's version section. That would seem to give people both options. In fact, that sounds really appealing to me. I'd like to know that a package author thinks I should use a newer version, while maintaining the option of easily ignoring their advice. I am still a little confused though. I guess people who want minimums in setup.py don't nail versions in their buildouts. (?) This message brought to you by -vvv. ;) -- Benji York Senior Software Engineer Zope Corporation _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
