[Zope-dev] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.

[Benji York]

On Tue, Dec 9, 2008 at 9:01 AM, Gary Poster <gary.poster at gmail.com> wrote:
>
> On Dec 9, 2008, at 8:43 AM, Benji York wrote:
>
>> On Mon, Dec 8, 2008 at 12:23 PM, Tres Seaver <tseaver at palladion.com>
>> 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