Removing log4net dependency of chocolatey.lib

[zbalkan]

Hi,

In the last discussion, I was trying to use chocolatey.lib in another project but it turns out that the target frameworks will remain an issue for a while. But there was another issue with the library for the third party users of the library: log4net

I plan to work on it but this time, I want to ask first so that I don't waste days for nothing. Since this is an architectural decision, it will change chocolatey console and GUI.

I intend to use the dotnet core way and go with DI. This way it's going to move the dependency out of library to the client applications. It does not add more value to the chocolatey project but helps with the users of chocolatey.lib, which are not that many.

So, if I can get a green light, I'll give it a try. In that case, if you have any pain points I might consider during this effort, I would be glad to have suggestions, warnings beforehand.

Thank you for the chocolatey, by the way, for being such a great helper.

[gep13]

@zbalkan apologies for not replying sooner about this. I saw this discussion, and then I promptly forgot about it.

Can you help me understand exactly what changes you are suggesting be made here?

log4net is engrained in pretty much every Chocolatey component/product, so removing it from chocolatey/choco would have a huge knock on effect that will ripple through all projects. I would be hesitant to make that type of change without a clear benefit in place.

[zbalkan]

Hi,

The questioned log4net dependency arose from using chocolatey.lib in another project, as I've mentioned above. Using just chocolatey.lib to gather information about installed packages requires a logging library. The consumer of the library, ideally, by default should be the decision-maker on the cross-cutting concerns like logging, authentication, security, etc. Therefore, my suggestion is to get the dependency out of the library on the consumers.

So, log4net dependency will be included in the console and GUI. By doing so, 3rd parties can utilize their own logging choices.

However, this brings another decision point with two options:

1. Transfer the responsibility of logging to the consumer: Remove logging totally out of chocolatey.lib, and make the consumer applications do the logging when a method is called from the library. The consumer may never need logging about the internals of the library.
2. Dependency Injection: Just like many dotnet core libraries, it's possible to utilize the abstraction that the framework provided. Using an abstract logger in the library and require the consumer to inject the used Logger into the library during initialization.

Proposed API

//  Current situation. 

Lets.GetChocolatey(bool initializeLogging);
Lets.GetChocolatey(); // initializeLogging is true by default

Instead,

// First option. No logging is mentioned anywhere.

Lets.GetChocolatey(); // Logging will be the responsibility of the consumer

// Second option, first alternative
Lets.GetChocolatey(ILogger logger); // This would always require a logger to be injected at runtime` 

or

// Second option second alternative, to me the sane way of handling the issue.
Lets.GetChocolatey().WithLogger(ILogger logger); // This would allow using or not using a logger

[zbalkan]

I was on mobile, so I sent the reply on halfway. Sorry for that. I also edited for a better reading experience afterwards.

[zbalkan]

Do you know any other consumers of chocolatey.lib except for chocolatey console and chocolatey GUI?

[gep13]

@zbalkan The main consumer that I am aware of Chocolatey GUI, but there are a couple of Chocolatey GUI clones that likely use the same approach as Chocolatey GUI. There is also Boxstarter, which currently makes use of the Chocolatey.Lib file, however, it is currently in the process of switching to using choco.exe instead.

The main concern that I have regarding this approach is that currently, the API within Chocolatey.Lib doesn't actually return useable information about "what" happened during an execution. Instead, a logger needs to be passed, and the log entries inspected to identify when an error has occurred (as an example). This is a failing of the current API, and something which does need to be addressed, but I wanted to raise this as simply not having a logger, or rather not worrying about logging, isn't going to work as it currently stands.

[zbalkan]

@gep13 My suggestion is based on allowing the usage of a logger if the consumer applications do not need to, and allowing them to pick their own logging library if they want to. The consumer applications may inject their own library, elmah, log4net, syslog, etc.

P. S: Excuse me if my wording is not clear enough, since I am not a native speaker.