CODEWITHSUNDEEP
go
Alec Mev
Alec Mev

Reputation: 4813

Storing a Go project with other non-Go projects

When it comes to code organization, Go seem to make an assumption, that it's the only language I'm going to use. However, I'd like to treat each Go project as a yet another isolated piece of software, and store it the same way as most programs were stored for decades now - in an arbitrary directory, containing no less and no more than what is needed to build and run it.

What Go wants:

home/
├─go/
│ └─src/
│   └─some-organization/
│     └─some-go-project/
│       └─main.go
└─projects/
  └─some-organization/
    ├─some-c-project/
    │ └─src/
    │   └─main.c
    └─some-python-project/
      └─src/
        └─main.py

What I want:

home/
└─projects/
  └─some-organization/
    ├─some-c-project/
    │ └─src/
    │   └─main.c
    ├─some-python-project/
    │ └─src/
    │   └─main.py
    └─some-go-project/
      └─src/
        └─main.go

Of course, nobody prevents me from structuring it my way, but I won't be able to build/install that project the intended way anymore. Doing something like home/projects/some-organization/some-go-project/src/some-go-project/main.go to address that is just too ugly to my liking.

So what's the consensus here? How does Go community handle this? Back-to-make?

Upvotes: 4

Views: 1011

Answers (2)

Topo
Topo

Reputation: 5002

This is a complicated issue and a huge headache, but what I did to solve this issue was to do it the other way around:

home/
└─projects/
  ├bin/
  ├pkg/ 
  └─src/
    └─some-organization/
      ├─some-go-project/
      |  └─main.go
      ├─some-c-project/
      │ └─main.c
      └─some-python-project/
        └─main.py

And I use the go bin and pkg directories for binaries and libraries of all languages. The go layout is not bad, is just different and having your go code in a 'special' structure different from all your other code is kind of ugly so I prefer to adopt the go directory structure for all my projects.

As an upside, you have all your software projects classified by repo hosting site and that is nice.

Upvotes: 5

Elwinar
Elwinar

Reputation: 9519

I had the same problem, and tried the following solutions (in chronological order):

  • don't put you package in the $GOPATH and compile from your project directory: that works while you have a single-package project. Anyway, go project should have a limited number of package…
  • use a symlink from your project directory to your $GOPATH: it's really boring to have to symlink everytime you want to checkout a new project. More, the various tools asking for a package name (fmt, test, etc) won't find your package, unless you make the link the other way around, which is equally boring (even more, as it defies your git layout).
  • add a $GOPATH entry for each project (like $PATH): even more boring than the previous solution, but mostly works. Even better if your poject layout is based on a src/ directory.
  • use vagrant and a dedicated $GOPATH: you can work as intended by golang, with the added complexity of having to ssh into the box. That's what I am doing now, as it have the benefits of vagrant as a bonus.

Upvotes: 5

Related Questions