5 ms·
Pinning deps is a good thing, but it won't necessarily solve the issue of transitive dependencies (ie: the dependencies of requests itself for example), which w
by athrun 2y ago
Pinning deps is a good thing, but it won't necessarily solve the issue of transitive dependencies (ie: the dependencies of requests itself for example), which will not be pinned themselves, given you don't have a lock file.
To be clear, a lock file is strictly the better option—but for single file scripts it's a bit overkill.
- woodruffw 2y agoOh yeah, I completely forgot about transitive dependencies. That makes perfect sense, then! Very thoughtful design/inclusion from `uv`.
- einpoklum 2y agoOne could indicate implicit time-based pinning of transitive dependencies, using the time point at which the dependended-on versions were released. Not a perfect solution, but it's a possible approach.
- froh 2y agoisn't that quite exactly what the above does?
- kokada 2y agoI think OP was saying to look at when the package was build instead of explicitly adding a timestamp. Of course, this would only work if you speficied `requests@1.2.3` instead of just `requests`. This looks like a good strategy, but I wouldn't want it by default since it would be very weird to suddenly having a script pull dependencies from 1999 without explanation why.
- EdwardDiego 2y ago1 file, 2 files, N files, why does it matter how many files? Use a lock file if you want transitive dependencies pinned. I can't think of any other language where "I want my script to use dependencies from the Internet, pinned to precise versions" is a thing.
- hannibalhorn 2y agoIf there's a language that does this right, all ears? But I havn't seen it - The use case described is for a small one off script for use in CI, or a single file script you send off to a colleague over Slack. Very, very common scenario for many of us. If your script depends on a => c b => c You can pin versions of those direct dependencies like "a" and "b" easy enough, but 2 years later you may not get the same version of "c", unless the authors of "a" and "b" handle their dependency constraints perfectly. In practice that's really hard and never happens. The timestamp appraoch described above isn't perfect, but would result in the same dep graph, and results, 99% of the time..
- __s 2y agoRust tends to handle this well. It'll share c if possible, or split dependencies. Cargo.lock preserves exact resolution
- lmm 2y agoTry Scala with an Ammonite script like https://ammonite.io/#ScalaScripts https://ammonite.io/#ScalaScripts . The JVM ecosystem does dependencies right, there's no need to "pin" in the first place because dependency resolution is deterministic to start with. (Upgrading to e.g. all newer patch versions of your current dependencies is easy, but you have to make an explicit action to do so, it will never happen "magically")
- kokada 2y ago> 1 file, 2 files, N files, why does it matter how many files? One file is better for sharing than N, you can post it in a messenger program like Slack and easily copy-and-paste (while this becomes annoying with more than one file), or upload this somewhere without needing to compress, etc. > I can't think of any other language where "I want my script to use dependencies from the Internet, pinned to precise versions" is a thing. This is the same issue you would have in any other programming language. If it is fine for possibly having breakage in the future you don't need to do it, but I can understand the use case for it.
- lenkite 2y ago
- fluidcruft 2y agoI'm not a python packaging expert or anything but an issue I run into with lock files is they can become machine dependent (for example different flavors of torch on some machines vs others).