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

samples: make samples its own module #2048

Closed
eliben opened this issue May 10, 2019 · 1 comment
Closed

samples: make samples its own module #2048

eliben opened this issue May 10, 2019 · 1 comment
Assignees
@eliben
Labels
process Improvement to the engineering process

Comments

@eliben
Copy link
Member

eliben commented May 10, 2019

We currently have samples/appengine as a separate module.

We should instead make samples/ a module, with all the samples just commands within that module. This will be needed as part of #886, since samples import all our providers and thus can't be part of the core module (if we want to not force some providers as dependencies on users of core)
@eliben eliben added the process Improvement to the engineering process label May 10, 2019
@eliben eliben self-assigned this May 13, 2019
@eliben eliben mentioned this issue May 13, 2019
Merged
eliben added a commit that referenced this issue May 13, 2019
@eliben
samples: move go.mod into samples root, making samples its own module (…
714b3ed 
…#2057)

Updates #2048 - moves the go.mod file from samples/appengine to samples.

Note the replace gocloud.dev => ../ added to the go.mod. Without this, running go test ./... in samples/ results in many errors like:

can't load package: package gocloud.dev/samples/server: unknown import path "gocloud.dev/samples/server": ambiguous import: found gocloud.dev/samples/server in multiple modules:
	gocloud.dev/samples (/home/eliben/eli/go-cloud/samples/server)
	gocloud.dev v0.13.0 (/home/eliben/eli/go/pkg/mod/gocloud.dev@v0.13.0/samples/server)

The symptom and solution is explained by bcmills in ugorji/go#279 (which refers also to golang/go#27899). The new go.mod points to gocloud.dev v0.13, which also provides these packages - so the go command is confused - it sees the same package(s) provided by two different modules.

The ugorji/go solution was to use a pseudo-version pointing at an existing commit in the core module which removes the packages - this removes the ambiguity. In our case, there is no existing commit yet - so I'm using a replace line. The replace line should be unnecessary when we release a new CDK version.

This has interesting implications for #886 - we'll likely have to do the same when we split out providers to their own modules and retain replace lines until a new release.
@eliben
Copy link
Member Author

eliben commented May 14, 2019

Fixed by #2057

@eliben eliben closed this as completed May 14, 2019
zombiezen pushed a commit that referenced this issue May 14, 2019
@eliben @zombiezen
gocloud.code-workspace: update with new location of samples module (#…
b8f20f0 
…2076)

Updates #2048
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@eliben eliben

Labels
process Improvement to the engineering process
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@eliben