A few questions by a newby mostly about initial structure

Getting Help
2

Hi @Reg,

Welcome to Go :slight_smile:

Let me try giving some answers.

Q1:

I am not useing a “split GOPATH” myself, so I cannot advise on this, nor did I find a suitable answer on the net. My personal feeling is that a two-part GOPATH would not provide additional benefit to using vendoring. But that’s just my point of view, not backed by any practical experience with this combination.

Q2:

There is a thread here in the forum that seems to summarize the question very well. (TL;DR: flatten the vendor directory. Use vendoring only for main projects, not for libraries.)

Q3:

I certainly cannot speak for all of the community, but I have seen others proposing the following approach:

  • If your project is a library, put the library packages at top level and move any commands that you might add to your library to a subfolder, e.g. cmd.

    E.g., if your library project is named mylib and has a sub-package server, then put the mylib package on top, and any sub-packages and any commands beneath:

                ├── mylib
            │   ├── mylib.go
            │   ├── asubpackage
            │   │├── http.go
            │   │└── server.go
            │   ├── cmd
            │   │   └── cmdone
            │   │       └── main.go
            │   │   └── cmdtwo
            │   │       └── main.go
            │   │   └── vendor

Here you get a library that can be imported as diycs/mylib, and two commands named cmdone and cmdtwo.

  • If your project is an executable, put the main package at the top of the project.

                ├── myexec
            │   ├── main.go
            │   ├── anothermainpkgfile.go
            │   └── somepackage
            │   │ ├── somepackage.go
            │   ├── someotherpkg
            │   │├── http.go
            │   │└── server.go
            │   └── vendor

This creates a command named myexec that uses the two packages somepackage and someotherpkg for itself.

Q4:

Go has support for auto-generating documentation from source files. If the documentation you write belongs to the package as a whole, you can put it in a separate file named doc.go (but this is optional). See this post on the Go blog for an introduction to Go documentation.

I have no idea why LiteIDE creates a doc.go file by default. Maybe they simply want to enforce proper documentation behavior. :slight_smile:

5 Likes