gopkg.in -> go/dep, however vendor dir hasn't been checked in about bfchroma HOT 7 CLOSED

Hmm... I see. What may be the alternative solution here ? Commit the vendor directory ?

from bfchroma.

I believe so. Most of the libraries (non-main Go packages) I've written, I've personally tried to stay away from committing the vendor directory (or using vendor tools in general), because having the changes in Git history is a pain to keep clean. I have travisci set up on a cron running tests to make sure things stay in check as well as I try and limit the packages I'm using as much as possible, thus partially mitigating dependencies from causing issues. As for packages which are main based, I do as you have done (commit the manifest files, and .gitignore the vendor/ folder).

from bfchroma.

Hm... Damn. Alright I'll do that 👍 Thanks for the report

from bfchroma.

So after investigation, I realized that there was an error in the Gopkg.toml file.
I added a warning in the README.md file that dep ensure needs to be executed after the go get if Blackfriday v1 is in the system. I'm really not a huge fan of committing the vendor directory

from bfchroma.

I feel there are many issues with that approach. To name a few:

1. For libraries, it seems like bad taste to require users to install the vendoring tool that you are using for a library. If someone is writing a utility or service which they don't want vendoring in (they don't use their own vendor tool, and let go get do everything for them) and they use this library, this means they now have to build into their compilation pipeline to:
   1. Install the vendor tool you use, go to your package dir.
   2. Figure out how to use the vendor tool. Or...
   3. They have to manually figure out which library you are using which is the problem, pin that specific version in whatever vendor tool they are using, then add bfchroma using the vendor tool (and completely forget about go get being useful at all). This is what I had to do.
2. Even if using go/dep ensure after go get, users will still receive the huge stack of errors returned by go get, and is extremely offputting, esp. to new users.
3. gopkg.in, although considered a "hack" (if you will) by some, is still widely used and recommended, as it still tries to enforce users to not implement breaking changes into their code

In short, I think that requiring users to use your vendor tool for a main-based package is OK, because you can easily handle all of that for the user in a Makefile for example (e.g. make install could make sure the vendor tool is installed, and fetches all of the necessary dependencies). However, requiring users to do it in a library, creates a lot of unwanted hassle. What if all of the other 20 packages that a large app imports also want to do the same? What if they don't use the same vendor tool?

I think the other issue is on blackfriday. They choose to start developing v2 in a sub-package, and not in their master branch (some other projects are doing this too). I've never been a huge fan of this because now when someone looks at my code, they will see github.com/russross/blackfriday, go to the repo, and none of the functions/methods I'm using are going to be at all similar, because it doesn't tell them anything about the branch that should be used. If other code also imports what blackfriday recommends, gopkg.in/russross/blackfriday.v2, this will also not match up in vendoring, and has the potential of causing uncorrectable dependency version issues. It would have been nicer for them to copy master to a v1 branch, and have recommended that to users from the start, but alas..This can be resolved by just using gopkg.in/russross/blackfriday.v2 when vendoring, so it matches up with what other users have been recommended to import/use, and there should be less conflicting issues in the vendor dir.

I think the only viable options without requiring users to jump through hoops, is:

1. Check in the vendor dir.
2. Don't check the vendor dir in, and don't check in go/dep files. Use gopkg.in, and let the user vendor where necessary. If they don't vendor things and this library breaks due to one of it's dependencies, causing a headache for them, I think it's on them for not vendoring things. This can still be minimized by limiting the dependencies of this library, however.

Lastly (and only personally), I'm really not a huge fan of how the structuring of go/dep is being handled (when it comes to commands, pinning, the file naming scheme, etc), so I haven't even downloaded it on my system yet. Plsplspls don't make me! 😃

tl;dr sorry for the rant. I'm using vendoring, so I was able to get around this issue, but I suspect it's not going to be easy for others. ¯_(ツ)_/¯

from bfchroma.

The first example in README.md also still uses gopkg.in.

from bfchroma.

Wow. Thanks for the explanation !
I prefer the approach where I rollback to gpkg.in. I really don't feel like handling the whole vendor directory in my repository.

And no problem you gave me a solution to the problem you reported so I'm glad you did that, I was quite confused how I could deal with that. Thanks ! 👍

from bfchroma.