Remove GOPATH (breaking change for using wag outside of GOPATH) #423
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With this change, GOPATH is still used, but only at the top level (main.go) where it's used to determine the absolute path for output.
This is a breaking change: now the -output-path, if it's relative, is interpreted relative to current working directory. Previously, we would combine GOPATH with the module path in go.mod to guesstimate where to interpret it relative to.
taylor-sutton
force-pushed
the
remove-gopath-simple
branch
from
d16d27b
to
4f9c25e
Compare
taylor-sutton
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a merge request into the
v9.xdev branch, currently even withmasterbut this will be where it starts to diverge.This PR is split into two commits.
The first commit is fairly mechanical: the idea is to reduce any remaining uses of GOPATH to the top-level, rather than using it deeper into the generator. The deeper usage of GOPATH that needed to be eliminated is in the
Generatortype in ourswaggerpackage. Previously this struct was receiving a path that was interpreted relative to GOPATH, now it's receiving an absolute path.In addition, I tried to simplify a bit by removing the number of
*pathvariables. For example, in practice,modelsPathwas always{basePath}/models; yet at the same time, the assumption that models lived in that directory was hardcoded in other places, so that if we just changedmodelsPath, things would actually break.The second commit included a BREAKING CHANGE⚠️ 🔴 . This change was necessary to completely remove any dependence on GOPATH. Now the -output-path, if it's relative, is interpreted relative to current working directory. Previously, we would combine GOPATH with the module path in go.mod to guesstimate where to interpret it relative to.
This change is only sorta kinda breaking. If you were using
waginside${GOPATH}/src/path/to/packagealready, nothing changes for you. Using wag outside such a directory... was already kinda broken. So while this is a breaking change, it's really fixing things. Previously, if I ranwagin~/someDir(i.e. outside of GOPATH),wagwould put the generated files inside of GOPATH, which is basically never what you want.Testing
Running
make testnot only passes the test, it also results in literally zero diffs inside samples, meaning that this is not changing anything in the use cases we are about.I also tried running wag outside of GOPATH... and it actually worked! It produced generated files inside the working directory instead of randomly far away.
Merge Checklist
make buildmake generate/VERSIONfile - N/A, not trying to release yet.Closes #328