Rigid requirements force use of outdated libraries

[georgevreilly]

Requests is up to 2.8.1; Clom is up to 0.8.0a1. Pinning your requirements.txt to exact versions forces all your users to use out-of-date versions of these libraries. Better to say >= than ==.

[jong]

I disagree. Pinning requirements prevents unforeseen requirements issues in the future. These libs can probably be updated though.

[jong]

Closing was too strong, really this issue should be about bumping the requirements and making sure this lib works with those updated libraries.

[georgevreilly]

Pinning to an exact version number may be appropriate for some applications. It's not a good idea for a reusable library that may be used in many contexts that you can neither predict nor control.

The Requests library is used by a lot of other libraries. My primary app has 96 dependences, according to pip freeze. pipdeptree says that not only do I have a direct dependency on Requests myself, but so do three other packages that I'm using: Rollbar, Datadog, Mandrill. We haven't incorporated testing.elasticsearch yet because of the hard version requirement. Imagine if Mandrill and Datadog and Rollbar each required a specific, different version of Requests.

[morganiq]

For a public library like this, pinning does not mean, "I can guarantee this version works, but other versions might work too." Rather, it means, "Without these versions, I can guarantee it won't work."

That is almost certainly not the case here. All you are doing is forcing clients to re-roll custom packages with the dependencies unpinned, so that they can turn around and pin to specific versions in their application for stability if they so choose.

Please pin exclusively rather than inclusively—that is, pin only to exclude versions you know won't work. In the absence of any evidence to the contrary, an upstream package should, without question, not pin at all.