importing internal packages not allowed in go 1.5.1

[mrak]

Imorting 'internal' packages doesn't work in 1.5.1

I am importing golang.org/x/net/internal/iana and  golang.org/x/net/internal/nettest

with errors

imports golang.org/x/net/internal/iana: use of internal package not allowed 

imports golang.org/x/net/internal/nettest: use of internal package not allowed

Is there a timeframe for the fix?

[Caleb Spare]

This is intentional. You can read more about this here:

golang.org/s/go14internal

> --
> 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.

[Caleb Spare]

Or see the go tool documentation here:

https://golang.org/cmd/go/#hdr-Internal_Directories

[sonn...@gmail.com]

it's importable in 1.4, just not in 1.5

If I want to do nettest.SupportsRawIPSocket()

or iana.ProtocolICMP I can't in 1.5

[Kamil Kisiel]

Go 1.4 restricted internal imports from paths GOROOT. As of Go 1.5 they are also restricted for paths in GOPATH.

[Marvin Renich]

* Caleb Spare <ces...@gmail.com> [150910 21:06]:

> Or see the go tool documentation here:
>
> https://golang.org/cmd/go/#hdr-Internal_Directories
>
> On Thu, Sep 10, 2015 at 6:04 PM, Caleb Spare <ces...@gmail.com> wrote:
> > This is intentional. You can read more about this here:
> >
> > golang.org/s/go14internal

Can someone explain to me what problem is solved by not allowing
importing of subdirectories of internal? First, I truly do not
understand what the benefit is. Second, it doesn't really seem to
prevent anything, it merely adds work for someone who wants to get
around the restriction; the source code is there and can be copied to a
separate directory. Now the user has all the problems of forking the
code when no fork was needed.

This sounds like security by obscurity, but worse.

...Marvin

[Ian Lance Taylor]

The benefits are listed in the above doc.

The goal is not to prevent anything, nor to provide any sort of
security. It's to permit structuring a package into multiple packages
without increasing the exported, supported, documented, API.

Ian

[Dump Hole]

Not sure if this benefits anything.  This actually makes it difficult for open source projects since the folder structure change between forks.

For Example a project 'foo' owned by 'opensource':

github.com/opensource/foo

When you fork it, it becomes

github.com/yourname/foo

If there's a piece of code that's importing 'internal' package (i.e github.com/opensource/foo/internal/bar), the project under yourname just fail to compile completely.

I don't think this is a good idea until Go is capable of parsing relative imports.  Specifying the entire somedomain/a/b/c/d/e for every imports is redundant anyway.

[Kevin Malachowski]

When you fork a project, shouldn't you be swapping out all the import strings to the fork's path anyway? Otherwise you'll be depending on the original repo when compiling your fork, which doesn't sound like something you want (at least not if you're going to change things other than the main packages).

[Dump Hole]

Why would I be swapping out all imports?  That creates unnecessary code changes, especially if you plan on doing some pull request back to the original repo.

Suppose you fork a relatively large codebase with 1000 files, and you are only interested in tweaking one file.  800 of these import at least one internal package.  Are you really recommending changing all 800 files before you can even start tweaking?

[Dave Cheney]

You don't need to change anything, just add a new git remote.

http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html

[Staven]

On Sun, Mar 27, 2016 at 12:03:50AM -0700, Dump Hole wrote:
> Suppose you fork a relatively large codebase with 1000 files, and you are
> only interested in tweaking one file. 800 of these import at least one
> internal package. Are you really recommending changing all 800 files
> before you can even start tweaking?

If only we had some sort of machine that could accomplish such a daunting
task for us.