On Wed, 2024-02-14 at 03:12 -0800, Jerry Londergaard wrote:
> I see quite a few modules out there where they seem to be putting in
> as little into the main package as possible. Literally they will
> sometimes be a few lines:
> ```
> import foobar
> func main() {
> os.Exit(foobar.Run())
> }
> ```
> Yet then go on to do all the things I would've thought are the domain
> of a main package, in the foobar package, like arg parsing, pulling
> in config items from env vars, setting up deps etc, and then running
> the actual thing.
>
> Why not just put that code into the actual main package? Sure, maybe
> not all into the main *function* itself, but in the main package at
> least.
>
> I understand that you don't want to be putting any real business
> logic into that main package, but I'm just talking about entry point
> type specific stuff. People might say they want to keep main 'light',
> but sometimes it feels like it's a competition to have the fewest
> lines as possible in the main package.
>
> kube-proxy[1] is an example of this. Maybe this starts to make more
> sense when the amount of code you would be putting into main become a
> lot, kube-proxy may qualify for this, but I see other cases where I
> don't understand the reasoning.
>
> Certainly not all are like that[2], but in some circles that I travel
> it seems to be a common way of thinking.
>
> Am I missing something ?
>
This can be used for testing the complete application.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/0f07a7e73982c48ed8f77cf6b5d2b32c71e807d2.camel%40kortschak.io.
