[go-nuts] Re: Should we stop using a global logger?

[buchanae . ohsu]

Or, what if...


type FunnelContext interface {
  context.Context
  logger.Logger
}

type RequestHandler struct {
  // No context specific fields here, instance stays reusable across 
requests
}
func (RequestHandler) Handle(ctx FunnelContext) {}

 



On Thursday, August 24, 2017 at 8:58:15 PM UTC-7, Dave Cheney wrote:
>
> > Should we stop using a global logger?
>
> Yes[1]
>
> 1. https://dave.cheney.net/2017/01/26/context-is-for-cancelation
>
> On Friday, 25 August 2017 13:38:48 UTC+10, buchan...@gmail.com wrote:
>>
>> In Funnel [1], we've been using a global logger, based on logrus [2]. 
>> This has worked fine through the early stages of the project, but it's 
>> starting to show a few cracks. In particular, we need to ensure that a 
>> request (task) ID is present in all log messages. Solutions to this have 
>> grown to be inconsistent:
>>
>> - We create a child logger instance which has the ID preconfigured, and 
>> pass that to some function calls. [3]
>> - We're looking at passing a context to logging calls, and the logger 
>> pulls the ID from context.Value. [4]
>> - Some calls have been left behind and are still using the global logger.
>>
>> Other notes:
>> - A global logger configured to a single task ID won't work, since 
>> multiple requests may be handled concurrently.
>> - Request handling spans multiple packages.
>> - We're using context extensively, we're ok with using it more.
>>
>> We're trying to decide whether to stick to a global (singleton) logger, 
>> or remove the global logger completely and start passing logger instances 
>> everywhere. I think we can make either work, and so far neither is an 
>> obvious choice. What do you think?
>>
>> Global logger:
>> - seems to be the most common approach
>> - convenient access
>> - global singleton might lead to difficulty and inflexibility, e.g. 
>> capturing logging in tests, multiple configurations
>>
>> Logger instances:
>> - more fields on every type and function that wants to log
>> - full control over logging in each individual type and function
>> - clearly stated dependencies for each type/function. I'd say Go idioms 
>> tend toward obvious, clear, and powerful over clean, concise, magic.
>>
>> A third, interesting option might be to add all logging configuration to 
>> the context using context.Value, including output, formatting, etc. Global 
>> logging functions would pull all needed config from the context. I'm 
>> worried this gets into the hotly debated territory of abusing 
>> context.Value. On the other hand, we're already passing context everywhere, 
>> and this is useful context that crosses API boundaries.
>>
>> Anywho, would love to get thoughts from the experts out there. Thanks for 
>> reading!
>>
>> Alex
>>
>>
>> [1] https://github.com/ohsu-comp-bio/funnel
>> [2] https://github.com/sirupsen/logrus
>> [3] 
>> https://github.com/ohsu-comp-bio/funnel/blob/master/worker/runner.go#L25
>> [4] https://github.com/ohsu-comp-bio/funnel/pull/194
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Should we stop using a global logger?

[buchanae . ohsu]

In Funnel [1], we've been using a global logger, based on logrus [2]. This 
has worked fine through the early stages of the project, but it's starting 
to show a few cracks. In particular, we need to ensure that a request 
(task) ID is present in all log messages. Solutions to this have grown to 
be inconsistent:

- We create a child logger instance which has the ID preconfigured, and 
pass that to some function calls. [3]
- We're looking at passing a context to logging calls, and the logger pulls 
the ID from context.Value. [4]
- Some calls have been left behind and are still using the global logger.

Other notes:
- A global logger configured to a single task ID won't work, since multiple 
requests may be handled concurrently.
- Request handling spans multiple packages.
- We're using context extensively, we're ok with using it more.

We're trying to decide whether to stick to a global (singleton) logger, or 
remove the global logger completely and start passing logger instances 
everywhere. I think we can make either work, and so far neither is an 
obvious choice. What do you think?

Global logger:
- seems to be the most common approach
- convenient access
- global singleton might lead to difficulty and inflexibility, e.g. 
capturing logging in tests, multiple configurations

Logger instances:
- more fields on every type and function that wants to log
- full control over logging in each individual type and function
- clearly stated dependencies for each type/function. I'd say Go idioms 
tend toward obvious, clear, and powerful over clean, concise, magic.

A third, interesting option might be to add all logging configuration to 
the context using context.Value, including output, formatting, etc. Global 
logging functions would pull all needed config from the context. I'm 
worried this gets into the hotly debated territory of abusing 
context.Value. On the other hand, we're already passing context everywhere, 
and this is useful context that crosses API boundaries.

Anywho, would love to get thoughts from the experts out there. Thanks for 
reading!

Alex


[1] https://github.com/ohsu-comp-bio/funnel
[2] https://github.com/sirupsen/logrus
[3] https://github.com/ohsu-comp-bio/funnel/blob/master/worker/runner.go#L25
[4] https://github.com/ohsu-comp-bio/funnel/pull/194

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Capture test output per-function

[buchanae . ohsu]

On Thursday, July 6, 2017 at 12:40:30 AM UTC-7, Jan Mercl wrote:
>
> On Thu, Jul 6, 2017 at 12:56 AM  wrote:
>
> > As far as I can tell, go test captures the output per-package, and when 
> one test fails it dumps all the captured logs.
>
> It's per test, not package.
>
>
I think you need print statements in your other tests?

---

RJHB552 capture-test-output
cat foo_test.go
package t

import "fmt"
import "testing"

func TestOne(t *testing.T) {
  fmt.Println("ONE")
}

func TestTwo(t *testing.T) {
  fmt.Println("TWO")
  t.Fatal("fatal")
}
RJHB552 capture-test-output
go test .
ONE
TWO
--- FAIL: TestTwo (0.00s)
foo_test.go:12: fatal
FAIL
FAIL scratch/capture-test-output 0.006s

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Capture test output per-function

[buchanae . ohsu]

In Funnel, we have a growing end-to-end test suite which has many test 
functions.
https://github.com/ohsu-comp-bio/funnel/tree/master/tests/e2e

When one test fails, Funnel's logs are dumped, and there are lots of them. 
Debugging tests has become difficult. As far as I can tell, go test 
captures the output per-package, and when one test fails it dumps all the 
captured logs.

Possibly I'm approaching things the wrong way, so here I am asking the 
gurus (or gorus?) :) What can I do better? These are some ideas:

1) Find a way to capture output per-test without modifying Funnel logging 
code. Maybe I can do something with TestMain, subtests, I don't know.
2) Add better tracing info to the logs, so that each log entry has some 
context that can be grep'ed for. This would make our logs more useful in 
general, but will take some work.
3) Reconfigure the logger per-test, at the beginning of each test. Maybe 
write the logs to a file. Our tests are not currently run in parallel, but 
I'd like to leave that door open, and this might make that more difficult 
because the logger is global.
4) Don't dump the logs during tests, just get the failed list, and then run 
those tests individually.

Thanks in advance!
Alex

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Why there is no container/set

[buchanae . ohsu]

Back to the original question, container/set seems like a great addition. 
It could have a nicer interface than map[T]U and a single best 
implementation. Can we talk about whether the owners of that package agree?

On Saturday, December 3, 2011 at 1:32:02 AM UTC-8, James Chow wrote:
>
> I used "set" in java and c++, why there is no such container in golang 
> pkg-tree?
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.