stretchr/testify uses wrong tag format and should be relegated to testImports

[jbirch]

This project currently defines its dependency on stretchr/testify as ^1.1.3 via Glide, in the import section.

Firstly, all tags of stretchr/testify are prefixed with v. Secondly, as stretchr/testify is only used for testing, it can be relegated to the testImport section of glide.yaml.

Either of these two issues don't cause problems by themselves -- depending on this project will cause Glide to detect semantic versioning and, at the time of writing, pull in stretchr/testify v1.2.0. However, if a project uses Glide and:

1. imports xeipuuv/gojsonschema, and
2. testImports stretchr/testify themselves, then

Glide will begin to normalise the versions it detects, but ultimately fail:

[INFO]	--> Fetching github.com/xeipuuv/gojsonschema
...
[INFO]	--> Detected semantic version. Setting version for github.com/stretchr/testify to v1.2.0
...
[WARN]	Using import github.com/stretchr/testify (version ^1.1.3) for test instead of testImport (version ^v1.1.4).
...
[ERROR]	Failed to generate lock file: Generating lock produced conflicting versions of github.com/stretchr/testify. import (^1.1.3), testImport (^v1.1.4)

This is somewhat a Glide problem, in it's rules of negotiating import vs testImport conflicts, even if they resolve to the same commit. However, we can work around the issue for consumers here by correcting the versioning format and moving it to testImport. For other projects that declare a direct dependency on this project in their import section, Glide will continue to use their specified version.

I've got a PR I'll submit shortly for this issue.

[jbirch]

This is root-caused by Masterminds/glide#741 -- which makes me think that perhaps the issue might still remain. Perhaps the answer is to either:

1. remove the version declaration for stretchr/testify, or
2. entirely remove the dependency on stretchr/testify and allow glide to detect it with magic.

What are your thoughts?

[jbirch]

At this point I reckon it's probably worth not merging this; I'll come up with a minimised test case to see if it'll be safe to be merged.

[jbirch]

Okay, it looks like the issue is mitigated by not depending on a specific version in testImport, and as far as I can see is safe. I'll update the PR.