Inconsistent dependencies when using `go-ethereum` with go modules

[Pet3ris]

Hi there,

I'm using go modules in a project that uses go-ethereum and it seems like it may be impossible to use it as a library.

System information

Geth version: 1.9.6
OS & Version: OS X
Commit hash : n/a

Expected behaviour

go build should compile when building on go-ethereum

Actual behaviour

Returns the following error:

$ go build
# github.com/ethereum/go-ethereum/ethdb/leveldb
~/go/pkg/mod/github.com/ethereum/go-ethereum@v1.9.6/ethdb/leveldb/leveldb.go:103:3: unknown field 'DisableSeeksCompaction' in struct literal of type opt.Options

This happens because the field DisableSeeksCompaction is available in github.com/syndtr/goleveldb on the master branch but not in the published 1.0.0. it seems like go-ethereum depends on the master branch, but go modules is pulling in 1.0.0 by default. Here is an excerpt from my go.mod file for context:

..
	github.com/ethereum/go-ethereum v1.9.6
	github.com/syndtr/goleveldb v1.0.0 // indirect
..

Steps to reproduce the behaviour

Import one of go-ethereum subpackages that has an indirect dependency to leveldb.

For example this file:

// Copyright 2017 The go-ethereum Authors
// This file is part of the go-ethereum library.
//
// The go-ethereum library is free software: you can redistribute it and/or modify
// it under the terms of the GNU Lesser General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// The go-ethereum library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU Lesser General Public License for more details.
//
// You should have received a copy of the GNU Lesser General Public License
// along with the go-ethereum library. If not, see <http://www.gnu.org/licenses/>.

package main

import (
	"sync"

	"github.com/ethereum/go-ethereum/common"
)

type AddrLocker struct {
	mu    sync.Mutex
	locks map[common.Address]*sync.Mutex
}

// lock returns the lock of the given address.
func (l *AddrLocker) lock(address common.Address) *sync.Mutex {
	l.mu.Lock()
	defer l.mu.Unlock()
	if l.locks == nil {
		l.locks = make(map[common.Address]*sync.Mutex)
	}
	if _, ok := l.locks[address]; !ok {
		l.locks[address] = new(sync.Mutex)
	}
	return l.locks[address]
}

// LockAddr locks an account's mutex. This is used to prevent another tx getting the
// same nonce until the lock is released. The mutex prevents the (an identical nonce) from
// being read again during the time that the first transaction is being signed.
func (l *AddrLocker) LockAddr(address common.Address) {
	l.lock(address).Lock()
}

// UnlockAddr unlocks the mutex of the given account.
func (l *AddrLocker) UnlockAddr(address common.Address) {
	l.lock(address).Unlock()
}

func main() {}

^ (Yes this is go-ethereum internal code that I need to refer to).

In an empty go module folder does not build.

Backtrace

n/a

[Pet3ris]

There is a work-around to force installation from leveldb repo using the latest commit:

go get github.com/syndtr/goleveldb/leveldb@758128399b1df3a87e92df6c26c1d2063da8fabe

or

go get github.com/syndtr/goleveldb/leveldb@master

which will always pull the latest.

[eccles]

For a permanent change try adding a replace directive in your go.mod file.

[karalabe]

Myeah, go modules picks the latest stable release of go-leveldb by default, which does not contain all the fixes we've upstreamed. The solutions are: a) manually swap your dependency as suggested above; b) get go-leveldb to merge the master changes into v1; c) update go-ethereum to use modules (blocked by #20228)