Re: [go-nuts] Trying to understand aversion to main package
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.
[go-nuts] Trying to understand aversion to main package
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 ?
1.
https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-proxy/proxy.go
2. https://github.com/ethereum/go-ethereum/blob/master/cmd/geth/main.go
--
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/e7b6de50-0351-4d2e-83a9-2207ba04b68an%40googlegroups.com.
