6 ms·

Aren't people annoyed by URL imports? e.g.: import "http://www.geocities.com/bla/packagebla" http://www.geocities.com/bla/packagebla" i.e. I don't want to men

by zerr 10y ago

Aren't people annoyed by URL imports? e.g.: import "http://www.geocities.com/bla/packagebla" 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.

smcl 10y ago
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.
- fnord123 10y ago
  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.
fnord123 10y ago
Java broke that barrier a long time ago with com.sun.whatever and com.google.whatever, etc.
- pjmlp 10y ago
  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.
  - fnord123 10y ago
    That's true. But the complaint was sullying his/her code with third party names.
    - mattmanser 10y ago
      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).
      - fnord123 10y ago
        >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.
        pjmlp 10y ago
        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.
        fnord123 10y ago
        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` 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:' {} +`.
  - themihai 10y ago
    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 https://golang.org/doc/go1.4#canonicalimports
    - pjmlp 10y ago
      It isn't a proper solution, because it requires package authors to take the additional effort of doing it.
      - Vendan 10y ago
        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...
        pjmlp 10y ago
        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.
        Vendan 10y ago
        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?
        10y ago
tscs37 10y ago
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.
- chmike 10y ago
  It also avoids naming collision. If it's open source, just fork it and voila!
eternalban 10y ago
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.
- secure 10y ago
  What’s the problem with importing github.com/… in your projects, aside from possibly not being appealing to your personal taste?
  - eternalban 10y ago
    The principal question is what is the benefit of this monumental facepalm.
    - fnord123 10y ago
      Data provenance. Now explain your side.
      - zerr 10y ago
        You don't have to change #include paths in C++ (or Java imports) code when you move your project from github to bitbucket.
        XorNot 10y ago
        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".
        deleted 10y ago
        [deleted]
themihai 10y ago
<< 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 https://golang.org/doc/go1.4#canonicalimports
nachexnachex 10y ago
I am the more by depending on external source -- as in needing the source for every library used to be able to build.
zerr 10y ago
EDIT: yes, besides aesthetics, the main (and more important) reason is the dependency on some disposable online resource.
- coldtea 10y ago
  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.
- wlll 10y ago
  1) it's Github, so "disposable" is a fair mental leap and 2) fork and/or vendor the dependencies if you're worried.
velodrome 10y ago
I like it. 1) I know exactly where the package came from: import "geocities.com/bla/packagebla" vs 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.
gtrubetskoy 10y ago
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.
- fnord123 10y ago
  I think this explains some of the confusion I've had reading posts below.
- hazbo 10y ago
  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`.
didip 10y ago
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.

by zerr 10y ago

smcl 10y ago

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.

fnord123 10y ago
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.

fnord123 10y ago

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

pjmlp 10y ago
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.
- fnord123 10y ago
  That's true. But the complaint was sullying his/her code with third party names.
  - mattmanser 10y ago
    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).
    - fnord123 10y ago
      >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.
      - pjmlp 10y ago
        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.
        fnord123 10y ago
        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` 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:' {} +`.
- themihai 10y ago
  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 https://golang.org/doc/go1.4#canonicalimports
  - pjmlp 10y ago
    It isn't a proper solution, because it requires package authors to take the additional effort of doing it.
    - Vendan 10y ago
      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...
      - pjmlp 10y ago
        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.
        Vendan 10y ago
        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?
        10y ago

tscs37 10y ago

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.

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

eternalban 10y ago

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.

secure 10y ago
What’s the problem with importing github.com/… in your projects, aside from possibly not being appealing to your personal taste?
- eternalban 10y ago
  The principal question is what is the benefit of this monumental facepalm.
  - fnord123 10y ago
    Data provenance. Now explain your side.
    - zerr 10y ago
      You don't have to change #include paths in C++ (or Java imports) code when you move your project from github to bitbucket.
      - XorNot 10y ago
        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".
      - deleted 10y ago
        [deleted]

themihai 10y ago

<< 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 https://golang.org/doc/go1.4#canonicalimports

nachexnachex 10y ago

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

zerr 10y ago

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

coldtea 10y ago
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.
wlll 10y ago
1) it's Github, so "disposable" is a fair mental leap and 2) fork and/or vendor the dependencies if you're worried.

velodrome 10y ago

I like it. 1) I know exactly where the package came from: import "geocities.com/bla/packagebla" vs 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.

gtrubetskoy 10y ago

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.

fnord123 10y ago
I think this explains some of the confusion I've had reading posts below.
hazbo 10y ago
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`.

didip 10y ago

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.