Split repository into library part and cmd part #2

New Issue

mrngm · 2019-09-02T13:25:52+02:00

mrngm commented

2019-09-02 13:25:52 +02:00

Typically, the main package (which becomes an executable) is situated in cmd/<executable name>: cmd/rushlink/.

Typically, the `main` package (which becomes an executable) is situated in `cmd/<executable name>`: `cmd/rushlink/`.

electricdusk commented

2019-09-06 00:19:36 +02:00

Ack. Do I also move all the other files there, or just the entrypoint (i.e. rushlink.go)?

Ack. Do I also move all the other files there, or just the entrypoint (i.e. `rushlink.go`)?

electricdusk referenced this issue from a commit

2019-09-10 17:55:50 +02:00

Use a more standardized project layout In #2, mrngm made the point that we should move to a more standardized project structure. This commit does exactly that. The new project structure is based on the repository listed at . Fixes #2.

electricdusk closed this issue

2019-09-10 17:55:51 +02:00

mrngm commented

2019-09-10 23:10:12 +02:00

Thanks for splitting the repository, but I'm reopening this because it seems you've moved more than really needed.

For example, there are exported structs and methods in internal/handlers/handlers.go. It is better to keep exported stuff out of a tree that starts with internal.

Suppose I want to write a Go program that interfaces with rushlink. I'm not interested in the binary (that's why the main package is now neatly defined in cmd/rushlink/), but I do want access to, for example, StoredPaste. It's counterintuitive (non-idiomatic) to import packages that have internal in their path, when the importing package is not part of rushlink.

Thanks for splitting the repository, but I'm reopening this because it seems you've moved more than really needed. For example, there are exported structs and methods in `internal/handlers/handlers.go`. It is better to keep exported stuff out of a tree that starts with `internal`. Suppose I want to write a Go program that interfaces with `rushlink`. I'm not interested in the binary (that's why the `main` package is now neatly defined in `cmd/rushlink/`), but I do want access to, for example, `StoredPaste`. It's counterintuitive (non-idiomatic) to import packages that have `internal` in their path, when the importing package is not part of `rushlink`.

mrngm reopened this issue

2019-09-10 23:10:13 +02:00

mrngm commented

2019-09-10 23:12:11 +02:00

Another thing pkg/gobmarsh has a pkg/ too many. See https://golang.org/doc/effective_go.html#package-names for some hints on package names; brevity is one of them.

Another thing `pkg/gobmarsh` has a `pkg/` too many. See https://golang.org/doc/effective_go.html#package-names for some hints on package names; _brevity_ is one of them.

electricdusk referenced this issue from a commit

2019-09-15 17:43:21 +02:00

Move packages out of dirs Fixes #2

electricdusk closed this issue

2019-09-15 17:43:21 +02:00

electricdusk referenced this issue from a commit

2019-09-15 18:20:56 +02:00

Move packages out of dirs Fixes #2

Sign in to join this conversation.