Go 1.11 module support #39

talbright · 2018-12-23T17:18:43Z

MODULE SUPPORT

Go 1.11 includes preliminary support for versioned modules as proposed here. Modules are an experimental opt-in feature in Go 1.11, with the hope of incorporating feedback and finalizing the feature for Go 1.12. Even though the details may change, future releases will support modules defined using Go 1.11 or vgo.

This PR drops the v3 path. For detailed discussion see comments in this PR.

This PR continues support for vendoring for older versions of GO (https://github.com/golang/go/wiki/Modules#how-do-i-use-vendoring-with-modules-is-vendoring-going-away)

Older versions of Go such as 1.10 understand how to consume a vendor directory created by go mod vendor, so vendoring is one way to provide dependencies to older versions of Go that do not fully understand modules.

TODO

Determine vendoring approach
Update docs
Improve build with Makefile(s) which: will be invoked by travis instead of go test and include appropriate checks such as gofmt
Update travis to build 1.9 - 1.12 (https://docs.travis-ci.com/user/customizing-the-build/#build-matrix)
Minor improvements to schema generation script and inclusion of generation target in makefile

⭐️ After merging be sure to create a github release
⭐️ Use semver and github releases moving forward

Addresses #37

cyberdelia · 2018-12-25T09:15:09Z

For the record, v3 was meant to match the API version more than indicating the version of the “library” itself.

alindeman · 2018-12-31T15:11:29Z

For the record, v3 was meant to match the API version more than indicating the version of the “library” itself.

I think this is important. Is there any way we can make this project compatible with modules without bumping to v4?

talbright · 2019-01-02T04:15:46Z

Unfortunately v1, v2, ... in GO projects has a special meaning that doesn't seem to be related to the use case here (https://github.com/golang/go/wiki/Modules#semantic-import-versioning) and is causing some conflicts with the new module system.

I can work on a different approach but that may reduce compatibility. Is that a preferred tradeoff?

mars · 2019-01-03T00:18:10Z

Unfortunately v1, v2, ... in GO projects has a special meaning that doesn't seem to be related to the use case here

😬 wow that's a collision of intents for sure.

I always assumed that v3 indicated the Heroku API v3, but if it's conflated with Go import versioning, perhaps we should rename that troubled module path to version3 or api-v3 as part of this major change.

talbright · 2019-01-03T01:53:53Z

😬 wow that's a collision of intents for sure.

I always assumed that v3 indicated the Heroku API v3, but if it's conflated with Go import versioning, perhaps we should rename that troubled module path to version3 or api-v3 as part of this major change.

The main concern I have with doing that (or my preference -- flattening the directory structure), is breaking existing users. I would be less concerned if there had been releases/tagging.

What's the purpose of this pattern? Is it really needed? This client does not utilize variants, so it's always the official supported API "latest GA". Does Heroku (or has it ever) supported multiple GA versions of its platform API?

mars · 2019-01-04T18:40:04Z

Before merging any module system changes, let's definitely please 🙏 make a release containing the current "pre-go-modules" client.

I'm happy to go ahead with that, call it v1.0.0 to kick-off our semantic versioning, and clearly describe the release as the "Initial stable release before switching to the new Go 1.11 modules system".

fgblomqvist · 2019-01-29T18:39:16Z

Any update on this? Also, any recommended way of importing the package (as it currently is) into a go mod project?

Right now, the only way I can get working is to require github.com/heroku/heroku-go v0.0.0-20190103224148-ad17585a922f and then import github.com/heroku/heroku-go/v3 inside my code. Doesn't seem like the proper way. I tried doing a replace github.com/heroku/heroku-go => github.com/heroku/heroku-go/v3 latest which seemed to initially work (it would tag it as v3.0.0.....) but then it just complained about not finding a go.mod in the root or in the v3. But yeah, this is the first package I've dealt with that uses the directory structure-way of versioning it.

talbright · 2019-01-29T18:48:50Z

@fgblomqvist I'm waiting to here back from the team...

@alindeman @cyberdelia any thoughts? Happy to make changes to this PR if there's a preferred approach.

mars · 2019-03-27T17:55:45Z

I created our first release 🙀 v1.0.0.

We'll move forward with this likely breaking PR soon.

mars · 2019-03-28T20:44:15Z

Hey @talbright ,

~~Let's drop /v3 from the module path so usage becomes:~~

~~It will be a breaking change of course. We'll tag it as v2.0.0, and add an obvious Breaking Change notice to the README.~~

(See revision to plan in next comment.)

Does anything else need to happen to resolve the problem using this as a Go Module?

Let me know if you have time to work on this, or if it would be helpful for me to take it from here 😇

mars · 2019-03-28T21:18:11Z

Apparently I have not read enough Go Module documentation. (Thanks to friendly collaborators pointing this out.)

According to "Go Modules: Semantic Import Versioning" docs we don't have an option:

If the module is version v2 or higher, the major version of the module must be included as a /vN at the end of the module paths used in go.mod files (e.g., module github.com/my/mod/v2, require github.com/my/mod/v2 v2.0.0) and in the package import path (e.g., import "github.com/my/mod/v2/mypkg").

The current version will actually need to be tagged v3.0.0 (done), and the new Go Modules version will need its path to be changed to /v4 and tagged v4.0.0.

talbright · 2019-03-29T01:52:14Z

Hey @talbright ,

Let's drop /v3 from the module path so usage becomes:

It will be a breaking change of course. We'll tag it as v2.0.0, and add an obvious Breaking Change notice to the README.

(See revision to plan in next comment.)

Does anything else need to happen to resolve the problem using this as a Go Module?

Let me know if you have time to work on this, or if it would be helpful for me to take it from here 😇
I can follow through and finish up. There's some other nice changes for the build on the branch I want to make sure don't get lost as well.

I will review that doc again (its been a few months.) From what I recall though, if we aren't worried about breaking backwards compatibility we do have the option of dropping vN. I somewhat prefer this approach:

it removes the vN vestiges and naming convention for which I'm not a fan of
simplifies module support going forward
makes the code base easier to maintain

In the future if Heroku truly needs to maintain two separate versions of the API (the original reason the vN notation was used), likely the best thing to do is create a new project for it.

mars · 2019-03-29T05:44:08Z

Sounds great @talbright

talbright · 2019-04-21T02:42:21Z

@mars ready for review

mars · 2019-04-24T00:13:47Z

Nice @talbright! 🙌😄 I'll review and test how it works with the Terraform Provider next week.

mars

Thanks for your patience as I finally got to this. Just a few comments in-line.

Also, I opened a PR on the Terraform Provider that uses this branch:

validated that this Provider branch works correctly with Terraform, applying & destroying a simple configuration
currently running the full Provider test suite locally (will report back, but it's all success so far)

README.md

mars · 2019-05-03T00:14:11Z

.travis.yml

@@ -1 +1,7 @@
 language: go
+
+go:
+  - "1.9"


Are Go Modules backward-compatible? These CI versions might need some pruning.

Not exactly no. But vendoring is the magic that makes this work. Please see https://github.com/golang/go/wiki/Modules#how-do-i-use-vendoring-with-modules-is-vendoring-going-away for more details. Also note the matrix is building all these versions just fine so things seem to line up.

Co-Authored-By: talbright <[email protected]>

talbright · 2019-05-03T00:40:04Z

Thanks for your patience as I finally got to this. Just a few comments in-line.

No worries, this PR is just taking its time to germinate. We will get there.

Also, I opened a PR on the Terraform Provider that uses this branch:

* validated that this Provider branch works correctly with Terraform, applying & destroying a simple configuration

* currently running the full Provider test suite locally (will report back, but it's all success so far)

Awesome, thanks for doing this.

mars · 2019-05-03T16:14:42Z

✅ Hashicorp CI passed for the Terraform Provider on this branch.

talbright · 2019-05-03T16:23:52Z

w00t! BTW I don't have perms to merge...

mars · 2019-05-03T16:27:36Z

I'm releasing v4.0.0 now!

talbright changed the title ~~Go 1.11 module support~~ [WIP] Go 1.11 module support Dec 23, 2018

talbright changed the title ~~[WIP] Go 1.11 module support~~ Go 1.11 module support Dec 24, 2018

talbright force-pushed the mod-compat branch from cd35826 to 7b0dba9 Compare December 24, 2018 00:23

alindeman mentioned this pull request Jan 3, 2019

Regenerate based on latest schema #40

Merged

talbright force-pushed the mod-compat branch 2 times, most recently from e819a6c to 501330d Compare April 21, 2019 02:18

support for go modules

aad7698

talbright force-pushed the mod-compat branch from 16d40c2 to aad7698 Compare April 21, 2019 02:31

Update README.md

ae7fcfc

mars mentioned this pull request May 3, 2019

Upgrade to Go Modules-compatible Heroku client heroku/terraform-provider-heroku#195

Closed

mars requested changes May 3, 2019

View reviewed changes

Update README.md

9ac85d1

Co-Authored-By: talbright <[email protected]>

mars approved these changes May 3, 2019

View reviewed changes

mars merged commit 8096b47 into heroku:master May 3, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Go 1.11 module support #39

Go 1.11 module support #39

talbright commented Dec 23, 2018 •

edited

Loading

cyberdelia commented Dec 25, 2018

alindeman commented Dec 31, 2018

talbright commented Jan 2, 2019

mars commented Jan 3, 2019

talbright commented Jan 3, 2019

mars commented Jan 4, 2019

fgblomqvist commented Jan 29, 2019

talbright commented Jan 29, 2019

mars commented Mar 27, 2019

mars commented Mar 28, 2019 •

edited

Loading

mars commented Mar 28, 2019 •

edited

Loading

talbright commented Mar 29, 2019

mars commented Mar 29, 2019

talbright commented Apr 21, 2019

mars commented Apr 24, 2019

mars left a comment

mars May 3, 2019

talbright May 3, 2019 •

edited

Loading

talbright commented May 3, 2019 •

edited

Loading

mars commented May 3, 2019

talbright commented May 3, 2019

mars commented May 3, 2019

Go 1.11 module support #39

Go 1.11 module support #39

Conversation

talbright commented Dec 23, 2018 • edited Loading

cyberdelia commented Dec 25, 2018

alindeman commented Dec 31, 2018

talbright commented Jan 2, 2019

mars commented Jan 3, 2019

talbright commented Jan 3, 2019

mars commented Jan 4, 2019

fgblomqvist commented Jan 29, 2019

talbright commented Jan 29, 2019

mars commented Mar 27, 2019

mars commented Mar 28, 2019 • edited Loading

mars commented Mar 28, 2019 • edited Loading

talbright commented Mar 29, 2019

mars commented Mar 29, 2019

talbright commented Apr 21, 2019

mars commented Apr 24, 2019

mars left a comment

Choose a reason for hiding this comment

mars May 3, 2019

Choose a reason for hiding this comment

talbright May 3, 2019 • edited Loading

Choose a reason for hiding this comment

talbright commented May 3, 2019 • edited Loading

mars commented May 3, 2019

talbright commented May 3, 2019

mars commented May 3, 2019

talbright commented Dec 23, 2018 •

edited

Loading

mars commented Mar 28, 2019 •

edited

Loading

mars commented Mar 28, 2019 •

edited

Loading

talbright May 3, 2019 •

edited

Loading

talbright commented May 3, 2019 •

edited

Loading