4 ms·

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 user

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]
      - PopsiclePete 10y ago
        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.
    - eternalban 10y ago
      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.
    - deleted 10y ago
      [deleted]
- ksherlock 10y ago
  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-manse-macabre/posts/373466 https://www.kickstarter.com/projects/2066438441/haunts-the-m...
  - pdappollonio 10y ago
    Vendor it, and your code will always compile.
bitexploder 10y ago
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)
- eternalban 10y ago
  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/http.go#L26 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?
- Jare 10y ago
  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.

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]
    - PopsiclePete 10y ago
      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.
  - eternalban 10y ago
    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.
  - deleted 10y ago
    [deleted]
ksherlock 10y ago
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-manse-macabre/posts/373466 https://www.kickstarter.com/projects/2066438441/haunts-the-m...
- pdappollonio 10y ago
  Vendor it, and your code will always compile.

bitexploder 10y ago

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)

eternalban 10y ago
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/http.go#L26 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?
Jare 10y ago
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.