New import paths for Go sub-respositories

[Andrew Gerrand]

Summary: The sub-repo import paths are changing from "code.google.com/p/go.*" to "golang.org/x/*". Please update your code on or before November 9.

As a prelude to the Go 1.4 release, the Go sub-repositories (go.tools, go.net, go.crypto, and so on) will be made available using custom import paths. See golang.org/s/go14subrepo for background.

This list shows the current base import paths, and their new equivalents.

code.google.com/p/go.benchmarks -> golang.org/x/benchmarks

code.google.com/p/go.blog -> golang.org/x/blog

code.google.com/p/go.crypto -> golang.org/x/crypto

code.google.com/p/go.exp -> golang.org/x/exp

code.google.com/p/go.image -> golang.org/x/image

code.google.com/p/go.mobile -> golang.org/x/mobile

code.google.com/p/go.net -> golang.org/x/net

code.google.com/p/go.sys -> golang.org/x/sys

code.google.com/p/go.talks -> golang.org/x/talks

code.google.com/p/go.text -> golang.org/x/text

code.google.com/p/go.tools -> golang.org/x/tools

The "x" in the path serves to disambiguate these external packages from the standard library.

If your code imports packages from these repositories, please prepare changes to update the import paths, and commit those changes either before or shortly after the official repositories are renamed. (These new import paths work today, but the code in those repositories has not yet been updated to use them.)

The change will be made on Sunday, November 9, 2014.

Updating

Any import path in any Go source file beginning with “code.google.com/p/go.” should change to begin with “golang.org/x/”.

On Linux, OS X, and other Unix systems, this command updates all Go source files in the current directory and all subdirectories, so running it in your GOPATH workspace root should suffice to update all your source code:

    sed -i .orig 's|"code\.google\.com/p/go\.|"golang.org/x/|' \

        $(find . -name '*.go')

Potential issues

After the change, code that uses the old import paths will not break. Instead, two copies of a given repository may be created inside your workspace.

For example, the "code.google.com/p/go.tools/go/ssa" package depends on "code.google.com/p/go.tools/go/types". After the change, these two paths will become "golang.org/x/tools/go/ssa" and "golang.org/x/tools/go/types", and the import statement in package ssa will be updated accordingly.

If your code imports the ssa package using its old path, when the import paths are changed the dependency graph will look like this:

your package -> "code.google.com/p/go.tools/go/ssa" -> "golang.org/x/tools/go/types"

If you run "go get", it will check out two copies of the go.tools repository: one under the old path, and one under the new path. If your program also contains references to "code.google.com/p/go.tools/go/types", you will end up with both copies of the go/types package (with different import paths) in the same executable.

To fix this, update the import statements in your code to use the new paths and then delete the old "src/code.google.com/p/go.*" directories from your workspace.

[Sebastien Douche]

On Wed, Nov 5, 2014 at 10:50 PM, Andrew Gerrand <a...@golang.org> wrote:

Hi Andrew,

> code.google.com/p/go.benchmarks -> golang.org/x/benchmarks
> code.google.com/p/go.blog -> golang.org/x/blog
> code.google.com/p/go.crypto -> golang.org/x/crypto
> code.google.com/p/go.exp -> golang.org/x/exp
> code.google.com/p/go.image -> golang.org/x/image
> code.google.com/p/go.mobile -> golang.org/x/mobile
> code.google.com/p/go.net -> golang.org/x/net
> code.google.com/p/go.sys -> golang.org/x/sys
> code.google.com/p/go.talks -> golang.org/x/talks
> code.google.com/p/go.text -> golang.org/x/text
> code.google.com/p/go.tools -> golang.org/x/tools
>
> The "x" in the path serves to disambiguate these external packages from the
> standard library.

Why 'x' and not a explicit name like 'ext' (or 'external')?


--
Sebastien Douche <sdo...@gmail.com>
Twitter: @sdouche / G+: +sdouche

[Andrew Gerrand]

A more explicit name would be helpful the first time you read it, but after that it would only take up space and be longer to type.

Incidentally, you can use these new import paths as URsLs to see the package documentation: http://golang.org/x/net/html

Andrew

[mattn]

code.google.com/p/go.net seems return unexpected fingerprint.

[Alex Sergeyev]

Why not to use old gofix for that?  

    sed -i .orig 's|"code\.google\.com/p/go\.|"golang.org/x/|' \

        $(find . -name '*.go')

 Also probably somehow godoc.org could publish warnings for some packages when someone browses doc of package with old importsh....

[Andrew Gerrand]

On Thu Nov 06 2014 at 11:39:42 AM Alex Sergeyev <a...@alexsergeyev.com> wrote:

Why not to use old gofix for that?  

It's a bootstrapping issue.

The go fix tool is part of the core distribution, so the path rewrite fix would not be available until Go 1.4.

But we need to update the import paths before 1.4, as the go tool must be updated to know about the new import paths (it has special cases for cover, vet, and godoc). If we issued a release candidate before updating the import paths, then the release candidate would be broken.

Fortunately the fix is trivial. The sed command works reliably in my testing. 

 

 Also probably somehow godoc.org could publish warnings for some packages when someone browses doc of package with old importsh....

godoc.org will be updated to redirect from the old paths to the new ones.

 

Andrew

[walu]

