6 ms·

Any efforts towards a version-numbering standard for dependencies? Godeps is ok as a workaround, but published versions of things like logging packages, etc, w

by jbooth 12y ago

Any efforts towards a version-numbering standard for dependencies? Godeps is ok as a workaround, but published versions of things like logging packages, etc, would make me feel a lot safer when depending on them. And no, I'd rather not 'vendor' source-snapshots of a logging package into every project I ever work on.

threeseed 12y ago
That's an interesting point. Does Go have an equivalent of Sonatype's Nexus ? This is basically mandatory in most enterprises since often you can't just go into the wild to pickup new dependencies. Plus keeping build artefacts managed is pretty important.
- StevePerkins 12y ago
  Not really. Moreover, as far as I know there really isn't a good story around shipping dependencies in binary format rather than source code (as Maven repositories do by default). It is fine to assume the availability of source code when you're working on tiny web microservices... and you're only depending on things like Gorilla, or whatever the leading Sinatra-clone is this week. However, a typical "enterprise" project has numerous proprietary dependencies for which the vendor doesn't want to ship source code. It will be interesting to see whether the Go community eventually adapts to fit enterprise culture, whether enterprise culture adapts to fit Go's model, or whether the two worlds never really come together at all.
- NateDad 12y ago
  Man, that page needs a "What is Nexus?" link. I can't really tell what it is.. I guess some sort of central repo for packages? What go has is Godep (https://github.com/tools/godep https://github.com/tools/godep) which with a single command can copy all your project's dependencies into your repo. from there on out, the dependencies are just part of source control like anything else, so you don't have to open up your build machine to the external internet, for example.
  - threeseed 12y ago
    Yes. It is just a central repo that also does caching/proxying of external repositories. In many enterprises developers won't have access to download from the external internet so godep won't work. It also has a fine grained security model and allows for security evaluations of libraries (check for outdated/insecure etc).
slimsag 12y ago
godep isn't really meant to be for versioning dependencies. It's meant to freeze source code so that you can reproduce builds 100%. With that being said, I'd recommend http://gopkg.in http://gopkg.in, or if you prefer hosting yourself https://azul3d.org/semver https://azul3d.org/semver Disclaimer: I created `azul3d/semver`.
NateDad 12y ago
If your dependency isn't publishing their own versions of their libraries, maybe they shouldn't be depended upon. What I mean is... there's a clear and easy way to version libraries in Go - you encode the version in the import path in some way. When the version changes, the import path changes (which means it's a completely different dependency, as far as Go is concerned). How you get those versions in the import path is up to you - you can use gopkg.in, you can host your own redirector, or just have different repos for each version. It's really not rocket science. For example, I released github.com/natefinch/lumberjack as v1... when I decided I needed to break the API, I released v2 as gopkg.in/natefinch/lumberjack.v2 (which redirects to the v2 branch of the same repo). The very fact that I'm using version numbers indicates I have a commitment to keeping my library stable for third parties. Now, you don't have to trust me, you can use godep or another tool to pin your code to a specific revision of my repo, and if you're really paranoid, you can use godep to vendor my code into your own repo, to insulate you from the possibility that I delete my repo in a fit of anger. (though in theory, that would only stop you for a short period of time, since you should have a copy of my code on every machine that has ever built your code that uses my library). I just don't understand why everyone thinks versioning in Go is a problem. It's not. It's solved... seven ways to Sunday. It's just solved in a slightly different way than other languages solve it... but so what?
- slimsag 12y ago
  I agree with you: package versioning in Go is solved already. I think the thing that conflicts people most often is that there is truly no "official" opinion on the subject aside from what you mentioned: use a different import path.
  - jbooth 12y ago
    I disagree that it's solved. 90% of community libraries aren't even following the gp's recommendation, let alone minor and incremental release versions. And as you said, there's no standard. With nexus/maven repos, when you push v1.4.2 of your library, that's it, it's only published once and everyone sees the same thing. Bug fixes can go out in 1.4.3, new features in 1.5.x and incompatible features in 2.x. Right now, even if everyone followed GP'S advice, I still risk a bug fix breaking my code, or different behavior depending on when I last ran go get.

