Hacker News Reader

Hacker News

Comment by zerr | Hacker News Reader

Parent Full thread

zerr

Aren't people annoyed by URL imports? e.g.:

import "http://www.geocities.com/bla/packagebla"

i.e. I don't want to mention some 3rd party irrelevant company name, and especially its URL in my source code.

View on HN

It's more like

    import "geocities.com/bla/packagebla"

which, IMO, is totally fine, Java has popularized putting some variant of the URL in the package name.

For me, it means that all dependencies are declared by origin, meaning you don't need to track where they come from , the origin is the import.

It also avoids naming collision. If it's open source, just fork it and voila!

So, why not:

  mkdir $GOPATH/src/mystuff

  git clone https://github.com/foo/bar 
  # may be switch to a branch here while you're at it

  mv bar $GOPATH/src/mystuff/bar

Now in your Go program

  import "mystuff/bar"

The whole "URL import" is not a "feature of Go", it's an artifact of "go get", just a tool to make it easier to pull code from github or whatever.

If package `github.com/foo/bar` imports a nested package, say, `github.com/foo/bar/baz`, this will break as it will be trying to look for said package in `$GOPATH/src/github.com/foo/bar/baz`.

I think this explains some of the confusion I've had reading posts below.

I like it.

1) I know exactly where the package came from:

import "geocities.com/bla/packagebla"

import "packagebla"

2) Easy to determine if the package is official, internal, or external (gofmt).

However, what is lacking is a unified vendoring standard. They will address this shortly.

<< I don't want to mention some 3rd party irrelevant company name, and especially its URL in my source code

Then don't use a irrelevant company name. Use your own name e.g. rsc.io/pdf . See more here https://golang.org/doc/go1.4#canonicalimports

Java broke that barrier a long time ago with com.sun.whatever and com.google.whatever, etc.

Those names don't change when you move the code from Subversion, to Github, to Gitlabs, to Mercurial, to cool SV startup offering SCM services.

You should use a vanity name such rsc.io/pdf which provides some meta data where the code is and how to fetch it. I personally like the import syntax.

More about this here https://golang.org/doc/go1.4#canonicalimports

It isn't a proper solution, because it requires package authors to take the additional effort of doing it.

About as much extra effort as it's saving the end users (devs) from having to find and download the package in the first place. And you could just tell your users to download from your site and stick it in their gopath, so it's literally just an enhancement over the model you are wanting, just allows an author to spend a few minutes to save every user some time...

When a package author changes the SCM repository location of a Java package available on any Maven like repository, I don't have to do anything.

And he/she also don't have do any extra work so that I can keep using the same package names.

In practice the author rarely changes the import domain/url so it's not really an nuisance. There are tools to fix imports if the unlikely case actually happens. I value the fact that I don't need config files to make it work more than this small possible inconvenience. There is also a `alias` feature in the upcoming version which allows the author to make the transition from one path to another even easier for clients. https://godoc.org/golang.org/x/tools/refactor/rename

And there is literally nothing preventing that from functioning with Go. All you are complaining about is that the central "package repository" doesn't exist yet, where as my point is that Go has given you all the tools to build a central or distributed repository as you choose. You seem to be most upset that people are just using GitHub cause it's free and it works, and how is that different then any other central repository?

URLs are part of package name and there is no guarantee they will survive a repository change unless the package author has taken the effort to use canonical imports.

As for being upset, not really, unless my boss requires me to use Go, I don't plan using it again.

That's true. But the complaint was sullying his/her code with third party names.

But the reason you don't want to mention a third party is precisely because you may want to change that third party.

And if you start maintaining a redirect on a site you control, what happens when you let the domain die because you never use it?

The amount of HN people who have a personal domain listed in their profile that is dead because life got in the way is surprisingly high (including me until recently).

>And if you start maintaining a redirect on a site you control, what happens when you let the domain die because you never use it?

Right. Either you trust that Github or whomever will always be there or you manage your own domain, or you vendorise and put your dependencies in tree. There are benefits and drawbacks to each approach. It's not magic and we're all adults.

