5 ms·

It's not wrong to depend on a single version, just suboptimal. Exhaustively testing every combination of dependencies with your project is infeasible for any n

It's not wrong to depend on a single version, just suboptimal. 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.

qwerty456127 3y ago
Why not just replace the "requires" semantics with "has passed tests with" and "has failed tests with" and let the host decide?
- pxc 3y ago
  This is basically what I daydream about for Nix some day (Nixpkgs doesn't currently involve any dependency resolution at all). Just recording successful version combinations (both of a package declaration and source version and dependency versions) would let us add versioning metadata and save historical package versions in-repo (or in an ancillary repo) without actually changing how the monorepo is built/used.
- throw10920 3y ago
  In general: no reason, I quite like your idea and think that it's useful. However, in the specific case of the blog post: because that's more complexity, which requires more effort. 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.

qwerty456127 3y ago

Why not just replace the "requires" semantics with "has passed tests with" and "has failed tests with" and let the host decide?

pxc 3y ago
This is basically what I daydream about for Nix some day (Nixpkgs doesn't currently involve any dependency resolution at all). Just recording successful version combinations (both of a package declaration and source version and dependency versions) would let us add versioning metadata and save historical package versions in-repo (or in an ancillary repo) without actually changing how the monorepo is built/used.
throw10920 3y ago
In general: no reason, I quite like your idea and think that it's useful. However, in the specific case of the blog post: because that's more complexity, which requires more effort. 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.