5 ms·

It would be great if go.mod file’s replace directive also supported a replace that applies to all downstream users (url to url , not just url to local path) Thi

by harikb 5y ago

It would be great if go.mod file’s replace directive also supported a replace that applies to all downstream users (url to url , not just url to local path) This would allow us to maintain simple forks (ones where you are only fixing a few lines and awaiting PR approval to upstream) but still don’t want to wait for the whole cycle to finish for your own internal company dependencies. I feel this is better than changing all imports. If you are truly forking with no intention to merge back, isn’t the manual find-and-replace by IDE just fine?

xyzzy_plugh 5y ago
The replace directive does allow you to use a different import path, not just a local path. Unless there's something I'm missing about your use case? https://golang.org/ref/mod#go-mod-file-replace https://golang.org/ref/mod#go-mod-file-replace
- harikb 5y ago
  Oh I never knew! Thanks. That does simplify a lot
- tsimionescu 5y ago
  It's important to note that it still doesn't apply to downstream users (those adding your package to their go.mod), only to those building your package directly. I think this decision makes sense, so this is not a complaint.
  - caust1c 5y ago
    Can you elaborate? We use `replace` everywhere in our codebase for modules that we've forked + modified.
    - tsimionescu 5y ago
      Assume module A depends on module B, and module B has a dependency on module github.com/C, and a replace rule for github.com/C => company.internal/C. When you build module A, it will pull module B and module github.com/C, instead of B and company.internal/C, unless A has its own replace directive for C.
CGamesPlay 5y ago
The problem I had was that I was forking a monorepo package, so I had to update its internal dependencies to point to the new place. It's possible I missed something, but I don't think I was able to do this with go.mod. And yes, manually doing the rename "is fine", but I don't think that has any reason to be stated in a discussion about a refactoring tool.
- silasdavis 5y ago
  > I don't think that has any reason to be stated in a discussion about a refactoring tool. Find and replace is the baseline, and for many refactorings is insufficient and fragile, however in replacing a stable, unique, and isomorphic token it is basically as good as it gets, so I think it is relevant. Its probably the least useful thing a refactoring tool could do.
  - CGamesPlay 5y ago
    I am not sure. You want to make sure that you are only modifying import statements and those can’t necessarily be identified from just a single line (else you might change an errant URL in a string literal), and you also need to move the files themselves, and update the package line in the files. So sure, you can do it yourself, but why are we building a refactoring tool at all?
    - johnmaguire 5y ago
      Not to mention if the package name itself changes...

by harikb 5y ago

xyzzy_plugh 5y ago

The replace directive does allow you to use a different import path, not just a local path. Unless there's something I'm missing about your use case? https://golang.org/ref/mod#go-mod-file-replace https://golang.org/ref/mod#go-mod-file-replace

harikb 5y ago
Oh I never knew! Thanks. That does simplify a lot
tsimionescu 5y ago
It's important to note that it still doesn't apply to downstream users (those adding your package to their go.mod), only to those building your package directly. I think this decision makes sense, so this is not a complaint.
- caust1c 5y ago
  Can you elaborate? We use `replace` everywhere in our codebase for modules that we've forked + modified.
  - tsimionescu 5y ago
    Assume module A depends on module B, and module B has a dependency on module github.com/C, and a replace rule for github.com/C => company.internal/C. When you build module A, it will pull module B and module github.com/C, instead of B and company.internal/C, unless A has its own replace directive for C.

CGamesPlay 5y ago

The problem I had was that I was forking a monorepo package, so I had to update its internal dependencies to point to the new place. It's possible I missed something, but I don't think I was able to do this with go.mod. And yes, manually doing the rename "is fine", but I don't think that has any reason to be stated in a discussion about a refactoring tool.

silasdavis 5y ago
> I don't think that has any reason to be stated in a discussion about a refactoring tool. Find and replace is the baseline, and for many refactorings is insufficient and fragile, however in replacing a stable, unique, and isomorphic token it is basically as good as it gets, so I think it is relevant. Its probably the least useful thing a refactoring tool could do.
- CGamesPlay 5y ago
  I am not sure. You want to make sure that you are only modifying import statements and those can’t necessarily be identified from just a single line (else you might change an errant URL in a string literal), and you also need to move the files themselves, and update the package line in the files. So sure, you can do it yourself, but why are we building a refactoring tool at all?
  - johnmaguire 5y ago
    Not to mention if the package name itself changes...