Just because someone says X does Y, it doesn't mean it does.
For anything serious you absolutely verify checksums. Ideally you also mirror every dependency used so you don't care anymore about what's out there.
The thinking in your comment lead to Maven range and npm general atrocities.
Every time an old unmaintained Linux app I need fails to start, saying it needs some libsomething.2.3 which isn't in the repos already I just symlink the libsomething.2.5 to it and it works great.
Some times this even helped me to overcome bugs/vulnerabilities.
Being able to fix a bug and update a library without the program even knowing (whithout having to get and rebuild the source or contacting the author) is why dynamic linking has been introduced in the first place, isn't it? Isn't this the "unix way"? Is having a program superglued to an outdated library with known (and fixed already) bugs really what you want?
It depends on what you want to do.
If you're hobby hacking stuff, sure.
Any kind of software that's supposed to come out of software engineering, probably not.
It is not superglued. If you want to update dependencies, just remove the lockfile and reinstall everything. The main reason people do this is because just updating a library without the program knowing by not specifying the exact version leads to behaviour silently changing, which is terrible (especially on CI!)
I love you.
Exhaustively testing every combination of dependencies with your project is infeasible for any non-trivial set of dependencies. The "is compatible with" relationship present in some package managers (e.g. ~= in pip) isn't guaranteed to work because packages can "lie" about their compatibility.
Sure, it's better to have some kind of way for a piece of software to specify that it depends on foo 3.x instead of tying it to a specific release, but at least being able to specify some dependency is better than not at all. In the worst case, the user can treat the "required" version as a suggestion/guide, override that version with whatever they want, and see if the code works.
I suspect that the author would have added in a more complex versioning/dependency system if he had more time/energy. But, given that he didn't, he had to make a choice about what features to include, and how much to flesh out the various systems.
A simple "depend on exact version" system is relatively easy to implement, and still (indirectly) supports users overriding the lockfile by manually editing it. A more complex (but flexible) system like pip's or yours would be more ideal from a user's perspective - the developer just needs to put in the time to implement.
However, I don't think that any of the above systems are wrong, unlike e.g. one that only allows you to specify a specific version in the lockfile, but then silently downloads "updates" to those dependencies in the background.
