twisted / nevow

Web Application Construction Kit

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

why does Nevow depend on Twisted >= 13.0?

zooko opened this issue · comments

Dear folks:

According to

nevow/setup.py

Line 90 in 4643891

install_requires=[
, Nevow requires Twisted >= 13.0. Here's the patch that added the declaration of dependency on Twisted: 0eb20bb

Do you know if there's any reason it wouldn't work for us to use Nevow 0.11.1 with Twisted == 11.0.0, == 11.1.0, == 12.0.0, == 12.1.0? Those are versions of Twisted that our users are currently able to install on Windows: tahoe-lafs/tahoe-lafs@d888b28 (due to https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2028 (Twisted endpoints introduce a dependency on pywin32) and http://twistedmatrix.com/trac/ticket/6032 (make twisted.internet.endpoints importable on Windows when pywin32 is not installed)).

The requirement Nevow imposes for Twisted >= 13.0 is also causing a different install problem for a user on Mac OS X: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2249# OSX: Installed distribution Twisted 12.2.0 conflicts with requirement twisted>=13.0

Zooko, if you'd like Nevow to support a different range of versions of Twisted, great!

As a first step, please create a pull request which adjusts the travis configuration to test Nevow against that range of Twisted versions. The new builds don't even have to pass, just make sure to mark them as allowed to fail if they fail. If there are failures, then please create issues for fixing each of them (and then pull requests and so on). Thanks.

I wasn't offering to support it, I was asking why it was marked as requiring Twisted >= 13.0. I infer from your answer that the reason is that it is only supported (which means tested and that someone intends to fix bugs) with Twisted 13.0 and all versions newer than that?

I think this ticket should be re-opened until documentation of the meaning of this (e.g. a docstring in https://github.com/twisted/nevow/blob/master/setup.py) is added.

I'm sorry if this wasn't clear, but different people use the dependency annotations in setup.py to mean different things, so without accompanying documentation explaining what you mean by Twisted >= 13.0, it is ambiguous. I think the most common policy is "If there is a known bug which prevents compatibility with Twisted < 13.0, and we do not intend to fix that bug, then we bump the version requirement to Twisted >= 13.0". So when I encountered this specification the first time, I assumed that there was such a known bug and I set about looking for it. Suggested doc::

"""
The reason that we specify `Twisted >= 13.0.0` here is that this version of Nevow is tested against Twisted == 13.0.0 and == 14.0.0, and we intend to test it and fix any incompatibilities between newer versions of Nevow and newer versions of Twisted.
"""

(That's still a bit ambiguous, about what your intended policy is for when you come out with Nevow v20 and Twisted comes out with Twisted v30. If you can make it clearer and more true to your intend that would probably be better.)

Okay. Thanks for clarifying.

From our point of view this is a regression of Nevow 0.11.1 relative to earlier versions. I can certainly see the rationale for bumping the requirement, but it would have been useful to make a release that fixed important packaging bugs before adding another packaging regression. Sigh.

If there is behavior that's important to you, you have to actually communicate it to the project maintainers - preferably in the form of automated tests that can be used by the continuous integration system.

I'm sorry this has caused problems for the Tahoe project. I am. However, you cannot expect the project to remain frozen nor can you expect your requirements to be intuited by other developers.

If you need absolute stability, I suggest you pin your dependency to an exact version of Nevow.

We did communicate the behaviour that was important to us! We asked on https://bugs.launchpad.net/nevow/+bug/1091055 and https://bugs.launchpad.net/nevow/+bug/812537 for a release that just fixed that packaging bug. We couldn't have predicted that another packaging regression would be added in the same release. That is the reason why we're unable to pin the dependency; we have to choose between working around the original bug or the regression (or both).