1

I am looking at the replace directive for go.mod:

https://thewebivore.com/using-replace-in-go-mod-to-point-to-your-local-module/

module github.com/pselle/foo

replace github.com/pselle/bar => /Users/pselle/Projects/bar

require (
    github.com/pselle/bar v1.0.0
)

when working in teams this is pretty dumb since the url is absolute and will break for any machine but your own.

Is there a way to use an env variable or relative path to designate the replace directive? Something like this:

replace github.com/pselle/bar => $GOPATH/src/github.com/pselle/bar

or

replace github.com/pselle/bar => ./github.com/pselle/bar

using the relative path is pretty horrible when PWD changes, an absolute path with an env var would be much better.

  • 1
    Do you absolutely need to commit go.mod including local path `replace` directives? Usually that's only used for local testing and isn't included when committing the file so other developers don't have to worry about how you've set it up on your machine. – Adrian May 14 '20 at 20:40
  • umm, you mean I would put go.mod in gitignore? If it's in version control it's not a lot of fun to add/remove the same line in a file over and over. NPM does this better by using symlinks. –  May 14 '20 at 21:08
  • @Alex I don't think @Adrian is suggesting that at all. `go.mod` with `replace` is usually for local development/testing (since the real repo does not exist or has a new method/type). Yes `go.mod` should be checked into git. But, no `replace` directives to local paths should probably be kept out of git. – colm.anseo May 15 '20 at 02:16

3 Answers3

3

This should answer your question:

https://stackoverflow.com/a/55534126/12834955

Env variables won't work, but you can use a relative path which is relative to a fixed location - the module's root. As you can see from the answer:

The path you specify for the replace directive must be either an absolute path or a relative path, relative to the module's root.

1

It's not possible right now. There was a proposal to introduce using directive to go.mod file, that would allow to reuse environment variables for replacements. But that proposal was rejected. As far as I know, there's no current plans to introduce easy solution to that problem.

Grigoriy Mikhalkin
  • 5,035
  • 1
  • 18
  • 36
0

If you are working with a team, how are your coordinating this new code across many developer machines?

Why not just check in this new code into git. Production build will still be version controlled via go.mod and your semver tags. You can tag this devel pushes. Or you can always pull @master to get the latest. All developers can work off this common code without breaking production. And when ready for release, tag the next working commit & update go.mod's semver tag.

colm.anseo
  • 19,337
  • 4
  • 43
  • 52