Conversation
|
Thank you for submitting this PR!
Getting other community members to do a review would be great help too on complex PRs (you can ask in the chats/forums). If you are unsure about something, just leave us a comment.
We currently aim to provide initial feedback/triaging within two business days. Please keep an eye on any labelling actions, as these will indicate priorities and status of your contribution. |
70a5a10 to
8875c82
Compare
Codecov ReportAttention: Patch coverage is
@@ Coverage Diff @@
## main #794 +/- ##
=======================================
Coverage 60.52% 60.52%
=======================================
Files 245 245
Lines 31130 31130
=======================================
+ Hits 18841 18842 +1
+ Misses 10613 10611 -2
- Partials 1676 1677 +1
|
dereknola
left a comment
There was a problem hiding this comment.
That works for K3s, I'm not seeing any conflicts when I inject your PR commit.
gammazero
left a comment
There was a problem hiding this comment.
Might be better to avoid makefile. See comments.
gammazero
left a comment
There was a problem hiding this comment.
Lets merge this before the next boxo version and kubo RC2. We can decide between Makefile and go:generate in a later PR.
d443b97 to
b91a277
Compare
b91a277 to
fbe6ba1
Compare
|
Using go:generate also means it can be run from a top-level directory, |
Context
To solve protobuf namespace conflicts, #789 renamed
record.prototoipns-record.protobreaking protobuf dependency import since the filename has now changed. I think there is a better way to solve #788.Proposed solution
While the
go_packageoption set in the.protofile isn't included in the registered protobuf name, we can use a customMakefileto register the full package name. This seems like a cleaner approach, since it registers the protobuf with the full package path, instead of justipns-record.proto, and it doesn't break existingrecord.protoimports.Protobuf package source before and after.
Also see libp2p/go-libp2p-record#62
Would that work for you @dereknola?