-2

I'm working on an open source Go app. Let's call it "projectA". In it there're multiple packages - "pack1", "pack2" ... "packN". I've forked the repo. I have import like these:

import (
  "go_package1"
  "go_package2"
  //........

  "github.com/some_user/projectA/package1"
  "github.com/some_user/projectA/package2"
  "github.com/some_user/projectA/package3"
)

accross the code.

I want to temporarily replace or re-point all these imports to "github projectA" such that they point to my fork on github as I'm working on it. Otherwise, I won't see changes that I make in these packages because they'll point to the original repo "projectA".

But, it should be in a smart way somehow, such that a PR that I'll make to "projectA" will contain the origin imports.

Or perhaps it could be via local imports somehow?

How can I do that?

iperforranda
  • 1
  • 1
  • 2
    It is dead simple: Never fork a repo. A fork produces something completely different for Go which in general (there are simple cases which do work) do **not** work. Clone the repo, work on the clone (typically on a branch) and add your fork as an additional remote so you can push and have a merge request sometime. To include the local clone: Use a replace directive in go.mod. To repeat: You **cannot** work on a Github fork. It does not matter how hard you try or whatever clever trick you think of. It is clone and add your fork as a remote. – Volker Oct 31 '19 at 04:21
  • @Volker how will I specify a certain branch then in the imports -- a brach which I'm working on? – iperforranda Oct 31 '19 at 04:23
  • 1
    You simply check out that branch and add a `replace full/module/import/path => /your/local/filesystem/path/to/your/clone` so go build will use what is on your disk (no matter what branch). – Volker Oct 31 '19 at 04:29
  • @Volker how will that be superior to manually replacing all the imports to point to my fork at github? namely -> `"github.com/my_user/projectAFork/package1"` – iperforranda Oct 31 '19 at 04:32
  • Manually replacing import paths just replaces import path but does not change _everything_ which _might_ be needed (e.g. if a package does magic via reflection). Package identity is complicated and what I described works perfectly in each and every case. Manually replacing import paths might work or might not work and good look finding the error if it doesn't work: You need _very_ good understanding of a lot of Go internals in this case. – Volker Oct 31 '19 at 06:30
  • @Volker why not do instead 1) "go get "github.com/some_user/projectA/package1" 2) and work on the project in ~/go/src/github.com/projectA ? – iperforranda Oct 31 '19 at 06:34
  • What you describe as an alternative is exactly what I told you to do: go get makes a clone and you work on the clone. So there is no answer to your question "why not?" What is the actual problem you encounter? Is there a reason you try to come up with lots of different or even identical ideas instead of doing simply what works? – Volker Oct 31 '19 at 06:42
  • @Volker thx.......... – iperforranda Oct 31 '19 at 07:28
  • @Volker I don't have a push access at all to the open source repo. Only via my fork am I able to create a Push Request. Therefore, I have to use my fork. – iperforranda Oct 31 '19 at 07:31
  • No!! Stop it! You do all your work on the clone. And of course you can push to your fork or wherever you like, that is totally unrelated. It is "clone and work on clone!" If you need a fork: make it via Github GUI and add your fork as an additional remote and push to that or wherever you like. But this fork is nothing your Go code **ever** even touches. It is totally unrelated. It does not matter where you push your code or from where you pull or whom you send patches, that is up to you. Just never try to do Go-related stuff on a fork!! – Volker Oct 31 '19 at 08:06
  • @Volker No!!! I will!!! I will fork it!!! And work on a fork – iperforranda Oct 31 '19 at 08:28
  • Good luck then. – Volker Oct 31 '19 at 08:46
  • @Volker thank you!!! I've already forked it and I enjoy working with a fork! – iperforranda Oct 31 '19 at 08:48
  • @Volker yes!! You've also noticied that??? – iperforranda Oct 31 '19 at 09:42

1 Answers1

-1

An hack for the situatuion, is to clone the repository in you personal github account, than initialize a new go module that point to your "forked" repo with go mod init github.com/yourname/yourrepo. By this way you can work-and-push to your repository, than (after a merge from the author) you can easily swap the import

alessiosavi
  • 2,753
  • 2
  • 19
  • 38