search

bazelbuild / rules_go

Go rules for Bazel
Apache License 2.0
1.37k stars 651 forks source link

repo import path prefix for source code from go_rule/go_context? #2205

Open jmhodges opened 5 years ago

jmhodges commented 5 years ago

This is with HEAD and bazel 0.28.1.

bazel_gomock with the source parameter (which is the set to the target of a specific file in a user's project) is no longer working. It seems that where, previously, the source code for your project would be at gopath + ctx.file.source.path, it's now at gopath + repo_prefix + ctx.file.source.path (where repo_prefix seems to be the import path of the prefix?)

I couldn't find the repo prefix (import path, whatever) in the GoContext API. Where is it at?

jmhodges commented 5 years ago

Relevant code in bazel_gomock: https://github.com/jmhodges/bazel_gomock/blob/master/gomock.bzl#L9-L12

jmhodges commented 5 years ago

I guess a more general question is: how do we translate a random source file that we know is in a given GoLibrary into its go_path equivalent (in order to avoid go module network connections)?

(The patch to avoid that go module network stuff was given to me by another user, so perhaps the real general question is there a way for rules_go to help us out with avoiding go module related network connections?)

jmhodges commented 5 years ago

Hm, I hacked this up with

 args = ["-source", gopath + "/src/" + ctx.attr.library[GoLibrary].importmap + "/"+ ctx.file.source.basename]

I think that basename call will work consistently because of how gopath would require the source code to be immediately in the same directory as its importmap.

jayconrod commented 5 years ago

So if I understand correctly, you have a GoPath, a GoLibrary, and a source file, and you need to know the path of the file within the directory constructed by go_path?

Your last comment looks correct based on how go_path works today. It's unfortunate that importmap needs to be used instead of importpath -- I think that was needed to accomodate multiple vendored copies of the same package, though it's been a long time since I looked through that code.

jmhodges commented 4 years ago

Ah, I never answered here.

I was thinking that, yep, I needed the source path inside of gopath in order to avoid various tools from complaining about working outside of GOPATH