What to do about go fmt 1.4 ?

[Andrew Wilkins]

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/572b01e5/attachment.html>