Vendoring doesn't work when the moment to update a package arrives and the upstream has changed SCM repository.

There is no way to avoid doing code changes in order to update the code that was vendored, this assuming that it isn't a binary package to start with.

It does work. You head to `$GOPATH/src/github.com/coolpeople/coolpackage` and then do `git remote set-url origin https://gitlab.com/coolpeople/coolpackage`.

New uses of go get will not work, but it's not impossible to work this way. Alternatively, you use find . -name \*.go -exec sed -i 's:github.com/coolpeople/coolpackage:gitlab.com/coolpeople/coolpackage:' {} +`.

Nope, not annoyed at all

1. I know precisely where a package is coming from.

2. When vendored, I know precisely in which directory a package is stored.

3. I actually want to know if a random no-name library is introduced by developers, so I can google it. URL looking import is a nice feature in this case.

I think it stupid, not merely annoying. In my own projects I have to import "github.com/.." of sibling packages in the same project or go get breaks for my users.

One of the most stupid engineering decisions I've seen in years, imo.

It is interesting to me that this feature has evoked such passion and feeling. To me it is a few extra characters and easily managed at the top of a file. It generally will take at least one line of code to import some other package or library. It isn't as terse as say C or C++ nor is it as flexible as Python's import system. Of all the things that bother me about a particular language, this just never bubbled to the surface for me.

(Vendoring and package management are different issues)

If you fork a go package with subfolders, you will be in for some trouble. Your fork is still importing the original subpackages, because they are referenced by their absolute (original) address. You don't want to rename the imports in the entire fork because you still want to merge/pull request with the original. So your fork needs to live in a folder that uses the original name, not your fork's name (that local repo will have two remotes, the original and yours). This is a pretty annoying and error prone disconnect, especially for people wanting to use your fork; they need to do the same type of workarounds.

It is not a matter of just a few characters. It is a conflation of logical identity (URI) with location (URL). Engineering 101.

https://github.com/coreos/etcd/blob/master/lease/leasehttp/h...

What could possibly justify having to use that import line in a sibling package of the same code?

What’s the problem with importing github.com/… in your projects, aside from possibly not being appealing to your personal taste?

You could ask failed kickstarter projects Haunts: The Manse Macabre what the problem is. Just last week I compiled some 25 year old, K&R style C code and it worked. Will any go code compile in 10 years? 1 year?

https://www.kickstarter.com/projects/2066438441/haunts-the-m...

Vendor it, and your code will always compile.

The principal question is what is the benefit of this monumental facepalm.

Data provenance.

Now explain your side.

You don't have to change #include paths in C++ (or Java imports) code when you move your project from github to bitbucket.

Have you looked at the build system of a C++ project lately? Or a Java project? It's not like that's some super-elegant not-at-all-rolling-catastrophe of a system.

Java and Node, for example, don't solve anything - to get something that builds sensibly they both entirely depend on "external service" being always available and enforcing naming (see the leftpad fiasco). C/C++ are the source of the term "dependency hell".

I've had to deal with CMake as well as automake/autoconf at work recently and I'll take Go's system of fetching/building any day over the Wild West that is the C/C++ eco-system.

It's an artifact of a tool. The same after-thought tool could have just dropped a mapping line in a .gotool file somewhere:

    $ go get whois etcd
    github.com/coreos/etcd

But no. We need to put that in every freaking file and thus transit from information to noise.

EDIT: yes, besides aesthetics, the main (and more important) reason is the dependency on some disposable online resource.

If you are using code hosted there, then you are dependent on that online resource, whether you write their name in your code or note.

1) it's Github, so "disposable" is a fair mental leap and 2) fork and/or vendor the dependencies if you're worried.

I am the more by depending on external source -- as in needing the source for every library used to be able to build.

I saw a comment recently that suggested URL imports are only meant for quick-start, hacky or stuff that won't be deployed somewhere. If you want a given version instead of the tip of master, for example, you're meant to retrieve them separately and set your GOPATH to that directory.

This is called vendorising your dependencies and is done because you can't/shouldn't rely on the third party server being available and serving the same version of the source code to build your code.

Reply on news.ycombinator.com