4 ms·

I'm really not crazy about the "import github.com/foobar/foo" thing. It seems that systems like CPAN have an advantage in that a) you can roll your own mirror t

I'm really not crazy about the "import github.com/foobar/foo" thing. It seems that systems like CPAN have an advantage in that a) you can roll your own mirror to avoid using an untrusted network and b) should upstream change their VCS etc, the go system requires changes to all files that import the affected module. The go system also seems to ignore the problem of versioning libraries, though I imagine there's probably some support for that in go get?

BarkMore 14y ago
The 'go get' sub-command is the only part of Go that interprets the import path as the location of a version control system repository. The use of the 'go get' sub-command is optional. You can use version control commands directly to get code from your own repository mirror or to get specific versions from a repository. As long as you clone the repository to the directory in the workspace corresponding to the import path, all of the other go tools will work with the code.
- ansible 14y ago
  And what's nice about this is that if someone else uses your project and doesn't have their own mirrors for the repositories, he can use 'go get' to download the imports. And that's without making any changes to the codebase or build scripts.
grey-area 14y ago
I actually think the go solution to this problem is quite elegant (because it also encapsulates info on where the dependencies come from), and preferable to other package systems which have one point of failure or central package repository. If you want to roll your own mirror simply change github.com/foo to my mirror.com/foo in your code. At least then you document the expected dependency with the code itself and can remove it if required. It also lets you very easily import a local package instead if you prefer. If the maintainer changes the location of their package and you have not taken a copy you might have to change your code, but this happens very rarely in my experience and isn't a big issue. Go doesn't have versioning for packages yet, and they will need to add this, but that wouldn't be hard to add as an option to the current import scheme.
- niggler 14y ago
  "If you want to roll your own mirror simply change github.com/foo to my mirror.com/foo in your code" This is very messy. If a mirror changes, you have to go back through all of your source code and change all of the relevant imports. I personally find the node.js/npm solution to the problem (separate the dependency mapping for external resources, allow changes to those without having to modify the source) to be more useful. It lets you swap local and remote versions effortlessly and, using a private npm server, maintain packages for a large internal network.
  - grey-area 14y ago
    This is very messy. If a mirror changes, you have to go back through all of your source code and change all of the relevant imports. Have you run into real-life problems with this or is it more a hypothetical issue? You can use local package import paths instead if you prefer to manage your dependencies separately (and have several different goroots too with different sets of packages), or use DNS/hosts to manage where your private package server domain points, there are lots of options which don't require specification of a package server in one place.
- BarkMore 14y ago
  "If you want to roll your own mirror simply change github.com/foo to my mirror.com/foo in your code" Instead of changing the code, use a version control command to clone your repository mirror to your workspace.
zemo 14y ago
it forces the package names to be globally unique, by piggybacking off of DNS. If you own "lclarkmichalek.com" you can put up a server and then have "import lclarkmichalek.com/foobar/foo" if you really want to.
- lclarkmichalek 14y ago
  That's a point I hadn't thought of. Though on the negative side, it does make it significantly harder to create a true "drop in replacement" that other languages have (i.e. where a library provides a replacement of another library without requiring any modification to the source code of an application using that library).
  - NateDad 14y ago
    That's a good thing.
    - lclarkmichalek 14y ago
      How so? I can think of a couple of examples where libraries have needed to be replaced and it's only because their replacements were transparently compatible that the replacement was possible without major pain all around.
  - chimeracoder 14y ago
    You're still going to need to recompile, because Go programs are all statically linked. Replacing the imports is pretty easy, though - because Go is so draconian about certain elements of formatting and style (including restrictions on imports), it's relatively straightforward to migrate code like this. (The 'go fix' tool is an even better example of the power that such an opinionated compiler provides as its tradeoff)

BarkMore 14y ago

The 'go get' sub-command is the only part of Go that interprets the import path as the location of a version control system repository. The use of the 'go get' sub-command is optional. You can use version control commands directly to get code from your own repository mirror or to get specific versions from a repository. As long as you clone the repository to the directory in the workspace corresponding to the import path, all of the other go tools will work with the code.

ansible 14y ago
And what's nice about this is that if someone else uses your project and doesn't have their own mirrors for the repositories, he can use 'go get' to download the imports. And that's without making any changes to the codebase or build scripts.

grey-area 14y ago

I actually think the go solution to this problem is quite elegant (because it also encapsulates info on where the dependencies come from), and preferable to other package systems which have one point of failure or central package repository. If you want to roll your own mirror simply change github.com/foo to my mirror.com/foo in your code. At least then you document the expected dependency with the code itself and can remove it if required. It also lets you very easily import a local package instead if you prefer. If the maintainer changes the location of their package and you have not taken a copy you might have to change your code, but this happens very rarely in my experience and isn't a big issue. Go doesn't have versioning for packages yet, and they will need to add this, but that wouldn't be hard to add as an option to the current import scheme.

niggler 14y ago
"If you want to roll your own mirror simply change github.com/foo to my mirror.com/foo in your code" This is very messy. If a mirror changes, you have to go back through all of your source code and change all of the relevant imports. I personally find the node.js/npm solution to the problem (separate the dependency mapping for external resources, allow changes to those without having to modify the source) to be more useful. It lets you swap local and remote versions effortlessly and, using a private npm server, maintain packages for a large internal network.
- grey-area 14y ago
  This is very messy. If a mirror changes, you have to go back through all of your source code and change all of the relevant imports. Have you run into real-life problems with this or is it more a hypothetical issue? You can use local package import paths instead if you prefer to manage your dependencies separately (and have several different goroots too with different sets of packages), or use DNS/hosts to manage where your private package server domain points, there are lots of options which don't require specification of a package server in one place.
BarkMore 14y ago
"If you want to roll your own mirror simply change github.com/foo to my mirror.com/foo in your code" Instead of changing the code, use a version control command to clone your repository mirror to your workspace.

zemo 14y ago

it forces the package names to be globally unique, by piggybacking off of DNS. If you own "lclarkmichalek.com" you can put up a server and then have "import lclarkmichalek.com/foobar/foo" if you really want to.

lclarkmichalek 14y ago
That's a point I hadn't thought of. Though on the negative side, it does make it significantly harder to create a true "drop in replacement" that other languages have (i.e. where a library provides a replacement of another library without requiring any modification to the source code of an application using that library).
- NateDad 14y ago
  That's a good thing.
  - lclarkmichalek 14y ago
    How so? I can think of a couple of examples where libraries have needed to be replaced and it's only because their replacements were transparently compatible that the replacement was possible without major pain all around.
- chimeracoder 14y ago
  You're still going to need to recompile, because Go programs are all statically linked. Replacing the imports is pretty easy, though - because Go is so draconian about certain elements of formatting and style (including restrictions on imports), it's relatively straightforward to migrate code like this. (The 'go fix' tool is an even better example of the power that such an opinionated compiler provides as its tradeoff)