Issue Importing from Projects Using Go 1.13

[tri-adam]

Version of Singularity:

3.4.0-131-gade1f06c3

Expected behavior

Importing github.com/sylabs/singularity in a project using Go v1.13 should work.

Actual behavior

Importing github.com/sylabs/singularity in a project using Go v1.13 fails. For example:

$ go mod download
go: finding gotest.tools v2.3.0+incompatible
go: finding gotest.tools v2.3.0+incompatible
gotest.tools@v2.3.0+incompatible: invalid version: +incompatible suffix not allowed: module contains a go.mod file, so semantic import versioning is required

The issue is two layers deep:

1. gotest.tools@v2.3.0+incompatible isn't a valid version when building with Go v1.13 due to version validation (ref).
2. The Singularity source code that references gotest.tools does not use semantic import versioning. This worked with Go < 1.13 since the +incompatible disabled that requirement, but now that version validation forces us to remove +incompatible, we need to use semantic import versioning in the source.

The most straight forward solution seems to be to bump to v3, as suggested by the package maintainers in gotestyourself/gotest.tools#140.

Steps to reproduce behavior

Import github.com/sylabs/singularity in project. Run go mod download with Go v1.13 installed.

[mem]

I have to say that I have my qualms about anything importing github.com/sylabs/singularity given that the development process does not take into account this sort of stuff. The pkg directory is quite messy (starting with the fact that it's called pkg). There's a bunch of stuff in e2e that could be imported if somebody tried, too.

(and yes, I'm aware that plugins need to import from singularity)

That aside, I updated gotest.tools to v3 as suggested.

[tri-adam]

Indeed, this has been an ongoing challenge. That was part of the motivation for splitting the Builder/Library/Key client libraries into their own modules.