I have a wonderful video of a GO program I wrote over 5 years ago which will not compile today due to my failure to vendor one lost module. I too had multiple paths in my GOPATH and it varied upon the client. I consider the new modules an improvement but the adaptation has not been without pain.
For students who are experimenting and testing and trying things, and only running and compiling locally, a single experimental repository with a doc.go file and v0.0.0 module for an experimental pkg and cmd works very very well and if they do create a useful abstraction then they can refactor and publish the result with ease at the end of the semester after they have a mastery of the language. I have a student using vscode and my vscode is complaining that my Go1.16 installation does not have a GOPATH. On Thursday, February 25, 2021 at 6:36:36 PM UTC-6 mar...@gmail.com wrote: > Given the writing on the wall that GOPATH is going away, what I have done > is created a single module where I keep all my own code, each different > experiment in its own subdirectory. I named it "github.com/...", but > never submitted it to github, so in the future I can do that without too > much fuss if I wanted to. > > Having been writing Go heavily since 1.2, I find the > all-code-in-one-module approach to be the easiest so far. > > -- Marcin > > > On Thu, Feb 25, 2021 at 4:21 PM Bob Alexander <bobj...@gmail.com> wrote: > >> Agreed -- module mode is great for "delivered code". But in a personal >> single machine single developer environment, all the extra complexity and >> manual overhead might not worth it. I'd guess that most students and >> hobbyists don't even use SCMs. My point was that GOPATH mode is good for >> them. >> >> On Thu, Feb 25, 2021 at 1:38 PM Robert Engels <ren...@ix.netcom.com> >> wrote: >> >>> That is 100% true but a important point is that using GOPATH requires >>> manual dependency management via ‘vendoring’. This can be very labor >>> intensive and error prone - leading to security issues in your delivered >>> code. >>> >>> On Feb 25, 2021, at 3:08 PM, Bob Alexander <bobj...@gmail.com> wrote: >>> >>> >>> GOPATH mode does *not *limit your Go code to a single directory. I've >>> seen this misunderstanding stated in probably hundreds of various posts. >>> >>> $GOPATH allows specification of multiple directories. I've used that >>> capability for several years to distribute my Go code to my personal >>> general library and to various application-specific libraries. Each of the >>> multiple GOPATH directories refers to a Go "workspace", so the result is my >>> general library workspace plus mini-workspaces in various application >>> directories -- each with src, pkg, and bin subdirectories. A single go >>> install installs all workspaces specified in your GOPATH at once, or you >>> can selectively build by temporarily changing the GOPATH. >>> >>> This is a pretty good setup for me, a decades-experienced software >>> engineer working in "programmer" mode for my personal development. >>> >>> Go's goal of ending GOPATH mode sounds like a choice to serve the >>> professional software engineer, and not the personal programmer. Module >>> mode is a good thing if you are publishing your code, but is a lot of >>> additional labor and cognitive load for us "programmers". >>> >>> I wonder if this might discourage adoption of Go by certain categories >>> such as college and high school students, non-software-engineer >>> professionals who write internal programs for their business, and curious >>> folks who want to introduce themselves to Go. It is soooo much easier to >>> set up my environment with GOPATH mode. In attempting conversion to MODULE >>> mode, I've spent lots of frustrating hours and it's still not working >>> perfectly! >>> >>> So, I am +1 for retention of GOPATH mode (as well as MODULE mode), >>> allowing Go users to make the choice of MODULE vs. GOPATH based on their >>> needs. >>> >>> -- >>> 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...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/CAKyHfRPYgop6YPgk3AcJ4Q43NgV%3D9KP%3DzgYja8Z6FJuc0UuPig%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/CAKyHfRPYgop6YPgk3AcJ4Q43NgV%3D9KP%3DzgYja8Z6FJuc0UuPig%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >> 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...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAKyHfRPw125S_800nhBxV9UrqHCaet-8WAO2q%2B1Xah3dhNiS5w%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/golang-nuts/CAKyHfRPw125S_800nhBxV9UrqHCaet-8WAO2q%2B1Xah3dhNiS5w%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/c2de6dd0-c8eb-4672-8378-46db73e36e4fn%40googlegroups.com.
