Closed sbowman closed 7 years ago
There is no glide specific functionality in the code. The dat API on branch v1 is fully compatible with dat.v1.
Glide is just a means to install the exact dependencies I'm using. Try installing the previous version of dat.v1 with go get
or gopkg.in
. It's impossible unless you manually clone the project, checkout a specific commit, then do that for each dependency. This is not a problem I created, it's a go problem.
My advice would is to install it manually and vendor it in your project. That should work with your CI.
I don't think this is correct. Your logxi package has a v1 directory, but imports in dat (including the one in gopkg.in) refer to github.com/mgutz/logxi, not github.com/mgutz/logxi/v1. Looks like the dat glide.yaml is pulling in a "subpackage" of v1 in your master branch, so it probably vendors to github.com/mgutz/logxi.
If you go back to branch v1.1.9 (pre-glide), building dat will work without glide.
dat/init.go (both v1 and master look similar):
import (
"fmt"
"strconv"
"github.com/mgutz/logxi"
)
glide.yaml (v1 branch, which I assume is gopkg.in/dat.v1):
...
- package: github.com/mgutz/logxi
glide.yaml (master):
...
- package: github.com/mgutz/logxi
subpackages:
- v1
...
I'm not familiar with Glide, so I'm just assuming "subpackages: - v1" pulls github.com/mgutz/logxi/v1 as dat/vendor/github.com/mgutz/logxi. Without Glide though, manually pulling causes the dat import statements to fail, since the Go code is actually in github.com/mgutz/logxi/v1. That's what I mean by "glide-dependent code".
Please install manually per the INSTALL.md doc to your $GOPATH. It will save us both time. dat.v1 is tracked on branch v1. All the commit hashes are in glide.lock if you want to attempt to tackle what glide does. The instructions literally take a few minutes to follow.
We're just going to pull it from our project and stick with sqlx.
This is more a feature request than an issue, but I wish you'd remove the requirement for Glide. You should leave the vendoring up to the application utilizing your package, since vendoring isn't "inherited".
You've utilized Glide-specific functionality in your code (subpackages), which means if our application doesn't use Glide (it doesn't), we have to take extra manual steps which aren't easily reproducible locally for development and updates or remotely during continuous integration, etc.