Perhaps just for completeness here, the replace directive is almost certainly what you want when it comes to unpublished modules. This will allow you to refer to a remote module as if it were published, even though it resides on a local disk.
See go help mod edit for more details (or alternatively https://tip.golang.org/cmd/go/#hdr-Edit_go_mod_from_tools_or_scripts) The one open issue to bear in mind however is https://github.com/golang/go/issues/26241 On Sat, 15 Sep 2018 at 17:07, K Davidson <kdev...@gmail.com> wrote: > > Well, my embarrassingly incorrect assumption came about from a package I was > writing recently; I was using the go mod tool to initialize my go.mod rather > than writing the file myself, and as an import statement I first tried using > the local filepath, which of coarse didn't work. Then I tried things like: > "." (yielding error: unknown import path "_/home/k/code/go/delete": internal > error: module loader did not resolve import" upon build (but it let me > initialize the module without issue). What finally did work, was when I used > a GitHub repo URL that I created only for this purpose, which is what > ultimately brought about my assumption. It never occurred to me to use a > fictitious import path because, well, there is nothing there. > > So it was my mistake (*egg on my face ¯\_(ツ)_/¯) > > But thx for the replies. > > -K > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
