If you write a package and you use pip to install and test it, pip will install the requirements according to what is requested, by default the latest acceptable version.
If somebody else installs your package at a later time, pip will again install the latest fitting versions.
This install will be different from your install, or from other installs other people made in the meantime.
If a newer version if a dependency breaks your package because it has a backwards-incompatible change, your package won't work - and it will not show up in your testing because pip sees the existing, already installed packages and will think they are new enough. So, you'll find "it works for me".
A good examples are packages like python-opencv which break on python2 because the versioning implies they are backwards-compatible but they (or their given dependencies) use syntax which is not supported by python2.
And these things tend to snowball quickly because the number of packages which other packages depend on tends to grow exponentially, without a real upper bound.
And while there is lots of annoyment and cursing about package managers, I think a huge part of the problem is a cultural issue in the python community because people accept and create libraries with backwards-incompatible changes without marking that in the version numbers.
If somebody else installs your package at a later time, pip will again install the latest fitting versions.
This install will be different from your install, or from other installs other people made in the meantime.
If a newer version if a dependency breaks your package because it has a backwards-incompatible change, your package won't work - and it will not show up in your testing because pip sees the existing, already installed packages and will think they are new enough. So, you'll find "it works for me".
A good examples are packages like python-opencv which break on python2 because the versioning implies they are backwards-compatible but they (or their given dependencies) use syntax which is not supported by python2.
And these things tend to snowball quickly because the number of packages which other packages depend on tends to grow exponentially, without a real upper bound.
And while there is lots of annoyment and cursing about package managers, I think a huge part of the problem is a cultural issue in the python community because people accept and create libraries with backwards-incompatible changes without marking that in the version numbers.
Obligatory link to Rich Hickey's brilliant talk on how to do it better: https://www.youtube.com/watch?v=oyLBGkS5ICk