4 ms·
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
by 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 agoVersioning 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 agoVersion 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.