I can only say that it works so well that I never needed to understand it deeper. My biggest chore related to dependencies is to clean go.sum files from time to time. I use go mod tidy for that.
I also run local go modules proxy (Athena) at home simply because I often update dependencies in multiple projects.
My biggest chore related to dependencies is to clean go.sum files from time to time. I use go mod tidy for that.
You do not need to clean go.sum. That file is an (almost) append-only log of checksums of modules that may be considered when building your dependency graph, and it’s used only to detect corruption or malfeasance. It’s not a lock file, and it doesn’t really represent the size or state of your dependency graph. (At best, it has a correlative relationship.) You should check it in for safety reasons, but there is basically no reason you should ever look at it, or care how big it is.
In a situation when you were using foo@v1.0.0 and then updated to v1.0.1.
The record in go.sum related to the older version does not serve any purpose. Is this a valid assumption?
I see this makes sense, and my understanding was the same.
I have slowly navigated towards a minimal possible number of dependencies in my code. Bumping a single dependency typically (but not constantly) leaves me with just one version required.
I don’t think you can make very many authoritative claims about the relationship between your dependency graph and the contents of go.sum. The rules that govern that relationship change from version to version.
I can only say that it works so well that I never needed to understand it deeper
Yup. I remember fiddling about with packages in Node and Python so much, but never really had to worry in Go.
With Go, there was the initial occasional issue with people changing the capitalisation of their usernames (and causing package breakages), or initial teething issues, but when everyone follows the rules (and most do), it works fine!
Wow. I’ve been using hammerspoon for a few years, but today I learned about URLDispatcher. That’s going to save me so many browser tabs with Zoom meetings!
I can only say that it works so well that I never needed to understand it deeper. My biggest chore related to dependencies is to clean go.sum files from time to time. I use
go mod tidyfor that.I also run local go modules proxy (Athena) at home simply because I often update dependencies in multiple projects.
You do not need to clean go.sum. That file is an (almost) append-only log of checksums of modules that may be considered when building your dependency graph, and it’s used only to detect corruption or malfeasance. It’s not a lock file, and it doesn’t really represent the size or state of your dependency graph. (At best, it has a correlative relationship.) You should check it in for safety reasons, but there is basically no reason you should ever look at it, or care how big it is.
Thanks, it is good to know! I believe it is just a personality deformation, to delete lines that are not required.
I don’t think “required” is actually well-defined, when it comes to lines in go.sum.
In a situation when you were using foo@v1.0.0 and then updated to v1.0.1. The record in go.sum related to the older version does not serve any purpose. Is this a valid assumption?
Well, does a transitive dependency depend on v1.0.0? Depending on how optimized the modules tool is, it could still need to download and evaluate it.
I see this makes sense, and my understanding was the same.
I have slowly navigated towards a minimal possible number of dependencies in my code. Bumping a single dependency typically (but not constantly) leaves me with just one version required.
IIRC
go.sumshould only “shrink” when you switch or remove a dependency, right?I don’t think you can make very many authoritative claims about the relationship between your dependency graph and the contents of go.sum. The rules that govern that relationship change from version to version.
Yup. I remember fiddling about with packages in Node and Python so much, but never really had to worry in Go.
With Go, there was the initial occasional issue with people changing the capitalisation of their usernames (and causing package breakages), or initial teething issues, but when everyone follows the rules (and most do), it works fine!
Wow. I’ve been using hammerspoon for a few years, but today I learned about URLDispatcher. That’s going to save me so many browser tabs with Zoom meetings!
this specific use case was my exact motivation for heading down this path.
I set it up yesterday and already it’s saved me whole minutes! Thanks for figuring out the chrome profile selection logic, that works like a charm (:
minutes! pay it forward :-)
The Chrome profile logic is awesome!
I’ve combined that with URLDispatcher, and it looks like this.