What to do about go fmt 1.4 ?
John Meinel
john at arbash-meinel.com
Thu Mar 12 05:06:44 UTC 2015
Right, its only go fmt that fails. "go build" and "go install" work, though
if there is a bug in your code they give you the wrong path to the code.
Sorry I wasn't clear on that.
It isn't that they fail to find the code, but they fail to give you the
right pointer to the code with the bug.
John
=:->
On Thu, Mar 12, 2015 at 6:00 AM, Andrew Wilkins <
andrew.wilkins at canonical.com> wrote:
> On Wed, Mar 11, 2015 at 8:55 PM, roger peppe <roger.peppe at canonical.com>
> wrote:
>
>> On 11 March 2015 at 06:52, John Meinel <john at arbash-meinel.com> wrote:
>> >
>> >
>> > On Tue, Mar 10, 2015 at 6:13 PM, roger peppe <roger.peppe at canonical.com
>> >
>> > wrote:
>> >>
>> >> On 10 March 2015 at 12:52, John Meinel <john at arbash-meinel.com> wrote:
>> >> > So there are 2 changes that I encountered with upgrading go to 1.4.2:
>> >> >
>> >> > 1) They changed how they sort import paths. Currently all our imports
>> >> > are:
>> >> >
>> >> > "github.com/juju/juju/bar"
>> >> > coretesting "github.com/juju/juju/testing"
>> >> > (sorted by the import string)
>> >> >
>> >> > It wants to sort them as:
>> >> >
>> >> > coretesting "github.com/juju/juju/testing"
>> >> > "github.com/juju/juju/bar"
>> >> >
>> >> > (sorted by the local name)
>> >>
>> >> Are you sure about this? I believe that play.golang.org
>> >> is running go 1.4 and this code is canonically formatted there,
>> >> despite unordered local names: http://play.golang.org/p/5R8dyHJG5e
>> >>
>> >
>> > Yeah, I was wrong here. It had moved a line I hadn't changed, and I was
>> > confused, but it was user error, not the tool.
>> >
>> >
>> >>
>> >> > 2) It no longer works if you have a symlink in your PWD
>> >> > Because of the need for exact paths, I have a link from $HOME/jc =>
>> >> > $HOME/dev/go/src/github.com/juju/juju
>> >> > However, if I do "go fmt" it now complains that:
>> >> > stat ../../../dev/go/src/
>> github.com/juju/juju/worker/uniter/deployer.go:
>> >> > no
>> >> > such file or directory
>> >> >
>> >> > (it seems to be using pwd -P and then using relative paths to that)
>> >> >
>> >> > Anyone know why it would need to do that?
>> >> >
>> >> > I can work around it with "cd jc; cd `pwd -P`" or some other form so
>> I
>> >> > don't
>> >> > have to type the long form each time.
>> >>
>> >> Can you show a step-by-step way to reproduce this please?
>> >> If you cd into jc, surely you are now in
>> >> $HOME/dev/go/src/github.com/juju/juju,
>> >> and I don't see how that's a problem. (but I've not seen the pwd -P
>> flag
>> >> before and don't understand how that works either - how can the pwd
>> >> command know what symlinks were used to get to the current working
>> >> directory?)
>> >>
>> >> cheers,
>> >> rog.
>> >
>> >
>> > So if I do:
>> >
>> > $ cd $HOME
>> > $ mkdir $HOME/dev/foo
>> > $ ln -s $HOME/dev/foo bar
>> > $ cd bar
>> > $ echo $PWD
>> > /home/jameinel/bar
>> > $ pwd
>> > /home/jameinel/bar
>> > $ pwd -P
>> > /home/jameinel/dev/foo
>> >
>> > So Bash sets $PWD based on what you actually issued to "cd".
>> > If I write this go code:
>> >
>> > package main
>> >
>> > import (
>> > "os"
>> > "fmt"
>> > "path/filepath"
>> > )
>> >
>> > func main() {
>> > dir, _ := os.Getwd()
>> > fmt.Printf("dir: %s\n", dir)
>> > pwd := os.Getenv("PWD")
>> > fmt.Printf("PWD: %s\n", pwd)
>> > expand, _ := filepath.EvalSymlinks(pwd)
>> > fmt.Printf("expanded: %s\n", expand)
>> > }
>> >
>> >
>> > I get:
>> >
>> > dir: /home/jameinel/dev/foo
>> > PWD: /home/jameinel/bar
>> > expanded: /home/jameinel/dev/foo
>> >
>> > So it would seem that "go fmt" is using os.Getenv("PWD") or some variant
>> > instead of using os.Getwd().
>>
>> OK, having looked at the pwd source and os.Getwd, I understand
>> more of the issue now. os.Getwd uses os.Getenv("PWD") to find
>> an alternative reachable current directory path. I had no
>> idea about this hack - it's useful to know about. That said, os.Getwd
>> has been like this since go1.0, so that at least hasn't changed recently.
>>
>> I can't reproduce your issue.
>>
>> $ ls -l ~/jc
>> lrwxrwxrwx 1 rog rog 41 Mar 11 12:44 /home/rog/jc ->
>> /home/rog/src/go/src/github.com/juju/juju
>> $ cd ~/jc/worker/uniter
>> $ pwd
>> /home/rog/jc/worker/uniter
>> $ GOROOT=~/go1.4 PATH=~/go1.4/bin:$PATH
>> $ go version
>> go version go1.4.1 linux/amd64
>> $ rm -r $GOPATH/pkg
>> $ go install
>> $ env | grep PWD
>> OLDPWD=/home/rog/jc/worker/uniter/relation
>> PWD=/home/rog/jc/worker/uniter
>> $
>>
>> Do you see an error in the above example?
>> It would be nice to have a complete script that demonstrates the
>> problem you're having.
>
>
> I get the same thing as John, but only with "go fmt". go build|install
> work fine for me in a symlinked path.
>
> Do all shells evaluate paths relative to symlinks the same way? what is
> the output of "ls ~/jc/.."
>
> Seems that "relPaths" in cmd/go/build.go ought to EvalSymlinks the result
> of os.Getwd.
>
> cheers,
>> rog.
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150312/763bdb31/attachment.html>
More information about the Juju-dev
mailing list