FAQ
Hi.

After some experiments I have decided that, for me, Go is a good substitute
for C and Python.
Since I writing some projects in Go I would like to choose one project
layout guideline
and stick with it.

Official go documentation only imposes one requirement on project layout:
it must be
go get-able.
This means that the layout used by the go compiler itself is no good.

I have these additional requirements:

1) The project top level directory must be clean; it must no contain source
     code, but only project metadata (license, readme) and some
subdirectories.

2) I'm very bad at choosing names, and since I also work in C and Python,
     I want to be sure there are no possible name clash.

Currently I'm thinking to use the following layout:

- The package name is go.<prj> or go-<prj>.
    I don't like go<prj>.
   An alternate prefix is golang, but it is longer.

- There is no source code in the top level directory.
    Go packages are in subdirectories.

    This means one additional path element, but it should not be a problem.

- Commands go in the cmd subdirectory.

As an example:

go.foo
   LICENSE
   README
   doc/
   misc/
   cmd/
   foo/

foo package is imported as:
   import "github.com/perillo/go.foo/foo"


Feedback will be appreciated.

Thanks Manlio Perillo

--
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.

Search Discussions

  • Konstantin Khomoutov at Dec 18, 2014 at 1:45 pm

    On Thu, 18 Dec 2014 05:22:28 -0800 (PST) Manlio Perillo wrote:

    After some experiments I have decided that, for me, Go is a good
    substitute for C and Python.
    Since I writing some projects in Go I would like to choose one
    project layout guideline
    and stick with it.
    [...]

    Please consider reading
    http://golang.org/doc/code.html#Organization
    http://blog.golang.org/organizing-go-code
    https://github.com/golang/go/wiki/GithubCodeLayout
    http://stackoverflow.com/a/14870666/720999

    --
    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.
  • Manlio Perillo at Dec 18, 2014 at 2:07 pm
    Il giorno giovedì 18 dicembre 2014 14:45:24 UTC+1, Konstantin Khomoutov ha
    scritto:
    On Thu, 18 Dec 2014 05:22:28 -0800 (PST)
    Manlio Perillo <manlio....@gmail.com <javascript:>> wrote:
    After some experiments I have decided that, for me, Go is a good
    substitute for C and Python.
    Since I writing some projects in Go I would like to choose one
    project layout guideline
    and stick with it.
    [...]

    Please consider reading
    http://golang.org/doc/code.html#Organization
    Of course it was one of the first documents I read, but it only speaks
    about code organization in a workspace, not about code organization in
    a project.

    I have read this, but it is not very specific about possible project layout
    guidelines/

    All these documents talk about is how to organize code inside a go
    workspace.


    Thanks Manlio

    --
    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.
  • Konstantin Khomoutov at Dec 18, 2014 at 2:29 pm

    On Thu, 18 Dec 2014 06:07:55 -0800 (PST) Manlio Perillo wrote:
    After some experiments I have decided that, for me, Go is a good
    substitute for C and Python.
    Since I writing some projects in Go I would like to choose one
    project layout guideline
    and stick with it.
    [...]

    Please consider reading
    http://golang.org/doc/code.html#Organization
    [...]
    All these documents talk about is how to organize code inside a go
    workspace.
    Supposedly we have different perception, but IMO they discuss project
    organisation because if you you the `go build|install` tool this
    organisation is indistinguishable from workspace organization.

    Said in more words, when it comes to the `go` tool, there's no such
    thing as, say, a library "private" to your project: all libraries and
    project inside a workspace are equal, but you might "namespace" your
    "private" libraries -- by maintaining them under the directory of your
    project and using appropriate import paths. This is demonstrated, for
    instance, here [1]. Here, the only difference from "Github code layout"
    is that your internal libraries won't be at the top level of a workspace
    but rather inside the project's directory -- with their import paths
    properly adjusted.

    1. http://stackoverflow.com/a/15051192/720999

    --
    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.
  • Lars Seipel at Dec 18, 2014 at 5:37 pm

    On Thu, Dec 18, 2014 at 06:07:55AM -0800, Manlio Perillo wrote:
    Of course it was one of the first documents I read, but it only speaks
    about code organization in a workspace, not about code organization in
    a project.
    This one from Dave should apply:
    http://dave.cheney.net/2014/12/01/five-suggestions-for-setting-up-a-go-project

    --
    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.
  • Manlio Perillo at Dec 18, 2014 at 6:27 pm

    On Thu, Dec 18, 2014 at 6:37 PM, Lars Seipel wrote:
    On Thu, Dec 18, 2014 at 06:07:55AM -0800, Manlio Perillo wrote:
    Of course it was one of the first documents I read, but it only speaks
    about code organization in a workspace, not about code organization in
    a project.
    This one from Dave should apply:

    http://dave.cheney.net/2014/12/01/five-suggestions-for-setting-up-a-go-project

    Again (I suspect I have not explained myself correctly):
    all go tools are interested about, and all these documents talk about is
    how to organize *source* code.

    However a project does not contains only source code, but
    (possibly several) other files, and I'm seeking the best way
    to organize the *entire* project files so that all files are well organized.

    About Dave suggestions, this phrase
    "Package names, and thus the package’s directory, should contain only
    letters, numbers if you must, but absolutely no punctuation."
    is incorrect.

    The package directory name can be different from the go package name, and
    it can contain
    punctuations, as it is done by http://gopkg.in.


    P.S.:
    sorry for the double message, but I always forget that by default gmail
    does not do a reply to all.


    Thanks Manlio Perillo

    --
    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.
  • Jason Gade at Dec 18, 2014 at 6:45 pm

    On Thursday, December 18, 2014 10:27:38 AM UTC-8, Manlio Perillo wrote:
    On Thu, Dec 18, 2014 at 6:37 PM, Lars Seipel <lars....@gmail.com
    <javascript:>> wrote:
    On Thu, Dec 18, 2014 at 06:07:55AM -0800, Manlio Perillo wrote:
    Of course it was one of the first documents I read, but it only speaks
    about code organization in a workspace, not about code organization in
    a project.
    This one from Dave should apply:

    http://dave.cheney.net/2014/12/01/five-suggestions-for-setting-up-a-go-project

    Again (I suspect I have not explained myself correctly):
    all go tools are interested about, and all these documents talk about is
    how to organize *source* code.

    However a project does not contains only source code, but
    (possibly several) other files, and I'm seeking the best way
    to organize the *entire* project files so that all files are well
    organized.
    If the concern is for a clean project directory structure, why not create a
    clean GOPATH for each project?

    You could even create a template directory with commonly-used packages
    already installed.

    --
    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.
  • Jan Mercl at Dec 18, 2014 at 1:48 pm

    On Thu Dec 18 2014 at 14:22:35 Manlio Perillo wrote:

    Feedback will be appreciated.
    Subjective suggestions:

    - Namely if the project is a single command or a single project, put the
    source right into the root. The import path is then eg. "
    github.com/use/project" with no extra noise.
    - Do not use any prefix unless unavoidable because of a clash with existing
    well known name which the user might have already in the $PATH. (eg.
    "asdfg" is a name probably w/o a need to be prefixed, OTOH "ls" should be
    prefixed if the intent is not to replace the common one in /bin.)
    - Do not use punctuation in the import path.
    - Use all lower case letters in the import path.

    -j

    --
    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.
  • Chris dollin at Dec 18, 2014 at 1:57 pm
    On 18 December 2014 at 13:48, Jan Mercl wrote:

    *nitpick*
    - Do not use punctuation in the import path.
    Did you mean something less all-encompassing? Slash is
    both common in import paths and I would have counted it as
    a punctuation character.

    Chris

    --
    Chris "allusive" Dollin

    --
    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.
  • Jan Mercl at Dec 18, 2014 at 2:02 pm
    On Thu Dec 18 2014 at 14:57:41 chris dollin wrote:
    On 18 December 2014 at 13:48, Jan Mercl wrote:

    *nitpick*
    - Do not use punctuation in the import path.
    Did you mean something less all-encompassing? Slash is
    both common in import paths and I would have counted it as
    a punctuation character.
    Yeah, you're right. I should have written "punctuation in the base name of
    the import path". Most commonly seen in the wild is probably [.-]. It
    forces the user to use the `ident stringlit` clause which I consider a bad
    idea.

    -j

    --
    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.
  • Manlio Perillo at Dec 18, 2014 at 2:15 pm
    Il giorno giovedì 18 dicembre 2014 14:48:17 UTC+1, Jan Mercl ha scritto:
    On Thu Dec 18 2014 at 14:22:35 Manlio Perillo <manlio....@gmail.com
    <javascript:>> wrote:
    Feedback will be appreciated.
    Subjective suggestions:

    - Namely if the project is a single command or a single project, put the
    source right into the root. The import path is then eg. "
    github.com/use/project" with no extra noise.
    No, please.
    If the single command requires several source files, its going to pollute
    the project top level directory.
    Since I want to use one *fixed* code layout, I don't want to make special
    cases.
    Moreover a command may take only one source file today, but may grow in
    future.

    - Do not use any prefix unless unavoidable because of a clash with
    existing well known name which the user might have already in the $PATH.
    (eg. "asdfg" is a name probably w/o a need to be prefixed, OTOH "ls" should
    be prefixed if the intent is not to replace the common one in /bin.)
    The problem is that I *do not know* if there is a possible clash.
    Note that I'm talking about name clash with a possible reimplementation of
    a go project in a different
    programming language written by me.

    As a real example, I'm writing a project with support for the ANT network.
    The project target is a PC, but in future I may want to support a SoC, and
    will need
    to rewrite the project in C, with some changes.

    - Do not use punctuation in the import path.
    Any specific reason?
    I don't remember this is specified in any of the official documents.

    - Use all lower case letters in the import path.
    This is ok.

    -j
    Thanks Manlio Perillo

    --
    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.
  • Luna Duclos at Dec 18, 2014 at 3:12 pm
    I don't understand why you consider go files in the root "polution" ?
    On Thu, Dec 18, 2014 at 3:15 PM, Manlio Perillo wrote:

    Il giorno giovedì 18 dicembre 2014 14:48:17 UTC+1, Jan Mercl ha scritto:
    On Thu Dec 18 2014 at 14:22:35 Manlio Perillo <manlio....@gmail.com>
    wrote:
    Feedback will be appreciated.
    Subjective suggestions:

    - Namely if the project is a single command or a single project, put the
    source right into the root. The import path is then eg. "
    github.com/use/project" with no extra noise.
    No, please.
    If the single command requires several source files, its going to pollute
    the project top level directory.
    Since I want to use one *fixed* code layout, I don't want to make special
    cases.
    Moreover a command may take only one source file today, but may grow in
    future.

    - Do not use any prefix unless unavoidable because of a clash with
    existing well known name which the user might have already in the $PATH.
    (eg. "asdfg" is a name probably w/o a need to be prefixed, OTOH "ls" should
    be prefixed if the intent is not to replace the common one in /bin.)
    The problem is that I *do not know* if there is a possible clash.
    Note that I'm talking about name clash with a possible reimplementation of
    a go project in a different
    programming language written by me.

    As a real example, I'm writing a project with support for the ANT network.
    The project target is a PC, but in future I may want to support a SoC, and
    will need
    to rewrite the project in C, with some changes.

    - Do not use punctuation in the import path.
    Any specific reason?
    I don't remember this is specified in any of the official documents.

    - Use all lower case letters in the import path.
    This is ok.

    -j
    Thanks Manlio Perillo

    --
    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.
    --
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedDec 18, '14 at 1:22p
activeDec 18, '14 at 6:45p
posts12
users7
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase