5 ms·

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

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