Open nasdf opened 12 months ago
This means that we should import the forks instead of the original.
This means that we should import the forks instead of the original.
How does that work with different module paths?
How does that work with different module paths?
For example, we replace all instances of github.com/dgraph-io/badger/v4
in the import statements to github.com/sourcenetwork/badger/v4
How does that work with different module paths?
For example, we replace all instances of
github.com/dgraph-io/badger/v4
in the import statements togithub.com/sourcenetwork/badger/v4
I thought the import paths and module names had to match.
I thought the import paths and module names had to match.
I'm not sure how they would be different even with the change?
github.com/sourcenetwork/badger/v4
still has badger
as it's module name.
I thought the import paths and module names had to match.
I'm not sure how they would be different even with the change?
github.com/sourcenetwork/badger/v4
still hasbadger
as it's module name.
Getting this error if I try to change the imports.
go: github.com/sourcenetwork/badger/v4@v4.0.0-20230801145501-d3a57bd4c2ec: parsing go.mod:
module declares its path as: github.com/dgraph-io/badger/v4
but was required as: github.com/sourcenetwork/badger/v4
Ah yes I see. We need to update our forks module names to match the path of the fork's repos
go: github.com/sourcenetwork/badger/v4@v4.0.0-20230801145501-d3a57bd4c2ec: parsing go.mod: module declares its path as: github.com/dgraph-io/badger/v4 but was required as: github.com/sourcenetwork/badger/v4
same to me , as well
same to me , as well
@alipostaci2001, if you update to v0.8 this should be fixed. Let me know if you still get the problem with that version.
When using DefraDB as a library the following module replacements must be copied to the project's
go.mod
in order for it to compile.