by jbooth 12y ago

threeseed 12y ago

That's an interesting point. Does Go have an equivalent of Sonatype's Nexus ? This is basically mandatory in most enterprises since often you can't just go into the wild to pickup new dependencies. Plus keeping build artefacts managed is pretty important.

StevePerkins 12y ago
Not really. Moreover, as far as I know there really isn't a good story around shipping dependencies in binary format rather than source code (as Maven repositories do by default). It is fine to assume the availability of source code when you're working on tiny web microservices... and you're only depending on things like Gorilla, or whatever the leading Sinatra-clone is this week. However, a typical "enterprise" project has numerous proprietary dependencies for which the vendor doesn't want to ship source code. It will be interesting to see whether the Go community eventually adapts to fit enterprise culture, whether enterprise culture adapts to fit Go's model, or whether the two worlds never really come together at all.
NateDad 12y ago
Man, that page needs a "What is Nexus?" link. I can't really tell what it is.. I guess some sort of central repo for packages? What go has is Godep (https://github.com/tools/godep https://github.com/tools/godep) which with a single command can copy all your project's dependencies into your repo. from there on out, the dependencies are just part of source control like anything else, so you don't have to open up your build machine to the external internet, for example.
- threeseed 12y ago
  Yes. It is just a central repo that also does caching/proxying of external repositories. In many enterprises developers won't have access to download from the external internet so godep won't work. It also has a fine grained security model and allows for security evaluations of libraries (check for outdated/insecure etc).

slimsag 12y ago

godep isn't really meant to be for versioning dependencies. It's meant to freeze source code so that you can reproduce builds 100%. With that being said, I'd recommend http://gopkg.in http://gopkg.in, or if you prefer hosting yourself https://azul3d.org/semver https://azul3d.org/semver Disclaimer: I created `azul3d/semver`.

NateDad 12y ago

If your dependency isn't publishing their own versions of their libraries, maybe they shouldn't be depended upon. What I mean is... there's a clear and easy way to version libraries in Go - you encode the version in the import path in some way. When the version changes, the import path changes (which means it's a completely different dependency, as far as Go is concerned). How you get those versions in the import path is up to you - you can use gopkg.in, you can host your own redirector, or just have different repos for each version. It's really not rocket science. For example, I released github.com/natefinch/lumberjack as v1... when I decided I needed to break the API, I released v2 as gopkg.in/natefinch/lumberjack.v2 (which redirects to the v2 branch of the same repo). The very fact that I'm using version numbers indicates I have a commitment to keeping my library stable for third parties. Now, you don't have to trust me, you can use godep or another tool to pin your code to a specific revision of my repo, and if you're really paranoid, you can use godep to vendor my code into your own repo, to insulate you from the possibility that I delete my repo in a fit of anger. (though in theory, that would only stop you for a short period of time, since you should have a copy of my code on every machine that has ever built your code that uses my library). I just don't understand why everyone thinks versioning in Go is a problem. It's not. It's solved... seven ways to Sunday. It's just solved in a slightly different way than other languages solve it... but so what?

slimsag 12y ago
I agree with you: package versioning in Go is solved already. I think the thing that conflicts people most often is that there is truly no "official" opinion on the subject aside from what you mentioned: use a different import path.
- jbooth 12y ago
  I disagree that it's solved. 90% of community libraries aren't even following the gp's recommendation, let alone minor and incremental release versions. And as you said, there's no standard. With nexus/maven repos, when you push v1.4.2 of your library, that's it, it's only published once and everyone sees the same thing. Bug fixes can go out in 1.4.3, new features in 1.5.x and incompatible features in 2.x. Right now, even if everyone followed GP'S advice, I still risk a bug fix breaking my code, or different behavior depending on when I last ran go get.