8 ms·

> Some projects like GORM sidestep the issue entirely by tagging their 2.0 releases as far flung 1.x releases. That something of a solution, but smells terrible

> Some projects like GORM sidestep the issue entirely by tagging their 2.0 releases as far flung 1.x releases. That something of a solution, but smells terrible. Amusingly, the Google protobuf team did a similar thing for the Go protobuf bindings. The new, backwards-incompatible `protobuf` module started with version 1.20, while the old module is at 1.4. If you've followed this, you know I've omitted one detail - they actually changed the name of the module as well, from `github.com/golang/protobuf` to `google.golang.org/protobuf`. Because, of course, Golang modules names are actually URLs, not identifiers like in every other package manager out there.

xyzzy_plugh 6y ago
> Because, of course, Golang modules names are actually URLs, not identifiers like in every other package manager out there. They don't have to be URLs, though. What's the difference between `google.golang.org/protobuf` and `org.golang.google.protobuf`?
- simiones 6y ago
  As far as I know, the difference is that the first one will work with `go mod`, while the second one won't work, unless you have a replace directive. As far as I know, `go mod` will simply connect to https://$MODULE_NAME https://$MODULE_NAME and retrieve metadata and contents from there.
- a1369209993 6y ago
  > What's the difference between `google.golang.org/protobuf` and `org.golang.google.protobuf`? There isn't one, because that's also a (mangled) URL, namely "http://protobuf.google.golang.org/" http://protobuf.google.golang.org/", and should be rejected for the same reasons. A identifier would be "protobuf"; note the lack of any reference to the DNS domain.
  - grey-area 6y ago
    Do that and soon you're going to have to introduce namespaces, and you're back to something that looks like urls. People use these longer import identifiers because they avoid polluting the global namespace, which be reserved for very important packages (in the case of go the std lib).
    - munificent 6y ago
      > Do that and soon you're going to have to introduce namespaces Everyone says this but there is strong evidence from npm and other package ecosystems that you can go surprisingly far with a single flat global namespace. I think there is a paranoia among software developers about potential name collisions. But in reality, name collisions are rare and easily avoided. There are 308,915,776 unique six-letter identifiers. Go to eight and you have 208,827,064,576 names to choose from.
      - a1369209993 6y ago
        > There are 308,915,776 unique six-letter identifiers. Go to eight and you have 208,827,064,576 names to choose from. To be scrupulously fair, no one wants to name their package "udjwhc"; the problem is more "protobuf" (by google) vs "protobuf" (by someone other than google), both implementing similar but subtly different interfaces for doing the thing they're named after.
      - grey-area 6y ago
        Namespaces are used for clarity (this is pkg log from org/user x), not because we run out of letters.
        munificent 6y ago
        The problem with that is that you're essentially using a hierarchy to attach some piece of metadata to each package. The question then is what piece of metadata is both so valuable to be worth enshrining in the name and yet so unchanging that if its value changes, you're OK with every user of that package having to migrate to the new identifier. I have yet to see any particular bit of metadata that fits into that set. Using "owner" like you do in your example here is a common choice, but also very frequently changes. If you look around, you'll find lots of examples where a package moved to a new owner and caused all sorts of problems because now all the old name references no longer work. You could try to pick some essentially descriptive property of the package itselfs—maybe, say, "Net" if it has to with networking—like CPAN does, but it's not clear that doing so adds any real value beyond satisfying our human desire to put things in neat littly cubbyholes.
sascha_sl 6y ago
Kubernetes, arguably the largest open source project using go, tags 1.17 as 0.1.17. I don't know how anyone in this thread wants to continue arguing for the merits of the current v2 scheme. It clearly did not catch on in the community and the status quo of hoping a go get will smoothen out all rough edges of your dependencies is terrible, almost as terrible as dep was (you certainly couldn't use consistent versions of the kubernetes components without hardcoded override blocks).

xyzzy_plugh 6y ago

> Because, of course, Golang modules names are actually URLs, not identifiers like in every other package manager out there. They don't have to be URLs, though. What's the difference between `google.golang.org/protobuf` and `org.golang.google.protobuf`?

simiones 6y ago
As far as I know, the difference is that the first one will work with `go mod`, while the second one won't work, unless you have a replace directive. As far as I know, `go mod` will simply connect to https://$MODULE_NAME https://$MODULE_NAME and retrieve metadata and contents from there.
a1369209993 6y ago
> What's the difference between `google.golang.org/protobuf` and `org.golang.google.protobuf`? There isn't one, because that's also a (mangled) URL, namely "http://protobuf.google.golang.org/" http://protobuf.google.golang.org/", and should be rejected for the same reasons. A identifier would be "protobuf"; note the lack of any reference to the DNS domain.
- grey-area 6y ago
  Do that and soon you're going to have to introduce namespaces, and you're back to something that looks like urls. People use these longer import identifiers because they avoid polluting the global namespace, which be reserved for very important packages (in the case of go the std lib).
  - munificent 6y ago
    > Do that and soon you're going to have to introduce namespaces Everyone says this but there is strong evidence from npm and other package ecosystems that you can go surprisingly far with a single flat global namespace. I think there is a paranoia among software developers about potential name collisions. But in reality, name collisions are rare and easily avoided. There are 308,915,776 unique six-letter identifiers. Go to eight and you have 208,827,064,576 names to choose from.
    - a1369209993 6y ago
      > There are 308,915,776 unique six-letter identifiers. Go to eight and you have 208,827,064,576 names to choose from. To be scrupulously fair, no one wants to name their package "udjwhc"; the problem is more "protobuf" (by google) vs "protobuf" (by someone other than google), both implementing similar but subtly different interfaces for doing the thing they're named after.
    - grey-area 6y ago
      Namespaces are used for clarity (this is pkg log from org/user x), not because we run out of letters.
      - munificent 6y ago
        The problem with that is that you're essentially using a hierarchy to attach some piece of metadata to each package. The question then is what piece of metadata is both so valuable to be worth enshrining in the name and yet so unchanging that if its value changes, you're OK with every user of that package having to migrate to the new identifier. I have yet to see any particular bit of metadata that fits into that set. Using "owner" like you do in your example here is a common choice, but also very frequently changes. If you look around, you'll find lots of examples where a package moved to a new owner and caused all sorts of problems because now all the old name references no longer work. You could try to pick some essentially descriptive property of the package itselfs—maybe, say, "Net" if it has to with networking—like CPAN does, but it's not clear that doing so adds any real value beyond satisfying our human desire to put things in neat littly cubbyholes.

sascha_sl 6y ago

Kubernetes, arguably the largest open source project using go, tags 1.17 as 0.1.17. I don't know how anyone in this thread wants to continue arguing for the merits of the current v2 scheme. It clearly did not catch on in the community and the status quo of hoping a go get will smoothen out all rough edges of your dependencies is terrible, almost as terrible as dep was (you certainly couldn't use consistent versions of the kubernetes components without hardcoded override blocks).