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.

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

cmd/go: support ~ in replace statements #33586

Open
FiloSottile opened this issue Aug 11, 2019 · 7 comments

Comments

@FiloSottile
Copy link
Member

commented Aug 11, 2019

I share some directories between machines with different user names. It would be useful to be able to add a statement like the following to a go.mod.

replace golang.org/x/net => ~/src/golang.org/x/net
@robpike

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2019

Does the file support $HOME? Because ~ is some modern aberration (says the old grump).

@FiloSottile

This comment has been minimized.

Copy link
Member Author

commented Aug 12, 2019

It doesn't support $HOME either. I suggested ~ because $HOME would likely be the only expansion available, but I don't have a strong opinion between the two.

@cuonglm

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2019

@FiloSottile I think adding this feature will be more complicated than we usually thought, I invite you to read https://unix.stackexchange.com/q/146671/38906

@robpike

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2019

I also think it's a slippery slope to start putting expressions that must be evaluated into module specification.

@dmitshur dmitshur added this to the Go1.14 milestone Aug 12, 2019

@bcmills

This comment has been minimized.

Copy link
Member

commented Aug 12, 2019

@cuonglm, I think the natural meaning of ~/ in a Go-specific configuration file is os.UserHomeDir(), which is hopefully not ambiguous.

@ianthehat

This comment has been minimized.

Copy link

commented Aug 12, 2019

If you are going to do anything at all I think it should be to call os.ExpandEnv, but my vote would be to do nothing.
The idea of a checked in module line that varies its behavior depending on which machine it is checked out on sends chills down my spine.

@bcmills

This comment has been minimized.

Copy link
Member

commented Aug 12, 2019

I tend to agree with @ianthehat and @robpike on this. Relative paths are one thing, since there is a pretty solid use-case for pointing a replace directive into the same repository. And absolute paths are probably necessary for tool-driven edits (like CI scripts that inject replace directives). But I don't see a strong use-case for variable absolute paths.

See previously #27824.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.