Skip to content
This repository has been archived by the owner on Jun 27, 2023. It is now read-only.

Build Failing - Missing "context" package #116

Closed
aludvik opened this issue Oct 11, 2017 · 6 comments
Closed

Build Failing - Missing "context" package #116

aludvik opened this issue Oct 11, 2017 · 6 comments

Comments

@aludvik
Copy link

aludvik commented Oct 11, 2017

After #111 was merged, I am now getting build failures in our CI process with the error:

cannot find package "context" in any of:

and then a list of directories in GOPATH.

@aludvik
Copy link
Author

aludvik commented Oct 11, 2017

Running go get -u github.com/golang/mock/gomock also fails with package context: unrecognized import path "context" (import path does not begin with hostname)

@balshetzer
Copy link
Collaborator

Which version of Go are you using?

@aludvik
Copy link
Author

aludvik commented Oct 11, 2017

We are using the golang-1.6 package in the Ubuntu 16.04 release:

root@be91d814ef5c:/# apt-cache show golang-1.6
Package: golang-1.6
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 78
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: all
Version: 1.6.2-0ubuntu5~16.04.3
Depends: golang-1.6-doc (>= 1.6.2-0ubuntu5~16.04.3), golang-1.6-go (>= 1.6.2-0ubuntu5~16.04.3), golang-1.6-src (>= 1.6.2-0ubuntu5~16.04.3)
Description: Go programming language compiler - metapackage
 The Go programming language is an open source project to make
 programmers more productive. Go is expressive, concise, clean, and
 efficient. Its concurrency mechanisms make it easy to write programs
 that get the most out of multicore and networked machines, while its
 novel type system enables flexible and modular program construction.
 Go compiles quickly to machine code yet has the convenience of
 garbage collection and the power of run-time reflection. It's a
 fast, statically typed, compiled language that feels like a
 dynamically typed, interpreted language.
 .
 This package is a metapackage that, when installed, guarantees
 that (most of) a full Go development environment is installed.
Description-md5: 8650a23f44e2d60a785ad3123733d6d8
Homepage: https://golang.org
Original-Maintainer: Go Compiler Team <pkg-golang-devel@lists.alioth.debian.org>

@aludvik
Copy link
Author

aludvik commented Oct 11, 2017

We use a docker image built from this Dockerfile for Go development: https://github.com/hyperledger/sawtooth-core/blob/master/docker/sawtooth-dev-go

@balshetzer
Copy link
Collaborator

That explains why this is happening. The context package was only added in Go 1.7.

If at all possible, I think you should upgrade your image to use Go 1.9.1 (that's the latest release). This should be simple since the Go releases are backwards compatible since 1.0.

If that's not possible then you can pin gomock to the latest version that worked for you. That would be 4887ba1.

I don't think we should try to fix this in the gomock package.

@balshetzer
Copy link
Collaborator

Despite what I said before, backwards compatibility was restored in #118

nick-drozd added a commit to nick-drozd/sawtooth-core that referenced this issue Nov 22, 2017
The compatibility issue was solved: golang/mock#116 (comment)

Signed-off-by: Nick Drozd <drozd@bitwise.io>
nick-drozd added a commit to hyperledger-archives/sawtooth-core that referenced this issue Nov 22, 2017
The compatibility issue was solved: golang/mock#116 (comment)

Signed-off-by: Nick Drozd <drozd@bitwise.io>
SpencerC pushed a commit to ggx-trade/gomock that referenced this issue Feb 19, 2024
Fixes golang#116 

# Problem

If your mock an interface that matches the fmt.Stringer interface:

```go
type Stringer interface {
  String() string
}
```

Then your unit tests can deadlock if you provide that mock as an
expected argument to a call that is not matched (i.e. fails the test).

Because, when printing the error message for the call that was not
matched, it calls `String()` on all arguments that support it, including
the mock.

But each call to a mock is protected with a mutex, and the previous call
(that was not matched) has not yet exited.

# Solution
The solution has two parts

1. During mock code generation (an existing part of this library) add a
unique method on mocks (ISGOMOCK)
1. During test execution, whenever we are stringifying something that
might be a mock, check if it is a mock (ISGOMOCK) that implements the
String() method. If it is, just use the type name as the string value,
instead of calling String() (which would cause the deadlock).
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants