4 ms·

To me the root problem for this alias proposal is that go currently ignores version dependencies. Go is designed so that we have to assume that an API and the

by chmike 10y ago

To me the root problem for this alias proposal is that go currently ignores version dependencies. Go is designed so that we have to assume that an API and the compiler are either perfectly backward compatible or immutable. This is a simplification inherited from C and other programming languages. If we want to support changing an API, then we have to specify version along the package name and import statement. Some packages already do that but it isn't satisfying because it is hardcoded in the package name. I like the versioning rule chosen by ICE from zeroc. A version is not backward compatible with other versions. A release must be backward compatible with previous release of the same version. So it should be possible to specify a version and release for packages in import statements which specify that the specified release and all subsequent release are valid. Dub, for the D programming language is going that line of direction. I'm aware that it may create a dependency hell. But it already exist and is hidden. The alias hack is not a good solution. It will make things worse by making the rules more lax.

rtpg 10y ago
is this because Go handles dependencies itself? What's preventing a tool like pip, npm, or stack from working with Go for versioning?
- pjmlp 10y ago
  Culture, you should have a thick skin when discussing those issues on gonuts.
hodgesrm 10y ago
Forgive me for asking but are you saying that you want this kind of versioning baked into the language? That seems to add a lot of complexity to Go itself. Java does not have versions baked into the language except for for class formats, which change rarely and are upwards compatible with new JDKs. Package versioning nowadays is handled by tools like maven and gradle. It's a good separation of concerns that keeps Java from being even more complicated than it already is. If the concern is with handling interface versions, why not just use loosely coupled web services?
- chmike 10y ago
  with big projects we will have dependencies with other packages. It is a good sign that this happens. But then we get also version dependency witch is currently ignored by go. I use gvm which is one way to handle it, but it is not enough because external package I use may have their own external dependency. The bigger the project, the bigger the problem will be. Actually the version dependency is undpecified. One has to guess it by trying to compile. I don't think aliasing package names solves this. You tell me that java tools take care of it. So go tools could take care of it. But this requires that the info is provided in a standard and clear way. This info can be kept optional for backward compatibility. Without this info, we are limited when trying to use go for bigger projects.
  - aikah 10y ago
    Versioning is not going to fix go's namespace problem, unless the package manager does the aliasing, like in every other well crafted language. Go namespace feature is completely broken, URL shouldn't be namespaces. This is yet another half backed feature put in Go that doesn't scale in practice. There are so many of them in the language, they'll be more and more obvious as the language gains adoption.
    - chmike 10y ago
      Version conflicts and package naming collisions are two different problems. The OP referred to the version problems. I overlooked package naming conflict which can occur with composed package names. It is true and correct that aliasing will help solving such type of problems. Thanks to point this out. PS: I suspect you have been down-voted because your critic is excessive (cf. "half backed feature").
      - aikah 10y ago
        > Version conflicts and package naming collisions are two different problems You cannot separate both issues. Go assumes all API are immutable which is insane, a package manager won't solve that.
tomohawk 10y ago
http://labix.org/gopkg.in http://labix.org/gopkg.in is useful, but maybe it doesn't go far enough. Perhaps it should be expanded to do the aliasing? Having the version in the package name is useful, as an incompatible API change usually requires visiting the code and this forces the issue.
blablabla123 10y ago
Go is somehow based on the assumption that code is really carefully designed. The tools in /bin are the perfect example for that. Unfortunately commercial projects usually have a much faster development pace. It definitely eases the problem, like proper dep mgmt would, but not more... ;)
IshKebab 10y ago
I don't see what is wrong with including the version in the package name. `http`, `http2`, `http3` and so on. I mean if the API changes in a backwards-incompatible way it is effectively a new package.

by chmike 10y ago

rtpg 10y ago

is this because Go handles dependencies itself? What's preventing a tool like pip, npm, or stack from working with Go for versioning?

pjmlp 10y ago
Culture, you should have a thick skin when discussing those issues on gonuts.

hodgesrm 10y ago

Forgive me for asking but are you saying that you want this kind of versioning baked into the language? That seems to add a lot of complexity to Go itself. Java does not have versions baked into the language except for for class formats, which change rarely and are upwards compatible with new JDKs. Package versioning nowadays is handled by tools like maven and gradle. It's a good separation of concerns that keeps Java from being even more complicated than it already is. If the concern is with handling interface versions, why not just use loosely coupled web services?

chmike 10y ago
with big projects we will have dependencies with other packages. It is a good sign that this happens. But then we get also version dependency witch is currently ignored by go. I use gvm which is one way to handle it, but it is not enough because external package I use may have their own external dependency. The bigger the project, the bigger the problem will be. Actually the version dependency is undpecified. One has to guess it by trying to compile. I don't think aliasing package names solves this. You tell me that java tools take care of it. So go tools could take care of it. But this requires that the info is provided in a standard and clear way. This info can be kept optional for backward compatibility. Without this info, we are limited when trying to use go for bigger projects.
- aikah 10y ago
  Versioning is not going to fix go's namespace problem, unless the package manager does the aliasing, like in every other well crafted language. Go namespace feature is completely broken, URL shouldn't be namespaces. This is yet another half backed feature put in Go that doesn't scale in practice. There are so many of them in the language, they'll be more and more obvious as the language gains adoption.
  - chmike 10y ago
    Version conflicts and package naming collisions are two different problems. The OP referred to the version problems. I overlooked package naming conflict which can occur with composed package names. It is true and correct that aliasing will help solving such type of problems. Thanks to point this out. PS: I suspect you have been down-voted because your critic is excessive (cf. "half backed feature").
    - aikah 10y ago
      > Version conflicts and package naming collisions are two different problems You cannot separate both issues. Go assumes all API are immutable which is insane, a package manager won't solve that.

tomohawk 10y ago

http://labix.org/gopkg.in http://labix.org/gopkg.in is useful, but maybe it doesn't go far enough. Perhaps it should be expanded to do the aliasing? Having the version in the package name is useful, as an incompatible API change usually requires visiting the code and this forces the issue.

blablabla123 10y ago

Go is somehow based on the assumption that code is really carefully designed. The tools in /bin are the perfect example for that. Unfortunately commercial projects usually have a much faster development pace. It definitely eases the problem, like proper dep mgmt would, but not more... ;)

IshKebab 10y ago

I don't see what is wrong with including the version in the package name. `http`, `http2`, `http3` and so on. I mean if the API changes in a backwards-incompatible way it is effectively a new package.