2

I have imported an app from github which has many imports, spread in several files like:

import (
    "log"
    "net/http"
    "github.com/johndoe/sleekrest/model"
    "github.com/johndoe/sleekrest/shared/passhash"
    "github.com/johndoe/sleekrest/shared/recaptcha"
    "github.com/johndoe/sleekrest/shared/session"
    "github.com/johndoe/sleekrest/shared/view"
    "github.com/johndoe/csrfbanana"
)

I want to work on the packages on my local path /go/src/myrest, so I'd like to have imports to be like 

import (
    "log"
    "net/http"
    "./model"
    "./shared/passhash"
    "./shared/recaptcha"
    "./shared/session"
    "./shared/view"
    "./csrfbanana"
)

I know I can use bash commands like sed, find, etc to replace the import paths, but I'm wondering if there is an idiomatic way to do so in golang?

Karlom
  • 13,323
  • 27
  • 72
  • 116
  • 4
    Do not use relative imports. Use a vendor directory, a vendoring tool, or rewrite the paths to their full import path. – JimB Apr 21 '16 at 00:41
  • Can you please elaborate why the relative paths are bad and how to use a vendoring tool to do so? – Karlom Apr 21 '16 at 01:13
  • 2
    Those packages ARE on your local path. What is the motivation for wanting to change the import paths? – elithrar Apr 21 '16 at 01:22
  • I don't like to go to 'github.com' folder to work on the code. – Karlom Apr 21 '16 at 01:31
  • 1
    Welcome to `Go`! Now, it's time to change your *like*s and don't fight the system: don't use relative paths and leave the import paths as-is. It's just the way Go works. Get a good IDE or VIM plugin that supports `goimports` and you'll be set. – eduncan911 Apr 21 '16 at 02:27
  • 1
    Just use `goimports` and never look at the import section in your source code again ;) – kostya Apr 21 '16 at 03:34

1 Answers1

2

There is not an idiomatic way to do this because relative import paths are not idiomatic Go.

Reasons to not use relative import paths

The following is from Organizing Go code:

An import path is the string with which users import a package. It specifies the directory (relative to $GOROOT/src/pkg or $GOPATH/src) in which the package's source code resides.

Sometimes people set GOPATH to the root of their source repository and put their packages in directories relative to the repository root, such as "src/my/package". On one hand, this keeps the import paths short ("my/package" instead of "github.com/me/project/my/package"), but on the other it breaks go get and forces users to re-set their GOPATH to use the package. Don't do this.

The following is from Command go:

Second, if you are compiling a Go program not in a work space, you can use a relative path in an import statement in that program to refer to nearby code also not in a work space. This makes it easy to experiment with small multipackage programs outside of the usual work spaces, but such programs cannot be installed with go install (there is no work space in which to install them), so they are rebuilt from scratch each time they are built. To avoid ambiguity, Go programs cannot use relative import paths within a work space.

Also, you might look at these StackOverflow answers:

Vendoring

Vendoring became an experimental feature in Go 1.5. As of Go 1.6, vendoring is no longer experimental. For more information on vendoring, see:

Community
  • 1
  • 1
Matthew Rankin
  • 457,139
  • 39
  • 126
  • 163
  • Can you please explain in concrete terms how should I use the vendoring? I looked at the docs but could not get my head around it. – Karlom Apr 22 '16 at 23:11
  • Check out the vendoring related questions that have already been asked on SO. If your question hasn't already been asked, feel free to ask a new vendoring related question. – Matthew Rankin Apr 25 '16 at 12:38