log15.Record compatibility across third-party packages about log15 HOT 6 CLOSED

I don't think there's a change here that will make it better, to be honest. It's not ideal that you need to import the package just to implement the Handler interface, but I think any of the other options are just more complicated and burdensome.

from log15.

@inconshreveable Agreed.

I have been thinking about this issue, and I'm not convinced there is a good solution either. One approach is to define the Handler interface solely with built in types or types from the standard library. But that may be painful to use.

This issue can serve to document one of the hidden costs of API changes.

from log15.

I have had issues with using the versioned form of the URL repo as well. As a solution I have been using a manifest file to pull in the labeled version of the repo directly from github onto my gopath. that works consistent enough for me.

from log15.

@notzippy You are talking about gopkg.in/inconshreveable/log15.v2, right? What problems have you had?

from log15.

@ChrisHines The code completor for intellij insisted that log15 needed to be on the end of the import statement (like import "gopkg.in/inconshreveable/log15.v2/log15"), this is an issue with the tool more then anything else, but I understand why, it is because the package name in the file is not matching log15.v2 which in theory it should.

from log15.

@notzippy I think about 30-40% of all non-std packages use a package name that doesn't match the directory they're in.. Lots of packages are prefixed with go. or go-, and then there's also all the gopkg.in versioned packages with the version suffix. The go tool doesn't expect the directory name to be equal to the package name, not does the spec state that this is expected. So I don't think in theory it should and this is definitely a intellij problem.

from log15.