Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide whether to alias package names #18

Open
lmars opened this issue Sep 22, 2017 · 2 comments
Open

Decide whether to alias package names #18

lmars opened this issue Sep 22, 2017 · 2 comments

Comments

@lmars
Copy link
Member

lmars commented Sep 22, 2017

It has been proposed on two occasions by @nolash that package import URLs which don't end with the same name as the package they are importing should be explicitly aliased (see here and here).

So for example, import github.com/ipfs/go-cid should actually be import cid github.com/ipfs/go-cid even though the package is already called cid.

I am against this because I never manually edit imports (I just let goimports do it, which I assume most people do), and so doing so means I have to go and look at the imports all the time, even if the code compiles just fine.

That being said, I am happy to do this if most contributors find it useful.

/cc @nolash @orenyodfat @zelig

@nolash
Copy link

nolash commented Sep 22, 2017

In the spirit of consciencousness, I manually went into the packages on both occasions to find which package it actually was. It is a slight nuisance, and potentially confusing for those lesser experienced with golang.

A compromise could be to add a comment at the end of the line, revealing what the real package name is:

include (
    "github.com/meta-network/xml" // metaxml
)

@MrTibbles
Copy link

Has this been discussed any further offline?

My opinion does not have strong enough Go foundations & experience, just yet.

@lmars lmars mentioned this issue Nov 12, 2017
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants