Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add mod #58

Closed
wants to merge 2 commits into from
Closed

Add mod #58

wants to merge 2 commits into from

Conversation

jeanbza
Copy link
Contributor

@jeanbza jeanbza commented Nov 8, 2018 •
edited
Loading

I'm still vetting this change, but I thought I'd send it out now to start getting early feedback. I figure it's better to know sooner than later if this seems like a very wrong road to go down. :)

Note that this change has a reliance on google-cloud-go for the same reason as is discussed here.

Commit message:

    all: enable modules

    This adds a go.mod and go.sum file to gax.

    Unfortunately, gax-go already has a v2.0.0 tag. So, 
    per [1] we create a v2/ subdirectory, copy all the v1
    code, and create a v2 go.mod in the subdirectory.
    Then, after this is merged, the commit will be tagged
    as v1.0.1 as well as v2.0.1. This is a combination of
    the "Major Branch" and the "Major Subdirectory"
    approaches mentioned in [1].

    However, there's one more complication: users are
    directly exposed to exported types in this package
    such as CallOption. google-cloud-go will rely on v2
    of gax, but a user's codebase is still going to have
    the non-v2/ gax import paths.

    We could:

    - Make google-cloud-go rely on v2 and simultaneously
    create a v2 of google-cloud-go. All existing users of
    google-cloud-go continue using v1 of gax and v1 of
    google-cloud-go. All folks migrating to v2 of
    google-cloud-go must go update their gax import paths
    to use /v2. (this is obviously infeasible)
    - Make all gax v1 types aliases of gax v2 types, and
    all v1 functions shadows of v2 functions. That way,
    google-cloud-go can rely on v2 but a user can pass
    either a v1 or v2 gax type.

    1: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Nov 8, 2018
@jeanbza jeanbza requested review from pongad, jba, enocom and broady November 8, 2018 01:25
@jeanbza
all: enable modules
5198651 
This adds a go.mod and go.sum file to gax.

Unfortunately, gax-go already has a v2.0.0 tag. This
means that the module must be a v2 module. So, per
[1] we create a v2/ subdirectory, copy all the v1 code
there, and mark the go.mod module declaration with
/v2.

However, there's one more complication: users are
directly exposed to exported types in this package
such as CallOption. google-cloud-go will rely on v2
of gax, but a user's codebase is still going to have
the non-v2/ gax import paths.

We could:

- Make google-cloud-go rely on v2 and simultaneously
create a v2 of google-cloud-go. All existing users of
google-cloud-go continue using v1 of gax and v1 of
google-cloud-go. All folks migrating to v2 of
google-cloud-go must go update their gax import paths
to use /v2. (this is obviously infeasible)
- Make all gax v1 types aliases of gax v2 types, and
all v1 functions shadows of v2 functions. That way,
google-cloud-go can rely on v2 but a user can pass
either a v1 or v2 gax type.

This change will be tagged as v1.0.1 as well as
v2.0.1. The versions v1.0.0 and v2.0.0 will be unusable.

1: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
pongad
pongad reviewed Nov 8, 2018
View reviewed changes
go.mod Outdated Show resolved Hide resolved
pongad
pongad approved these changes Nov 8, 2018
View reviewed changes
go.mod
@@ -0,0 +1,3 @@
module github.com/googleapis/gax-go

require google.golang.org/grpc v1.16.0

This comment was marked as spam.

Sign in to view

This comment was marked as spam.

Sign in to view

jeanbza added a commit to jeanbza/gax-go that referenced this pull request Nov 9, 2018
@jeanbza
ax: add v2 directory
c2b5338 
This commit was generated by copying the contents of the parent directory into
the v2 directory.

This commit supercedes googleapis#58 and is one
of two in a series of commits to add Go module support to gax.

Unfortunately, gax-go already has a v2.0.0 tag. So, per [1] we create a v2/
subdirectory, copy all the v1 code, and create a v2 go.mod in the subdirectory.
Then, after this commit is merged, the commit will be tagged v2.0.1. This is a
combination of the "Major Branch" and the "Major Subdirectory" approaches
mentioned in [1].

1: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
@jeanbza jeanbza mentioned this pull request Nov 9, 2018
Merged
jeanbza added a commit to jeanbza/gax-go that referenced this pull request Nov 9, 2018
@jeanbza
add v2 directory
5cfc149 
This commit was generated by copying the contents of the parent directory into
the v2 directory.

