CODEWITHSUNDEEP
gocommandpackage
fields
fields

Reputation: 909

How to structure go command internals

If your writing a go command (not a package) that is large how do you layout its internals? I would love to have some utility packages etc but not have those exposed for anything except the command's code. If it's all in the same repo I don't see whats stopping someone from importing those internal use packages.

Upvotes: 1

Views: 64

Answers (2)

kostix
kostix

Reputation: 55453

You might make your utility packages internal to your package — like this. This won't prevent anyone from using them but a) why would you care anyway? b) the package's structure would give a clear hint on that these "subpackages" are internal to the project.

Upvotes: 1

Volker
Volker

Reputation: 42413

The answer is simple (but most probably not what you'd like to hear): Do whatever you like and is allowed. Having utility packages living somewhere is perfectly fine, either in the same repo as a "sub-package" or in a different repo.

Regarding

I don't see whats stopping someone from importing those internal use packages

Why do you care? If the packages encapsulate distinct and usable functionalities someone might benefit from importing them. Keeping those function together with the command does not "protect" them in the sense of "nobody should be able to look at my code". Just make it clear in the docs that you'll feel free to do incompatible changes at any time. Go is not about preventing each and any stupidity and protecting the lazy and incapable ones who deliberately ignore any documentation from shooting their foot.

Upvotes: 1

Related Questions