1

I have a Go main-application that uses a custom log package and a custom config package.

This application "consumes" other packages that they need more logging or config parameters. Perhaps, a useful example is a custom api-package:

  • It should print some debug|info|warning logs (the errors are managed as usual by the caller, in this case, the main-application).
  • It should have access to values stored in the config (e.g. a server url/port, the environment of the main-application (development, test or production),... ).

I see three solutions to solve this problem:

  1. Passing a pointer (of log and config) from the main object to the sub-package when the package is "initialised", then it will use this pointer like the main-application.
  2. Initialise these dependencies (log or config) directly into the sub-package too, but this could raise concurrency issues between the main-application's instance vs. the package's instance.
  3. Pass to each method the required arguments (but I would like to avoid build methods with huge args list).

At the moment I use method 1, am I doing it right? What is the Go conventions about this? Are there other ways to solve this?

EDIT

Just to explain, why it is not a duplicate of the proposed "duplicated" questions:

  • The answer proposed by icza: it takes care only for logging (writing "somewhere") and not for config (reading and writing). No other options are taken in consideration, for example which one follow at best the standards, which one is more performant,...
  • The other answer proposed by icza: it takes only care about a single application, this is not the case at all, because I already know how use the logging and the config in one "application" (or in goroutines).

If you mark as duplicate, please just explain why. So I can see if this is a really duplicate or if my question was misunderstand.

Community
  • 1
  • 1
damoiser
  • 6,058
  • 3
  • 40
  • 66
  • are you changing the config at runtime? i like solution 2 if it not change. – Jiang YD Jul 28 '15 at 08:02
  • 1
    Also related: [Logging globally (across packages)](http://stackoverflow.com/questions/29538668/logging-globally-across-packages) – icza Jul 28 '15 at 08:39
  • @JiangYD yep, it can (rarely) change – damoiser Jul 28 '15 at 09:47
  • @icza I don't think is really a duplicate of that answer. It is discussed only one way there (similar to my solution-proposal ```1.```), but it is not take in consideration any other option. Furthermore, the ```config``` topic is not discussed at all. – damoiser Jul 28 '15 at 09:51
  • Do the custom `log` and `config` packages require parameters produced by the main app? Can't they just initialize themselves? – icza Jul 28 '15 at 12:55
  • yep @icza it can be "custom" flags provided (for example) from the cli while starting-up (e.g.: the log could have the ```-debug=true|false```, the config could have ```-config_location=somewhere```). Then I think that they can't initialize themselves (because they could miss the main-app flags). – damoiser Jul 28 '15 at 14:26
  • A further issue, could be that the config can be updated - then in this case a package or the main-app could be not anymore in sync (have the same configs values) - ever in the case they initialise themselves. Using a reference solves this, but is the right way? – damoiser Jul 28 '15 at 14:31

0 Answers0