A few reasons as to why we would use 'pkg', to make sure they are captured:
- Approval for working on open source projects may be easier it it's a smaller number of repos
- go imports use the last part of the path as the import name as best practice, so either we would need a package called 'log' in the top level of the repo, which is greedy, or 'go-log', which misses the best practice.
A common method to address the second one is to use an alias server, e.g., gopkg.anz.com/log is a static website with a go get redirect to github.com/anz-bank/log.go or something similar.
The potential downside for using a monorepo for packages is that we end up creating a standard set of libraries which are interdependent and need to be versioned together (as two separate issues possibly?). E.g., if we wrote a 'httpLib' here which logged, it would probably use the pkg/log library. We might add a 'trace' package which the logger and httpLib know to check for certain IDs, then an errors package which httpLib knows to inspect for 'http specific' errors, etc etc. That pattern allows you to create a whole 'world' in which we work, a whole new basis for writing go code, and effectively creates our own highly opinionated ecosystem of go, independent from the wider go community.
I see this as a 'bad thing', but maybe it's not, and maybe that's exactly what we want to create, so raising it here as a ticket so that it's explicitly discussed and decided, rather than accidentally done to solve unrelated problems with go packaging and ANZ policy.
A few reasons as to why we would use 'pkg', to make sure they are captured:
A common method to address the second one is to use an alias server, e.g., gopkg.anz.com/log is a static website with a go get redirect to github.com/anz-bank/log.go or something similar.
The potential downside for using a monorepo for packages is that we end up creating a standard set of libraries which are interdependent and need to be versioned together (as two separate issues possibly?). E.g., if we wrote a 'httpLib' here which logged, it would probably use the pkg/log library. We might add a 'trace' package which the logger and httpLib know to check for certain IDs, then an errors package which httpLib knows to inspect for 'http specific' errors, etc etc. That pattern allows you to create a whole 'world' in which we work, a whole new basis for writing go code, and effectively creates our own highly opinionated ecosystem of go, independent from the wider go community.
I see this as a 'bad thing', but maybe it's not, and maybe that's exactly what we want to create, so raising it here as a ticket so that it's explicitly discussed and decided, rather than accidentally done to solve unrelated problems with go packaging and ANZ policy.