File names in error messages should show absolute or relative path about gb

[davecheney]

@fatih I agree and I'll do this. At the moment the error message are without a path because the build is compiled with the working directory set to the src directory of the package.

As a simplistic fix, always executing the build from a single location will give more inspectable error message.

I'd like to avoid making the paths absolute initially, I'd rather everything was relative to $PROJECT or $PROJECT/src/. @fatih, do you have any preferences ?

[ukiahsmith]

I feel that file paths in messages should be relative to $PROJECT.

gb is all about thinking in terms of projects. This should be reflected in how it communicates with users.

[davecheney]

There is a small inconsistency that you ask for a package to be built by
its import path, but the error message will have src/ stuck on the front. I
think this I'd manageable, and preferable to making the paths relative to
$PROJECT/src/ as it makes it more complicated if the error is in a vendored
package.

On Sat, 9 May 2015 13:02 Ukiah Supermighty Smith [email protected]
wrote:

I feel that file paths in messages should be relative to $PROJECT.

gb is all about thinking in terms of projects. This should be reflected
in how it communicates with users.

—
Reply to this email directly or view it on GitHub
#57 (comment).

[ukiahsmith]

What are other things that would be affected by this decision? Tooling? Copy/Paste from terminal? How does the choice of path make life easier or harder to be a drop-in replacement for the go tool?

[davecheney]

If it makes it easier for @fatih to integrate gb I to go-vim, I can only
see this as a positive for other tools that want to integrate.

On Sat, 9 May 2015 13:13 Ukiah Supermighty Smith [email protected]
wrote:

What are other things that would be affected by this decision? Tooling?
Copy/Paste from terminal? How does the choice of path make life easier or
harder to be a drop-in replacement for the go tool?

—
Reply to this email directly or view it on GitHub
#57 (comment).

[fatih]

@fatih I agree and I'll do this. At the moment the error message are without a path because the build is compiled with the working directory set to the src directory of the package.

Thanks a lot @davecheney, this will make it easier to integrate gb with editors.

As a simplistic fix, always executing the build from a single location will give more inspectable error message.

Right. I was executing gb build in the root folder. To test how the path is printed I've introduced an error in a new subfolder: github.com/fatih/color/subcolor. The error was in the form:

subcolor.go:5: non-declaration statement outside function body

However there is no context here, does the file belong to github.com/fatih/color or github.com/fatih/color/subcolor? (Correct answer is the latter one). So here gb build evaluated in the root folder. But of course in the editor, the build will be always from within the source code's location (github.com/fatih/color)

I'd like to avoid making the paths absolute initially, I'd rather everything was relative to $PROJECT or $PROJECT/src/. @fatih, do you have any preferences ?

Relative is imho a good choice to go (because it's the same with the go tools). Because it's relative, it doesn't matter exactly from where it's called right? For example this is how go build is acting:

fatih git:master ❯ pwd
/Users/fatih/Code/koding/go/src/github.com/fatih
fatih git:master ❯ go build ./color
# github.com/fatih/color
color/color.go:79: undefined: a
fatih git:master ❯ cd color
color git:master ❯ go build
# github.com/fatih/color
./color.go:79: undefined: a
color git:master ❯ cd foo/bar
bar git:master ❯ pwd
/Users/fatih/Code/koding/go/src/github.com/fatih/color/foo/bar
bar git:master ❯ go build ../../.
# github.com/fatih/color
../../color.go:79: undefined: a

For example some users have a autocmd in their vimrc, which is automatically joining the directory of the current buffer's location. However some are in a completely different location but are working on the same buffer. In vim-go, what I do is, regardless of the user's directory, I enter into the current buffer's directory and execute go build. This makes things very easy for me, because as seen above I'll get always the correct path.

Now for gb, I can do the same but as reported in my first reply, it's printing differently. Here is an example:

The error is in the github.com/fatih/color/subcolor package obviously, but I don't have any context to the file name.

[davecheney]

Got it, fix coming soon.

On 10 May 2015, at 06:11, Fatih Arslan [email protected] wrote:

@fatih I agree and I'll do this. At the moment the error message are without a path because the build is compiled with the working directory set to the src directory of the package.

Thanks a lot @davecheney, this will make it easier to integrate gb with editors.

As a simplistic fix, always executing the build from a single location will give more inspectable error message.

Right. I was executing gb build in the root folder. To test how the path is printed I've introduced an error in a new subfolder: github.com/fatih/color/subcolor. The error was in the form:

subcolor.go:78: c evaluated but not used

However there is no context here, does the file belong to github.com/fatih/color or github.com/fatih/color/subcolor? (Correct answer is the latter one). So here gb build evaluated in the root folder. But of course in the editor, the build will be always from within the source code's location (github.com/fatih/color)

I'd like to avoid making the paths absolute initially, I'd rather everything was relative to $PROJECT or $PROJECT/src/. @fatih, do you have any preferences ?

Relative is imho a good choice to go (because it's the same with the go tools). Because it's relative, it doesn't matter exactly from where it's called right? For example this is how go build is acting:

fatih git:master ❯ pwd
/Users/fatih/Code/koding/go/src/github.com/fatih
fatih git:master ❯ go build ./color

github.com/fatih/color

color/color.go:79: undefined: a
fatih git:master ❯ cd color
color git:master ❯ go build

github.com/fatih/color

./color.go:79: undefined: a
color git:master ❯ cd foo/bar
bar git:master ❯ pwd
/Users/fatih/Code/koding/go/src/github.com/fatih/color/foo/bar
bar git:master ❯ go build ../../.

github.com/fatih/color

../../color.go:79: undefined: a

For example some users have a autocmd in their vimrc, which is automatically joining the directory of the current buffer's location. However some are in a completely different location but are working on the same buffer. In vim-go, what I do is, regardless of the user's directory, I enter into the current buffer's directory and execute go build. This makes things very easy for me, because as seen above I'll get always the correct path.

Now for gb, I can do the same but as reported in my first reply, it's printing differently. Here is an example:

The error is in the github.com/fatih/color/subcolor package obviously, but I don't have any context to the file name.

—
Reply to this email directly or view it on GitHub.