This commit supercedes googleapis#58 and is one
of two in a series of commits to add Go module support to gax.

Unfortunately, gax-go already has a v2.0.0 tag. So, per [1] we create a v2/
subdirectory, copy all the v1 code, and create a v2 go.mod in the subdirectory.
Then, after this commit is merged, the commit will be tagged v2.0.1. This is a
combination of the "Major Branch" and the "Major Subdirectory" approaches
mentioned in [1].

1: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
@jeanbza
Copy link
Contributor Author

jeanbza commented Nov 9, 2018

Unfortunately it turns out we can't do this atomically. In order for v1 to depend on v2, v2 has to already have been committed, pushed, and tagged. Only then will go mod tidy be able to look for v2, check github, see v2, and add the require dependency. This song-and-dance is a well-known nuisance and is discussed in golang/go#27056 (and several other issues).

I'm breaking this PR into two PRs:

  • Add v2 (then tag)
  • Make v1 shallow alias of v2 (then tag)

The first of which is here: #59.

@jeanbza jeanbza closed this Nov 9, 2018
@pongad
Copy link
Contributor

pongad commented Nov 9, 2018

Oh..that makes so much sense 😆

jeanbza added a commit that referenced this pull request Nov 13, 2018
@jeanbza
add v2 directory (#59)
9c40fc3 
add v2 directory

This commit was generated by copying the contents of the parent directory into
the v2 directory.

This commit supercedes #58 and is one
of two in a series of commits to add Go module support to gax.

Unfortunately, gax-go already has a v2.0.0 tag. So, per [1] we create a v2/
subdirectory, copy all the v1 code, and create a v2 go.mod in the subdirectory.
Then, after this commit is merged, the commit will be tagged v2.0.1. This is a
combination of the "Major Branch" and the "Major Subdirectory" approaches
mentioned in [1].

1: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
jeanbza added a commit to jeanbza/gax-go that referenced this pull request Nov 13, 2018
@jeanbza
make v1 a type alias of v2
e4b1c56 
This commit supercedes googleapis#58 and follows googleapis#59, and is the second of two in a
series of commits to add Go module support to gax.

This commit makes v1 code type aliases of v2 code. This commit will be tagged
v1.0.1.

Reasoning for making type aliases:

Users are directly exposed to exported types in this package such as
CallOption. google-cloud-go will rely on v2 of gax, but a user's codebase is
still going to have the non-v2/ gax import paths.

We could:

- Make google-cloud-go rely on v2 and simultaneously create a v2 of
google-cloud-go. All existing users of google-cloud-go continue using v1 of
gax and v1 of google-cloud-go. All folks migrating to v2 of google-cloud-go
must go update their gax import paths to use /v2. (this is obviously
infeasible)
- Make all gax v1 types aliases of gax v2 types, and all v1 functions shadows
of v2 functions. That way, google-cloud-go can rely on v2 but a user can pass
either a v1 or v2 gax type.
@jeanbza jeanbza mentioned this pull request Nov 13, 2018
Merged
jeanbza added a commit that referenced this pull request Nov 16, 2018
@jeanbza
make v1 a type alias of v2, add go.mod (#61)
d5fa34d 
* make v1 a type alias of v2

This commit supercedes #58 and follows #59, and is the second of two in a
series of commits to add Go module support to gax.

This commit makes v1 code type aliases of v2 code. This commit will be tagged
v1.0.1.

Reasoning for making type aliases:

Users are directly exposed to exported types in this package such as
CallOption. google-cloud-go will rely on v2 of gax, but a user's codebase is
still going to have the non-v2/ gax import paths.

We could:

- Make google-cloud-go rely on v2 and simultaneously create a v2 of
google-cloud-go. All existing users of google-cloud-go continue using v1 of
gax and v1 of google-cloud-go. All folks migrating to v2 of google-cloud-go
must go update their gax import paths to use /v2. (this is obviously
infeasible)
- Make all gax v1 types aliases of gax v2 types, and all v1 functions shadows
of v2 functions. That way, google-cloud-go can rely on v2 but a user can pass
either a v1 or v2 gax type.

* add missing newline

* Add go.mod
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@pongad pongad pongad approved these changes

@jba jba Awaiting requested review from jba

@enocom enocom Awaiting requested review from enocom

@broady broady Awaiting requested review from broady

Assignees
No one assigned
Labels
cla: yes This human has signed the Contributor License Agreement.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@jeanbza @pongad @jba @googlebot