Earlier quoted context omitted.
You can put your project in ~/work/my-go-project but then symlink it to ~/go/src/github.com/joshklien/my-go-project (assuming your $GOPATH is ~/go). But yes, with modules you don't need to do this anymore. go mod init github.com/joshklien/my-go-project
Not all go tools respect symlinks, since Rob Pike decided that symlinks should not be supported. https://github.com/golang/go/issues/15507#issuecomment-24158...
Using Go Modules
101–110 of 124 posts
Re: Using Go Modules
#102Earlier quoted context omitted.
> I like the Debian solution to this, which permits freeform textual suffixes, so that in the hypothetical scenario above, you can release v1.2.3bigco1, v1.2.3bigco2, ... Go also allows freeform textual suffixes, it just needs a `+` in there: v1.2.3+bigco1, v1.2.3+bigco2.
Oh wow, so they are not following semver? In semver everything after + is a build tag that does not "modify" the version (i.e. 1.2.3+a and 1.2.3+b are considered to both be the same version, just e.g. built at different times).
The blog post links to the Semantic Versioning spec, specifically item 9.
> A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
Item 10 explains how + can be used to add a build tag.
> Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
Instead of using v1.2.3bigco1 or v1.2.3+bigco1, we should use v1.2.3-bigco1. If we need to add a build tag we can use v1.2.3-bigco1+001.
Re: Using Go Modules
#103Making sure I understand this: I’m some independent developer working in many languages. I like every project I work on to be inside ~/work/ within a subdir I name based on the project. I used to be annoyed that I had to put every go project into a dir 7-8 layers below that e.g ~/work/go/src/github.com/joshklein/project/cmd/hello_world.go, but now I can have ~/work/go_hello/src/main.go. Right? I understand this isn’t…
You can put your project in ~/work/my-go-project but then symlink it to ~/go/src/github.com/joshklien/my-go-project (assuming your $GOPATH is ~/go). But yes, with modules you don't need to do this anymore. go mod init github.com/joshklien/my-go-project
Where in your gopath are you supposed to put your source code if you never intend to upload it? All gopath tutorials I see say to put your github in the path like you did, and never say what to do if its not public.
Re: Using Go Modules
#104Earlier quoted context omitted.
Gocode works in vim but for some reason won't do autocomplete in spacemac's go-mode. I haven't found the time to look for a fix yet. There's a fork of Gocode that fixes it, but makes vim's autocomplete very very slow. As someone who switches between vim and emacs I wish this mess gets sorted out soon!
What's the fork that fixes the problem? I haven't used Go since modules released, but I'm going to be needing it soon, and this is something I need.
It's this one. https://github.com/stamblerre/gocode
Re: Using Go Modules
#105Earlier quoted context omitted.
Gocode works in vim but for some reason won't do autocomplete in spacemac's go-mode. I haven't found the time to look for a fix yet. There's a fork of Gocode that fixes it, but makes vim's autocomplete very very slow. As someone who switches between vim and emacs I wish this mess gets sorted out soon!
HEAD of vim-go has now gopls support, which has excellent support for Go modules for code completion and jumpt to definition. Give it a try.
Oh, I'm already using vim-go, but didn't know it does code completion too. Thanks for writing such a great plugin!
Re: Using Go Modules
#106Earlier quoted context omitted.
nah. we’ll agree to disagree on this one. most devops cloud stuff is written in python. you know what’s written in go? terraform. i have yet to meet someone that has actually leveraged terraform in a production setting and does not think it should be banned. what else? k8s? the favorite poster boy of our generation. solving problems you don’t have and replacing figuring out how to deploy your stuff with the anguish o…
I'm curious as to how much golang is even used inside Google itself, since they actually have to write maintainable code that does nontrivial stuff, and not follow the latest fads
good news is that it’s buckets. bad news is that it’s C++ and Java
Re: Using Go Modules
#107Every mainstream programming language that came out in the last 20 years has already solved this. Java, Javascript, Ruby, Python, Rust, you name it. I am baffled to why Go has not figured this out and are presenting recent developments as some kind of breakthroughs - they are not. To me, and I'm not trying to be disrespectful here, because of the shortcomings it has, Go is in the experimental/keep an eye on bucket. I…
It's how basically the entire language is, they keep reinventing the wheel, only in a subpar way and market it as if it's some breakthrough, and people who don't know better drink the Koolaid. golang wouldn't have gone anywhere if it didn't have the Google name behind it. Did you even notice how verbose the testing code was in that post?
we should form a club or something. we’ll call it the gopher 8th light seekers and drink sparkling water +
bitch about go while the rest invent the future. in go :)
Re: Using Go Modules
#108Earlier quoted context omitted.
As far as I can tell, rsc.io/sampler isn't a git repository, so it's not doing the same stuff `go get` does. If I try to clone it I just get hit by the HTTP redirect to the docs for rsc.io/sampler. I may be missing something here (it's been quite a while since I did serious Go stuff so `go get` may have changed too) > Does it, though? It's a blog-post, not the "normal" documentation. The full docs are much more expli…
> As far as I can tell, rsc.io/sampler isn't a git repository, so it's not doing the same stuff `go get` does. If I try to clone it I just get hit by the HTTP redirect to the docs for rsc.io/sampler. Why would you try to `git clone` it directly instead of trying to `go get` it? $ GO111MODULE=off go get -v rsc.io/sampler Fetching https://rsc.io/sampler?go-get=1 Parsing meta tags from https://rsc.io/sampler?go-get=1 (s…
Ah, I wasn't aware that the meta tag existed, everything about publishing crates seemed to point to using github (or a self-hosted repository of various supported VCSes)
Thanks.
The example using a less-commonly-known package distribution method is probably causing the confusion in Animats' original comment.
Re: Using Go Modules
#109The main thing that annoys me about Go modules is that it broke so much tooling. I still can't get GoCode to work properly, and there are 4 or 5 different forks of the repo all trying to add module support, its a mess.
Preach, gorename doesn't work either and seems to be in a pretty uncertain state.
This issue is tracking compatibility of common tools https://github.com/golang/go/issues/24661
Re: Using Go Modules
#110Be warned that if you like all the tooling VSCode provides for Go then that is still not available if you are using go modules. They are working on it and there are some rough betas out there for some limited functionality but simple things like renaming variables etc, are still not available. Realize this is a tooling issue and not necessarily a language one, but do feel like they should be mentioning this. It makes…
I agree, I tried go modules a couple of months ago but the VSCode tools were much slower and cpu usage increased when using go mod extensions. I reverted back to not using go modules at the time, will try again soon to see if it improved. I still like go modules.