[golang-dev] proposal: custom import path checking

I already said that this proposal was a bad idea. Go already makes moving
packages and forking more difficult than it needs to be due to not allowing
relative import paths. This proposal makes it even harder without any
significant gains. In fact, it even breaks more things: proxy services
which do version/revision pinning. Given that Go developers have clearly
expressed that they won't add any support for revision/version pinning in
the Go toolchain, I think that keeping these services working should be a
priority.

If the imports mechanism is going to be changed, it should be towards
fixing its two most glaring problems:

- Setting a canonical import path.
- Allowing easier *correct* forks without having to do some trickery nor
change the code. There are lots of forks in GitHub with import to
subpackages pointing to the original repo.

The solution to the first problem is blacklisting import paths, not
whitelisting. By blacklisting github.com/rsc/pdf you get practically the
same effect (if you move the package elsewhere you might have to update the
blacklist), without breaking anything. In fact, you can have even more
functionality by augmenting the proposal by a little bit.

// +import rsc.io/pdf -> this only lists the canonical import path, it
doesn't restrict it
// -import github.com/rsc/pdf -> this generates an error if imported from
github.com/rsc/pdf
// -import gopkgs.com* -> if you don't want users to import your package
from a version/revision pinning service, you can prevent them from doing so

// Package pdf does whatever... blah blah blah -> this is the package
documentation
package pdf

With these comments in a Go file, users can still fork the repository and
work from there without doing any changes to this metadata and go get'ing
from a blacklisted location still generates a useful error message:

$ go get github.com/rsc/pdf
error: this package does not allow being imported from github.com/rsc/pdf,
please use rsc.io/pdf instead

It also uses a syntax similar to build tags (easier to understand and
remember) and allows multiple blacklisted/whitelisted locations. e.g.

// +import rsc.io/pdf
// +import gopkgs.com/pdf.v1
// -import *

This allows importing from either rsc.io/pdf or gopkgs.com/pdf.v1,
disallowing any other import paths.

$ go get github.com/rsc/pdf
error: this package does not allow being imported from github.com/rsc/pdf,
please use rsc.io/pdf or gopkgs.com/pdf.v1 instead

And, finally, for exactly the same effect of your proposal (although I
wouldn't recommend to use that, but if people want to shoot themselves in
the foot, I think they should be allowed to):

// +import rsc.io/pdf
// -import *


For the second point, I think relative import paths should be brought back
(fixing the problems in the compiler/linker that lead to their demise), but
allowing only intra-repository relative imports. Virtually, every other
language allows relative includes/requires/imports and they're definitely
useful for big projects with lots of inter-project dependencies.

Regards,
Alberto