Dependency on requests is too restrictive about prance HOT 6 CLOSED

The version is just best practices in package management. You can somewhat rely on future package versions to provide the same API as the version you're testing with, but not on past versions. Therefore, the dependency is for any 2.x greater or equal to 2.21 (See https://www.python.org/dev/peps/pep-0440/#compatible-release )

The problem in this case is that docker-compose does not specify versions according to PEP-0440, by explicitly excluding 2.21 for what appears arbitrary reasons. If you look at the commit that excludes 2.21, you can see they increase the version from 2.20 here. It seems they follow every requests release and manually update the maximum allowed version. That's bound to create this type of issue.

File an issue with docker-compose. Feel free to reference this issue here, and I'll jump in on the conversation.

from prance.

I just saw you opened an issue there already and jumped in, sorry. And thanks for doing so!

from prance.

It's not about best practices, and your reading of what Docker package specification does is really off...

But I am not writing this to put blame. I am quite sure that docker-compose had much more reasons to choose the constraints that they did than you had. They receive a massive volume of bug reports and their approach to dealing with bugs resulted from requests usage was to disallow particular versions of this library.

You, on the other hand, never had any such bug reports. My understanding is that you simply wrote down whatever version you happened to use at the time of developing your library. Which is a good first step, but it prevents a lot of people with requirements which include your library as well as other things from using your library.

What I'm saying is that you use requests in only one place in your code, for a very trivial thing, which would have worked with a lot more versions than what you declared. If you relaxed this unreasonable requirement, it would allow other people to use your package, and there still would be no bugs when they used it.

In other words: your approach to versioning your dependencies is overly restrictive. Really, if you wanted to establish which versions are possible to use with your library, you would have to have a sizable matrix of tests (there are about hundred or so versions of requests there in the wild), and based on those test results you could've concluded that some versions did not work. Alternatively, you could have relied on users of your library to provide feedback when requests did not work as you expected. In either case, you would have a much more permissive version requirement than what you have now.

from prance.

PS. Re' your comment: that's not how ~= is interpreted by setuptools. To setuptools it means that you are free to choose release version, but you must have the same major and minor. In particular, this will not allow you to use a newer version of the library, only a newer release / build.

docker-compose, on the other hand, do not allow using newer versions of requests on purpose: it's a library that must have caused them a lot of trouble, and it keeps updating at a very high rate, so they want to prevent breakage due to people installing a very new version that they never tested their code with. Sub-optimal, but very understandable, given the circumstances.

from prance.

My approach is what decades of testing and release management best practices have established.

I can recommend looking at https://semver.org/ as a starting point, to read up on DSO versioning (e.g. from the excellent https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf guide by Ulrich Drepper) and how it feeds into Linux distribution package management, or read about release management in a paper book such as https://www.amazon.com/Software-Release-Methodology-Michael-Bays/dp/0136365647/ . Those are approaches that provide stability and an upgrade path, and have been established a long time ago when facing the same kind of problem.

The TL;DR remains that you follow three steps:

1. Pick an interface version (in semver that's the major number component)
2. Develop and test against an implementation version (in semver that's the minor number component)
3. Depend on the interface version with the implementation as the minimum. Then pray to Cthulhu that the other package's maintainer doesn't screw up.

That last point makes the approach brittle, because package maintainers can screw up, but allows for an upgrade path in the face of bugs. Turns out, it's still usually the best of a number of shitty approaches.

So, sorry, but no - docker-compose has worse reasons than me for doing what they're doing. The worse part being that they ignore what other people have figured out the hard way long, long before them. But that's sort of the rallying cry for the entire Docker ecosystem, so I can hardly be surprised.

from prance.

PS. Re' your comment: that's not how ~= is interpreted by setuptools. To setuptools it means that you are free to choose release version, but you must have the same major and minor.

No, it means the major must be the same, the minor must be the same or higher. See the link I posted earlier about PEP-0440, and also perhaps try it out.

from prance.