-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default branch, release-branch.v6 has some compile/import problems #877
Comments
Can you please specify what you’re doing exactly? Tests are running fine (https://travis-ci.org/olivere/elastic/builds), and recipes are working as well. I just prepared Elastic for Go modules the other day. |
I realize this isn't the recommended way but I just to do It looks like go get is checking out the default branch which is release-branch.v6 which includes a bunch of /v6/ paths that don't appear to be in the same branch. |
Yah, that seems to be it... check out release-branch.v6 and client.go references import path |
Me too, I just glide install new package. Seem doesn't exist |
As Elastic is on version 6 already, the correct thing is to use Go modules as advertised and ask it to install v6 of the library. So you need to add that I changed import paths to be Notice that both |
Here's the PR in |
Any chance you would consider changing the default branch to be something just less than <6.2.0 so it will still work for people using GOPATH until modules are a much more mainstream thing. |
Using "github.com/olivere/elastic/v6" as import path and running
Did I miss something? Sorry, Im quite new to Go |
I have purposely avoided using dependency managers until now because I knew modules were coming and really only wanted to make the jump once. I've been using your library without issue for quite a while because I've kept current with elastic. |
@snowzach Modules are supported for both Go 1.10 (with 1.10.4) and Go 1.11. That covers the release policy already used with Go itself. You have different options. First is to vendor version 6.1.x. Second is to use something like |
@snowzach Go modules are there, and you can use them with a recent version of Go. What's stopping you? |
@MoritzGoeckel What version of Go are you on? What does If you're using Go 1.10.4 or later, are you in a sub-directory of |
@olivere |
@MoritzGoeckel Go 1.11 has Go modules disabled by default in In the long run, Go is moving away from |
Everybody trying to figure out what's going on with Go 1.11 and Go modules, please try this recipe first:
|
@olivere it would appear that some of my build process breaks when switching to modules. I rely on some generated code using |
@snowzach If I can help, let me know. From my experience: If you can use a recent version of Go, it will just work: You only need to change the import path. |
Okay thanks for the offer. |
@olivere This is not an acceptable solution to our problem. The changes to the default branch paths are not backwards compatible for consumers who've not yet enabled the experimental module support. EDIT: From the release page:
|
I'd consider rolling back the changes. But I need to understand what's causing the issues: Changing the import path? Not being able to use Go modules with an existing dependency manager like |
@olivere Thanks for your response. My choice would be to keep the modules changes in a branch -- something go modules support 😄 Mostly I think if you can just release a v6 tag everyone can use with gopkg.in that imports from a gopkg.in path like you've done for v5, everyone should be sweet for a while. Ideally though, if you want to support users on |
My primary concern has always been to limit breaking changes. I didn't expect this to hurt users so deeply. While I still think changing the import path and supporting a current version of Go would be the correct way forward, I understand that some of you are not ready to do so right now. With regards to the default branch on for So 6.2.1 will revert the changes to the import path. I'm testing the impact as I'm writing this. I'm deeply sorry for the confusion. |
I just released 6.2.2 which tests on Go 1.10 and 1.11 both with Changes to the import path are reverted, so keep using However, as a reminder: DO NOT use the default branch. It will break from time to time. Use tagged releases! |
Thanks @olivere, fantastic response time! I really appreciate your effort on this. |
Yes, thanks @olivere ! |
I am about to switch to go modules but it appears the branch release-branch.v6 has some import problems when you just try to use it using old-fashioned GOPATH...
When you compile you get:
I realize you recommend to use a dependency manager however prior to your latest update it still worked okay.
The text was updated successfully, but these errors were encountered: