Let me explain my situation.
I'm making a website and uses some very advanced functionality. It includes
a front-end wasm module, a daemon (written in GoLang), nginx configuration,
some PHP, and some haml, and sass. I have written a makefile to build
everything into 1) ELF binary (the daemon), 2) a wasm binary, 3) an 'ext'
directory (which holds images and other large static files for the website)
and 4) and PHAR archive (which holds all html and PHP). Needless to say,
the makefile is very useful. The repository holding all of this looks like
this:
daemon/
build/
doc/
etc/
scripts/
tests/
wasm/
website/
makefile
As you can tell, all major component has its own directory and is neatly
laid out.
This layout traditionally worked for other projects that utilized other
languages such as C, C++, Javascript, and Python. However, with GoLang, its
aggressive use of GOPATH causes an architectural problem I'm running into
regarding the daemon and wasm. You see, both the daemon and wasm module are
built using packages that are exclusive to their respective binaries. For
instance,
files in ~/projects/project1/
daemon/
- main.go
- package1/
- package2/
wasm/
- main.go
- package3/
- package4/
This would not be a problem, as the make file can appened GOPATH to include
the packages in the respective components. Unfortunately, GOPATH requires a
directory exactly named "src" to be present... thus makes the building
impossible by traditional means. Thus I see only a few exact workarounds...
A) Renaming my "~/projects" folder to "~/src" making this possible:
import "project1/daemon/package1"
B) Adding "src" to each component:
daemon/
- src/
- package1/
- package2/
daemon/src/main.go:
import "package1"
C) Using symlinks
daemon/
- main.go
- package1/
- package2/
- src -> ./
D) Throwing all golang components into a src dir at the project root dir
src/
- daemon/
- wasm/
build/
doc/
etc/
scripts/
tests/
website/
makefile
E) Relative package include
import "./package1"
Reasons why I hate all of these solutions:
A - Renaming my projects directory to simply "src" makes the directory
makes it misleading. I have many other things besides just source code in
that directory. I'm very organized as you can tell.
B - Its just another sub directory I have to enter in order to get to the
code I need to edit. Every time I'm navigating through the project it's
going to force me to use an extra "../" or an extra "src/". The flatter the
file system, the easier it is to navigate (in this case).
C - This works for the most part. But this monstrosity of a work-arounds
usually makes my IDEs sh*t the bed when trying to index code.
D - Having a "src" directory listed in the project's root directory would
be misleading. As there's source code in website/, scripts/, and maybe etc/
and tests/, thus all would technically need to be in that "src"
directory... complicating the file structure and adding unnecessary depth.
I would be more attuned to this if I could use a "go-src" directory. But I
can't.
E - This one is definitely the go-to. Unfortunately, I'm using TinyGo to
compile the WASM module, and it does not support relative imports. I
contact the team why, and they said the support is on the backlog but also
that relative imports were not "best practice". So I'll agree with that
until I'm told otherwise.
My gripe:
I get that Go's design is deliberately simple. And forcing things like
syntax and naming standards in the actual code makes it more readable and
simple for all... which is Go's best quality. However, when attempting to
have the same mindset with the file structure does the exact opposite.
GOPATH and GOROOT are always the hardest concepts to understand for new
learners, and I've been using go for a good year and I still don't
completely understand the purpose of go modules (I know it was an effort to
ease the GOPATH requirements for new learners).
It's almost like in order to use Go you'd have to reconfigure your
operating system's normal file structure. It is such a pain and goes
against the fundamental simplicity of go. It's even more strange that Go
builds into native binary when the source files are in the most non-native
locations, ie everything in "/usr/local/go/src/" should be in
"/usr/local/include/go/". Go seems to be trying to install its philosophy
on my whole computer and I don't like it.
Anyways:
Does anyone have any thoughts as to what I should do? Or is this project
structure just invalid? Also, project goals are as follows:
1. Must work with `make build`, `make test`, and `make install`
2. Must be able to be put into a `deb` package
3. Must be optimal inside a git repository (ie, do not track binaries)
4. As few directories as possible (Occam's file system)
Thanks Guys and Gals.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/63c1cfc7-4ad8-4ecd-80ad-ba85d01995a3%40googlegroups.com.
