Exposing a way to consumers to choose where to save the logs instead of defaulting always to os.Stdout

[aguidirh]

Description

In v3.0.0-alpha.1 dcontext package was moved to the internal folder. Because of that it is not possible to choose what is the file to save the logs anymore.

It was possible before by using the following code:

dcontext.SetDefaultLogger(regLogEntry)
ctx = dcontext.WithLogger(ctx, regLogEntry)

I think exposing to consumers a way to choose where to save the logs is a valuable feature. In case there are other ways to do that using the current v3.0.0-alpha.1 please let me know.

[milosgajdos]

I doubt we'll do that. Streaming logs into files creates major headaches for the app developers because then they have another problem on their hands: log rotation and dealing with open FDs etc...if you want to capture the log into a file use redirect operator 🤷‍♂️

[aguidirh]

Hi @milosgajdos,

Thanks for your answer.

I am not sure if using a redirect operator suits some use cases. Let me give more context so you can tell me if redirect operator suits or not.

Use Case:

A command line tool which start registry.NewRegistry(context.Background(), cfg) as part of its code base (direct dependency in go.mod).

The command line has their own logs being printed in the os.Stdout, printing the command line logs + the registry logs together in the same os.Stdout makes the output really confusing, making the command line logs unusable.

How is it possible to identify which logs are from the registry (distribution/distribution) in a code level in order to redirect them using the operator to a file?

[milosgajdos]

I didn't say a redirect operator will solve whatever issues you might face -- I merely offered it as an option to save stdout into a file if you need to.

making the command line logs unusable

This is a very strong statement 😄

[aguidirh]

Hi @milosgajdos,

I only said making the command line logs unusable because our command line logs is a step by step about what it is happening in the workflow. If the registry logs get mixed with the command line logs, then the customer won't be able to follow the workflow steps.

Is there a way to identify which logs comes from the registry ? If yes then I can use the redirect operator to save the registry logs to a file.

Don't you think this is a use case for others distribution/distribution consumers? From my perspectives consumers who are importing distribution/distribution on their code will usually face the same.

[milosgajdos]

Is there a way to identify which logs comes from the registry ? If yes then I can use the redirect operator to save the registry logs to a file.

I'm not sure off the top of my head. I'd have to verify that.

Don't you think this is a use case for others distribution/distribution consumers?

I actually don't. You are the first one (probably ever) who's asked for this 🤷‍♂️