4 ms·

The major reason to have separate import paths is to support multiple major versions of the same module, which is important to not end up stuck in situations wh

by dilap 6y ago

The major reason to have separate import paths is to support multiple major versions of the same module, which is important to not end up stuck in situations where package A wants dep D1 and package B wants dep D2, and you can't fix it. Of course, you could handle this w/ more complexity in the package manager/build system, but having separate import paths makes it very clear, and is a very "Go"ish solution. Since you're only doing this when you've got breaking changes coming in anyway, i.e., you've already got to fix the code, is it really such a big deal to update the import paths while you're at it? It's like a 2 second grep/replace... That said, having Go tell you about major version upgrades available, and also an option to fix the code to use the upgraded versions import path, are good ideas.

xyzzy_plugh 6y ago
> also an option to fix the code to use the upgraded versions import path, are good ideas. In theory this sounds good but in practice major versions can be drastically incompatible, and I wouldn't expect this to work very well at all in practice. One of the excellent features Go's use of semantic versioning enables is for lower major versions to be updated to use the higher major version implementations, as a sort of backwards-compatible shim. In this case, no tools needed.
toast0 6y ago
> Since you're only doing this when you've got breaking changes coming in anyway, i.e., you've already got to fix the code Just because the module broke compat doesn't mean you were using the things that broke though. Maybe they dropped or changed functions that you didn't use.
- xh-dude 6y ago
  Then you don’t have breaking changes, though?
  - srtjstjsj 6y ago
    Breaking and Naming is a property of the whole package, not the subset one client uses.
- dilap 6y ago
  It's interesting that your comment and xyzzy_plugh's comment make opposite points! But you're right, in some cases the breaking changes won't break you. In any case, I do think it's worth having a dead-easy way to fix the imports, rather than having to fuss about with grep. (And what if you could actually ship rules to transform code to the upgraded version? That would be cool...)

by dilap 6y ago

xyzzy_plugh 6y ago

> also an option to fix the code to use the upgraded versions import path, are good ideas. In theory this sounds good but in practice major versions can be drastically incompatible, and I wouldn't expect this to work very well at all in practice. One of the excellent features Go's use of semantic versioning enables is for lower major versions to be updated to use the higher major version implementations, as a sort of backwards-compatible shim. In this case, no tools needed.

toast0 6y ago

> Since you're only doing this when you've got breaking changes coming in anyway, i.e., you've already got to fix the code Just because the module broke compat doesn't mean you were using the things that broke though. Maybe they dropped or changed functions that you didn't use.

xh-dude 6y ago
Then you don’t have breaking changes, though?
- srtjstjsj 6y ago
  Breaking and Naming is a property of the whole package, not the subset one client uses.
dilap 6y ago
It's interesting that your comment and xyzzy_plugh's comment make opposite points! But you're right, in some cases the breaking changes won't break you. In any case, I do think it's worth having a dead-easy way to fix the imports, rather than having to fuss about with grep. (And what if you could actually ship rules to transform code to the upgraded version? That would be cool...)