Contributing to golang based project on github - collaboration best practice

[Nicholas Yue]

Hi,

  I am relatively new to golang coming from a C++/Python world.

  When contributing to C++/Python projects on GitHub, I usually fork the project, make changes to hit and submit a pull request to the author/maintainer.

  I found that the above didn't work for me.

  I am hoping to contribute to the following project

https://github.com/scipipe/scipipe

  

  I am trying to ascertain if my challenges is because Golang has specific ways for contribution or the above project is setup differently. I can't tell as I am new to Golang.

  I clone the forked project to $HOME/go/src/github/scipipe and testing it in another directory. I found that whenever I run my small test program, it pulls from some archive rather than my cloned repository and hence is not able to see the changes I made.

  Is there some special way to import the module so that it picked my clone directory rather than pulling down a zip archive versioned copy ?

```

package main

import (

// Import the SciPipe package, aliased to 'sp'

sp "github.com/scipipe/scipipe"

)

func main() {

// Init workflow with a name, and max concurrent tasks

wf := sp.NewWorkflow("hello_world", 4)

// Initialize processes and set output file paths

hello := wf.NewProc("hello", "echo 'Hello ' > {o:out}")

world := wf.NewProc("world", "echo $(cat {i:in}) World >> {o:out}")

// Connect network

world.In("in").From(hello.Out("out"))

wf.Nicholas() // Failed to find this new exported function I added

}

```

Cheers

[Shulhan]

> On 3 Feb 2021, at 10.17, Nicholas Yue <yue.ni...@gmail.com> wrote:
>
> Hi,
>
> I am relatively new to golang coming from a C++/Python world.
>
> When contributing to C++/Python projects on GitHub, I usually fork the project, make changes to hit and submit a pull request to the author/maintainer.
>
> I found that the above didn't work for me.
>
> I am hoping to contribute to the following project
>
> https://github.com/scipipe/scipipe
>
> I am trying to ascertain if my challenges is because Golang has specific ways for contribution or the above project is setup differently. I can't tell as I am new to Golang.
>
> I clone the forked project to $HOME/go/src/github/scipipe and testing it in another directory. I found that whenever I run my small test program, it pulls from some archive rather than my cloned repository and hence is not able to see the changes I made.
>
> Is there some special way to import the module so that it picked my clone directory rather than pulling down a zip archive versioned copy ?
>

Inside the go.mod file in your test directory, add the "replace" directive. Something like this may works,

----
module mytestmodule

replace github.com/scipipe/scipipe => ../path/to/your/clone
----

More on Go modules,

* https://blog.golang.org/using-go-modules
* https://golang.org/ref/mod

[Volker Dobler]

You either have to use the "replace" directive in go.mod, or:

Do not work on the fork. Do your work on a plain _clone_ of the

repo (which works without "replace"ing dependencies).

To create a Github PR: git push to your fork (add it as an additional

git remote) and create the PR. The "fork" is just a vehicle for a

Github PR and nothing you do work on (or try to build).

V.

[Adrian Ho]

On 3/2/21 2:21 pm, Volker Dobler wrote:
> To create a Github PR: git push to your fork (add it as an additional
> git remote) and create the PR. The "fork" is just a vehicle for a
> Github PR and nothing you do work on (or try to build).
>

For a concrete example of what Volker's talking about, see the `git`
commands and general workflow in Homebrew's docs on creating pull
requests: https://docs.brew.sh/How-To-Open-a-Homebrew-Pull-Request

--
Best Regards,
Adrian

[Nicholas Yue]

Thank you for the different approaches.

I have settled on the go.mod approach as proposed by Shulhan.

Cheers

[Sachin maurya]

I think this post might help

https://penthaa.medium.com/contributing-to-open-source-go-projects-on-github-a-recipe-to-clone-forked-go-repos-4b52a1b36489

[Amnon]

This needs to be updated for post-GOPATH modules.