Dnia 2020-03-12, o godz. 19:11:48 Nick <n...@njw.name> napisał(a): > Forgive my ignorance, but why aren't gohack and > in the go.mod file perfectly good replacements for these use cases? > I get the feeling I'm missing something...
> why aren't gohack Gohack is an invaluable tool to hack around without need to manual edits of go.mod once a couple of minutes. Note the "hack" in its name, though ;). Note also, that this exact mechanics used for modules could work over repos staying in the GOPATH. For way less code and effort that went into centralized zipfiles solution. > and replace statements in the go.mod Explained in pointed to go.mod.local issue: tl;dr – go.mod changes intended for local tinkering may inadvertently end in the CI pipe. It is cumbersome to do all that dance just to tinker in an early stage of minting something new. > I agree that anything that penalises people for not using Google > services is problematic, but I don't see how that's happening here. TL;DR - IMO, Go community is now being led into the technically unsound dependency off G/cloud infrastructure. Escape paths, still present yet, are full of obstacles and are easy to close in the future, would G wish so. LR: Offline setup is still possible, but now it is cumbersome and full of traps. We somehow went from the self-contained local tree of dependencies' full source – gathered from any of supported VCS repo – to the cloud infrastructure managed by G from where zipfiles (hello npm!) are downloaded then checked against G owned database. In the case of godoc.org sunset [1], it was not even planned for you to run local docs server at all (G backpedaled on this a bit due to a backslash from the community [2]). Still it is G who can decide whether your code deserves to be listed at go.pkg.dev [3]. It now is a well lubricated slope to some future "notarization / approval" process. I am an old frog and I think I can discern whether I am being cooked even if pot I am in is advertised as a comfortable warming device. [1] https://blog.golang.org/pkg.go.dev-2020 [2] https://github.com/golang/go/issues/36747 [3] https://github.com/golang/go/issues/36840 PS. I do not blame the technical team, as IMO this was a "business decission" in upper echelons of Google what dev-team as a G employees, must obey. > Nick -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20200313135617.0ec6fdb3%40xmint.