oh，why golang.org/x/** only supports hg, not git???!!!

[Andrew Gerrand]

Because they are Mercurial repositories. That's what we use to develop Go.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Walu Zhang]

​ok, i kown.

but they, like context, supported git before, and we use git getting them.

so, i think the meta infomation(go-get=1) show return multiple repos with git\svn\ Mercurial toggether for important repos and the "go get" should support it .

--

---------

Hi, I'm walu

http://weibo.com/walu

http://www.walu.cc

[Andrew Gerrand]

Conceptually, it would be very strange if a single import path could be backed by multiple version control systems. That would add another dimension to the entire version management issue, which seems best avoided IMO.

What do you mean "they supported git before"? The sub-repos have always been backed by Mercurial repositories.

Andrew

[Walu Zhang]

oh, forgive my mistake.

there is hg in my self computer 

[Matt Sherman]

Looks like this may be causing some trouble in either types or gcimporter, relating to paths. The following:

go get code.google.com/p/go.tools/go/gcimporter

Returns:

# code.google.com/p/go.tools/go/gcimporter

code.google.com/p/go.tools/go/gcimporter/gcimporter.go:817: cannot use val (type "golang.org/x/tools/go/exact".Value) as type "code.google.com/p/go.tools/go/exact".Value in argument to types.NewConst:

"golang.org/x/tools/go/exact".Value does not implement "code.google.com/p/go.tools/go/exact".Value (wrong type for Kind method)

have Kind() "golang.org/x/tools/go/exact".Kind

want Kind() "code.google.com/p/go.tools/go/exact".Kind

(I've cleared out my /pkg directory to be sure.)

[Andrew Gerrand]

You need to move your local go.tools repo to its new location:

  mkdir $GOPATH/src/golang.org/x/

  mv $GOPATH/src/code.google.com/p/go.tools $GOPATH/src/golang.org/x/tools

and, instead of the 'go get' command you typed, run:

  go install golang.org/x/tools/go/gcimporter

(This assumes you have already used the sed command in my original mail to update all the source code in your tree.)

Andrew

[Gerard]

I am quite sure this topic will return the coming couple of months. Maybe it is an idea to make the announcement a sticky note.

[Monnand]

Why not use gofix to do the job? I remember in good old days, we used
to catch up with go team using this tool until version r60, or r61?

-Monnand

[Caleb Spare]

Andrew already responded to this question earlier in the thread.

https://groups.google.com/d/msg/golang-nuts/eD8dh3T9yyA/mvte_a-kQMAJ

[Monnand]

Oh. Didn't see that. Sorry. This thread was cross-posted later and I
missed Andrew's answer. Thank you!

-Monnand

[dja...@gmail.com]

go install golang.org/x/text/encoding

can't load package: package golang.org/x/text/encoding: cannot find package "golang.org/x/text/encoding" in any of:

/usr/local/go/src/pkg/golang.org/x/text/encoding (from $GOROOT)

/home/........../src/golang.org/x/text/encoding (from $GOPATH)

in golang.org/x/text/ there is only package tranform. (http://godoc.org/golang.org/x/text)

do i miss someting ?

Djadala

[Tim Shannon]

FYI, looks like there shouldn't be a space between the -i arg and .orig

sed -i.orig 's|"code\.google\.com/p/go\.|"golang.org/x/|' \

        $(find . -name '*.go')

[Andrew Gerrand]

That's true for some versions of sed. Thanks for pointing it out.

[Nathan Youngman]

On Wednesday, 5 November 2014 22:47:07 UTC-7, Gerard wrote:

I am quite sure this topic will return the coming couple of months. Maybe it is an idea to make the announcement a sticky note.

I've linked this thread from the SubRepositories wiki entry, but haven't yet updated the full text to specify the new paths and sed script:

https://code.google.com/p/go-wiki/wiki/SubRepositories

Andrew, will this subrepo listing also be updated for this Sunday?

http://tip.godoc.org/-/subrepo

Thanks, Nathan.

[Andrew Gerrand]

Yep. The godoc.org change is committed and will be deployed on Sunday.

[Yongjian Xu]

On Wed Nov 05 2014 at 8:51:35 PM Andrew Gerrand <a...@golang.org> wrote:

You need to move your local go.tools repo to its new location:

  mkdir $GOPATH/src/golang.org/x/

Most likely, you might need to use mkdir -p 

[Andrew Gerrand]

The change has been made; the new paths are in effect.

Please update your code as per the instructions below, if you haven't done so already.

[roger peppe]

As an alternative to this (and slightly safer, although it won't find
instances of the path inside doc comments or strings):

go get launchpad.net/govers
govers -m 'code\.google\.com/p/go\.' golang.org/x/

This will also check if any dependencies are using the old
style paths (use the -d flag to suppress that check)

[se...@fritz-payment.com]

On a different note: as announced, on tip installing go vet will fail with

$ go get code.google.com/p/go.tools/cmd/vet

the code.google.com/p/go.tools/cmd/vet command has moved; use golang.org/x/tools/cmd/vet instead.

The problem is that for previous versions the new location will fail as well:

$ go get golang.org/x/tools/cmd/vet

$ go vet ./...

go tool: no such tool "vet"; to install:

go get code.google.com/p/go.tools/cmd/vet

This means that I can't use the same build script for tip and release anymore - at least how I set it up. Do you have suggestions on how to include the vet tool in the build process?

Thanks

[adon...@google.com]

PSA:

If you have pending changes to the old paths, no change is required to your Mercurial state; as far as hg is concerned, nothing has happened.

Simply rename the local directory, fix up any import paths in *.go files, and submit.

(Sorry if this is obvious, but that didn't stop me from wasting a bunch of time over-thinking things.)

cheers

alan

[Wael M. Nasreddine]

When I do go get -u golang.org/x/tools/cmd/cover on Go 1.2 and Go 1.3, somehow it does not install the binary.

Please see https://travis-ci.org/go-poker/poker/builds/40512085 it was working find before the change https://travis-ci.org/go-poker/poker/builds/40148093

Wael

[Andrew Gerrand]

If you're running Go 1.3, use "go get code.google.com/p/go.tools/cmd/cover". The new import paths will only install to the correct locations under Go 1.4 and later.