On Tue, Mar 10, 2015 at 6:13 PM, roger peppe <[email protected]> wrote:
> On 10 March 2015 at 12:52, John Meinel <[email protected]> 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(). What I *really* don't understand is that if I'm at the top level and I do "go fmt" it shows: ~/jc $ go fmt ... stat ../dev/go/src/github.com/juju/juju/doc.go: no such file or directory ~/jc $ cd worker/uniter/filter ~/jc/worker/uniter/filter $ go fmt ... stat ../../../../dev/go/src/ github.com/juju/juju/worker/uniter/filter/filter.go: no such file or directory I really don't understand all the interactions with PWD or why it is trying to stat "../../../../". How does it know about dev/go/src/ github.com/juju/juju but then try to apply that to PWD? If you have go 1.4 it should be easy to test this. John =:->
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
