Remove upper bound on dependency requirements

jodal commented 10 years ago

I appreciate that you've recently loosened the dependency version requirements (ref #198), but the requirements are still way too tight.

My specific use case is Mopidy with its growing ecosystem of extensions, all necessarily needing to live in the same env/virtualenv as Mopidy itself. Since Mopidy-GMusic use gmusicapi, which again lock e.g. requests to <= 2.1.0, no other package in the entire ecosystem can use a newer version without creating havoc.

User scenario: If a user installed another Mopidy extension requiring "requests >= 2" first, he naturally got the latest version, 2.2.0. If he then installs Mopidy-GMusic, gmusicapi is dragged in as well. When he then tries to start Mopidy everything fails because gmusicapi requires an older version than what's installed, and Mopidy, trying to be nice and user friendly, checks that all dependencies are in place when loading extensions.

Generally, I'd use the following guidelines when setting requirements for a library (which is a very different use case from a application where you want to pin exact versions of everything):

Start with a dependency with no version requirement.
If you know you need a feature/bugfix that is only present from a specific version, add a lower version bound.
In the odd case you know that there are changes in the new version that will not work with your library, add an temporary upper boundary. As soon as you update your library to work with the newer dependency, you remove the upper boundary.