Extract github.com/go-kit/kit/log to github.com/go-kit/log

[peterbourgon]

I have several use cases, now, where it would be beneficial if projects could use Go kit's package log without pulling in anything else. I would like to extract it to it's own module and package, tentatively named kitlog to avoid the name collision. And then I would like to point the existing package at it, maybe with type aliases if they are up for the task.

@ChrisHines — Do you think this is a reasonable idea, and is feasible? Can you identify any blockers?

[ChrisHines]

I support the idea in principle and would be happy to help make it happen. I have not yet thought it through enough to identify any blockers, but I have a hard time imagining any from a code or Go module perspective.

If we move it to a separate repo what happens to the issue history? Clearly it can stay in the go-kit/kit repo in the short term. It would be nice to eventually have the new repo be self contained though. I have migrated git commit histories while splitting a repo in the past, but I haven't migrated issues, PRs, etc. I don't know what tooling might be available or how well it works. I have lots of questions about that.

[basvanbeek]

I really like this idea and it has been a blocker for one of my teams in the past to use Go kit's log.

This can also provide us some experience if we want to refactor certain pieces to also live in their own repo's. Observability and Tracing instrumentation bridges come to mind.

[peterbourgon]

I'm sure there are tools that would let us extract and transplant the commit history from the kit repo, I'll look into that.

On further thought, it might not be necessary to alias kit/log to kitlog, we could just freeze the kit/log package and point folks to the new one in the documentation. Thoughts?

@basvanbeek Yep, I think the ultimate goal would be to extract all of the major units of functionality into their own repos/modules, and I think go-kit/tracing would be a good candidate for the next one.

How do people feel about the name kitlog? How annoying is it to deal with the current name conflict?

[ChrisHines]

On further thought, it might not be necessary to alias kit/log to kitlog, we could just freeze the kit/log package and point folks to the new one in the documentation. Thoughts?

That is an option. It might be OK given the stability of the log/** packages, but it feels like a fall back position if other approaches become too cumbersome.

How do people feel about the name kitlog? How annoying is it to deal with the current name conflict?

My first reaction is negative to kitlog due to the increased length, but maybe it's OK. Existing code adopting the new package could use an import alias to minimize code churn during migration. I think I need to try some examples to get a feel for it.

The existing name conflict with the stdlib log package only seems to impact me when first adding logging to some code and goimports type tools tend add the stdlib package by default. Once the import statement is corrected I don't find it a problem since all the functions names are different. The number of files that import both packages tends to be very small in my experience, hopefully only one place in a project if it needs to set up a StdlibAdapter.

[peterbourgon]

After some thought I think I'm actually -1 on kitlog — I think the benefits of using log. namespace in code significantly outweigh the cost of conflicting with the stdlib package.

[ChrisHines]

We should also consider giving the log subtree into its own go.mod as an alternative to moving it into a separate repo.

Pros:

• No change of import paths, code, or issue tracking.
• We can tag it v1.0.0 separate from the rest of Go kit.
• Least work required.
• All the benefits of it being a separate module.

Cons:

• Requires discipline in git tag naming (e.g. log/v1.0.0).

Personally I think this maybe the best approach unless there is a downside I haven't thought of yet.

[peterbourgon]

There are enough caveats and complexities involved with multi-module repos that I would not willingly opt in to that unless I had no other choice.

[ChrisHines]

Thanks for the link. I hadn't read through that page in a while. I agree that in the current context there are some big downsides to making log a submodule. The most scary part is described in the section "Is it possible to add a module to a multi-module repository?". The money quote is:

The second class: the path at which the module is being added is in version control and contains one or more existing packages. This case requires a considerable amount of care.

IMO, the main show stopper is that we would have to create a fake dependency from log to the main go-kit/kit module to avoid triggering an “ambiguous import” error at compile time.

So yes, after further consideration I agree a submodule is not such a great idea given that the log package is already published as part of the main module.

[sagikazarmark]

I'm sure there are tools that would let us extract and transplant the commit history from the kit repo, I'll look into that.

That can easily be done with just git. I had a similar task once and I blogged about it here. If you need assistance with the split, I can help.

[andig]

That can easily be done with just git. I had a similar task once and I blogged about it here. If you need assistance with the split, I can help.

With what @sagikazarmark mentioned it should be possible to transfer github.com/go-kit/kit/log to github.com/go-kit/log given that

There are enough caveats and complexities involved with multi-module repos that I would not willingly opt in to that unless I had no other choice.

rules out the mono-repo solution. In addition, github.com/go-kit/kit/log should be deprecated and no longer referenced from go-kit.

What would it take to move this forward? Anything external contributors could do?

[peterbourgon]

go-kit/log#2

[sagikazarmark]

What's the next step? Do you plan to introduce larger changes to the extracted log library? What about backwards compatibility? Do you plan to keep the log library in the main module as well?