I certainly agree with everyone who has been saying that implementing modules can be painful. Implementing them was initially a multi-week nightmare of sleepless nights for me, and I still sometimes shake my head with their use. I think that a large part of the problem is that the documentation, which is actually pretty good, is (or was, haven't looked lately) rather bereft of "non-GitHub" and "local, non-domain name" examples. I also think that when you are in the early development stages of a system when there are many library changes taking place, and those libraries all need to be tagged with version numbers each time they change, it just seems a bit much for such early stage development on a system. I can definitely see the benefits, especially if your team is large, and I definitely appreciate them with regards to using open source GitHub modules, but for small teams or single developers with libraries that are in the midst of lots of change, it can be challenging. I didn't see any of the good ideas that I'm seeing in this thread when I changed over, which is unfortunate. Live and learn.
I work on Linux and ended up writing scripts to modify the import statements in hundreds of source files, and other scripts that somewhat automate the "go install, git add, git commit, git push, git tag, git push tag" sequence needed for one or all modules. I've also been meaning to look for or write some tool that nicely shows which modules are dependent on which modules, but just haven't had the time. I know they're in each module's go.mod file, but it would be nice to see some kind of big-picture dependency tree or something. It would also be nice to have tools that know which modules are affected by a library module change and just rebuild those when needed. Anyway, it's slowly becoming a part of my standard development practice and is less painful as time goes by. :) -Paul On Friday, 9 April 2021 at 09:01:34 UTC-7 Carla Pfaff wrote: > On Friday, 9 April 2021 at 17:38:12 UTC+2 gonutz wrote: > >> A replace in the go.mod file is of no help here because I still have to >> specify a require with a concrete version or commit hash for the library. >> This means I cannot just change the code in the library module, I also have >> to create a commit and check it in, then go back to my main module and >> udpate not only the replace but also the require in go.mod, every time I >> want to simply place a simple, temporary print statement for debugging >> purposes into the library. >> >> Does anybody have an easy workflow for the common use case? >> > > https://golang.org/doc/modules/managing-dependencies#local_directory > -- 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/7f290a9d-f889-4f2f-94f3-4d3e819b5d28n%40googlegroups.com.
