Masterminds / glide

Package Management for Golang
https://glide.sh
Other
8.15k stars 541 forks source link

Failed to generate lock file when same package exists in import and testImport #741

Open piotrkowalczuk opened 7 years ago

piotrkowalczuk commented 7 years ago

On glide install (glide version 0.13.0-dev) I'm getting such error:

Failed to generate lock file: Generating lock produced conflicting versions of github.com/stretchr/testify. import (~1.1.4), testImport (~1.1.0)

Tell me if I'm wrong, but expected behavior would be to choose ~1.1.4.

Cheers

sagikazarmark commented 7 years ago

I have a similar issue: Failed to generate lock file: Generating lock produced conflicting versions of google.golang.org/grpc. import (), testImport (^1.0.5) (Yes, it's ONLY a dev dep)

import:
- package: github.com/Sirupsen/logrus
  version: ^0.11.2
testImport:
- package: google.golang.org/grpc
  version: ^1.0.5
kisPocok commented 7 years ago

I have the same issue. Do you have any clue?

stevenroose commented 7 years ago

I think the best solution is to don't have a version constraint on your test dependencies.

stevenroose commented 7 years ago

It's weird, I now also get an error like that even when I don't have a version constraint on one of the dependencies.

jbirch commented 6 years ago

This one is somewhat a pain in the ass for us, as we have dependencies that Glide 0.12 and earlier fails to build against (the import . "github.com/project/repo" bug), but all the 0.13 Glides (and master) are running into this -- where some transitive dependency is pulling in github.com/stretchr/testify in import but the project itself is pulling it in testImport.

We can move our dependencies on stretchr/testify to import also as a quick workaround, at least.

Near as I can tell, the prevailing advice is "Hope all your dependencies don't use testImport, otherwise you might not be able to build your project". I'd be interested in hearing about other ways we can possibly mitigate this.

jbirch commented 6 years ago

Two corrections:

Firstly, it looks like having any of your dependencies use testImport for something that is elsewhere simply imported will not cause an issue -- at least if the dependency doesn't declare a version.

Secondly, as long as we don't declare a specific version in our own usage of testImport dependencies, then this usually doesn't seem to trigger the clash. Sometimes it does, and I haven't figured out why:

[ERROR] Failed to generate lock file: Generating lock produced conflicting versions of github.com/stretchr/testify. import (^1.1.3), testImport ()

This means our mitigation strategy is to testImport-depend on testify, but to set no versions anywhere in testImport for anything. This isn't ideal, but it's certainly workable for us in the short term.

jbirch commented 6 years ago

At the very least, this can probably combined with https://github.com/Masterminds/glide/issues/597 and https://github.com/Masterminds/glide/issues/564.