Any plan for using godep or glide to manage dependencies ?

[yanyiwu]

I think godep is a good tool to mange dependencies better for this project.
So I wonder whether this project will use it .

For example, TiDB use godep as well.

[yanyiwu]

And golang is very very popular in China, But China can not visit golang.org very well because of the GFW .
So if bleve can manage all denpendencies with godep, it will reduce much pain for the developer in China. Because it can break away from golang.org when go get .

And I have planed to add Chinese Word Segmentation into bleve, make it more useful and in China.
Bleve is a great project, I hope it will become more popular in China.

[mschoch]

Thanks for your interest in Bleve. We would certainly like to do whatever we can to help make the project more accessible and useful for people in China. If you have other ideas for this please let me know.

We have been considering how to properly version the project for some time, and the handling of dependencies is a related concern. One challenge with versioning is that most of the Go tooling around versions expects that applications declare their versions, not libraries. In addition to godep, we want to consider gb and gopkg.in as well.

My first thought is that we need to start introducing our own versioning, most likely using something like gopkg.in. And then we should review our external dependencies, and decide whether or not there is value or harm in us bringing them into the project or not.

Thanks for raising this issue in the context of the GFW, I had not considered that. I'll leave this issue open as we try to figure out what we're going to do.

[yanyiwu]

@mschoch
Thanks for your response here, you are so nice!
This project will become better and better definitely.
But it is sad the developers in China can not visit gopkg.in , it is blocked by GWF too.
It is so sad.

[mschoch]

OK, thats also good to know. I'm trying to understand what about the godep solution in particular will make it work well. Is it that you would have bleve and all of its dependencies in a single github repository? That way the go get command only has to talk to github?

[yanyiwu]

@mschoch Yes. That is totally right.
godep save -r ./... will pack all your dependencies in one directory named Godeps, and rewrite all the statement like import "github.com/x" to import "github.com/blevesearch/bleve/Godeps/_workspace/src/github.com/x"

And after that a new directory Godeps will be generated, so the last thing you need to do is git add Godeps and commit it.

[donhcd]

+1 for having versioned dependencies. For my projects, I've been using the go1.5 vendor experiment which works alright, though saving dependencies with godeps can be messy... instead of godep save ./... you typically do GO15VENDOREXPERIMENT=1 godep save $(go list ./... | grep -v /vendor/) (you can omit the GO15VENDOREXPERIMENT=1 if you keep that set in your environment, of course)

[mschoch]

Thanks, we are working towards introducing versioning. Are any of the projects you maintain a library? If so that would be useful for us to examine closer as an example to follow. Thanks.

[donhcd]

Unfortunately, my main projects are closed source so I can't really share :/ I'll update this thread if I find any good open source examples... I haven't found any yet

[yanyiwu]

Now I think maybe glide is a better solution .

[noypi]

workaround for our chinese friends.
gohugoio/hugo#1558

[mschoch]

Here is some further discussion around the problems with vendoring dependencies in libraries:

https://peter.bourgon.org/go-best-practices-2016/#dependency-management

With the conclusion (for now) being "Libraries should never vendor their dependencies."

There are links to golang issues and golang-dev discussions, I encourage everyone to read through them if you are concerned with this issue.

On a more positive note, I think we can actually work to eliminate many of the external dependencies we have. Things like the context package which are necessarily part of the public API simply cannot be vendored at the moment.

[mschoch]

In order to keep moving towards 1.0, I'm leaving this open and moving it to 2.0.

For now, we are doing the following:

1. Releases are tagged, and we are trying to follow semver.
2. Applications using bleve are encouraged to use a vendoring tool to vendor bleve and it's dependencies. We ship a manifest with the versions we've tested to aid in this process.
3. Once at 1.0, users could use gopkg.in to get the latest stable 1.x (we understand this won't work for everyone, but it is an option for some)

Going forward, I expect bleve to:

1. Take a very hard look at all external dependencies, consider vendoring (with source) libraries that are just an implementation detail and not part of the exposed API.
2. Continue to monitor progress of the official package manager 'dep' and ensure we work well with it.