File organization in a github-ed Go project

[Basile Starynkevitch]

Hello All,

I'm writing my first Go program, it is on GitHub monimelt  and I'm specifically talking of the commit 15a7fbc61e141d62655 (master branch). See this question for more details and motivations. So I am not very familiar with Go. I'm using Go 1.8 on Debian/Linux/x86-64

I understood it is better to have each package in its own directory (that directory would often contain one or more *.go files implementing the package, and probably one or more *_test.go tests; I don't mention the tests files here....).

So I have a package serialmo mostly in file serial/serialmo.go and that package (from my point of view, a "leaf" package) only depends on standard Go packages (like  "crypto/rand", "fmt" etc...)

I also have a package objvalmo mostly in file objval/objvalmo.go and that package depends on the previous serialmo.

However, I had to code there

package objvalmo
import (
    "fmt"
    serialmo "github.com/bstarynk/monimelt/serial"
    "runtime"
    "sync"
    "unsafe"
)

and I find very inconvenient to have to mention the path "github.com/bstarynk/monimelt/serial" in the source code, notably because if someone wants to fork my github project, he would have change my username bstarynk/ by his own one in every package path like "github.com/bstarynk/monimelt/serial"

I tried (and I would prefer) to code

   serialmo "../serial"

but that does not work.

I'm certainly doing things very wrong. What did I missed? I'm using the go tool to compile stuff.

Thanks for reading and for your help. Regards.

Basile Starynkevitch (France)  http://starynkevitch.net/Basile/

[C Banning]

Try organizing your project as:

monimelt

src

cmd (or "monimelt", if there's just one app)

objvalmo

serial 

 

 Then include $HOME/monimelt in your GOPATH.

[Basile Starynkevitch]

 
Thanks for the suggestion.

BTW, I did commit in bbc5c3789788 the change of using directory names same as package names. So I have monimelt/objvalmo/objvalmo.go & monimelt/serialmo/serialmo.go files (implementing packages objvalmo & serialmo respectively)

But does that avoid me to have to use long paths in import directives? Would that allow me to code import "serialmo" instead of import "github.com/bstarynk/monimelt/serialmo" in my file objvalmo.go (to ease the forking of my github project)?

Regards

--
Basile Starynkevitch

[Dave MacFarlane]

If someone wanted to fork your library for one of their programs, they could also vendor the package with their changes until it's changed significantly enough that they think it's worth updating to its own namespace (and at that point, it really should be a different import path..)

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

- Dave

[brainman]

> if someone wants to fork my github project, he would have change my username bstarynk/ by his own one in every package path

When I contribute to other people's projects on Gitub, I just "go get" their package, and adjust my "git remote" settings for the package so can push all my changes into my Github fork instead. Something like http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html or https://splice.com/blog/contributing-open-source-git-repositories-go/

Alex

[Basile Starynkevitch]

Actually I did that (adding $HOME/monimelt to my GOPATH)  and now I am simply importing "serialmo"

BTW, I am beginning to believe that I could drop the go tool and use gb build tool instead.

[Diego Medina]

Note that if you write a project that other users would use, you will force them to update their $GOPATH to make your app work.

Which I think it a lot worse than making people who fork your project update the import path And like someone else said, if I need to fork a project, I most likely already vendor the dependency, so I simply make small changes to the file(s) in the vendor folder

Thanks

Diego

[oju...@gmail.com]

That is by design. All import paths should be complete, absolute paths, and that is enforced as much as possible.

When somebody moves or copy a file to another directory structure, the program behaviour is preserved, even if by chance there is a similarly named package nearby.

If "../serial" was allowed, the semantics would be "import any package called serial that happens to be found in a sibling directory". By using the full path you are stating "I want Basile Starynkevitch's serial package. Refuse imitations!"