Gitea: Proposal: Move to golang/dep for vendor in place of govendor

Created on 27 Jul 2017  路  15Comments  路  Source: go-gitea/gitea

golang/dep is planned to be the official tool to manage vendor (even make disappear /vendor in the future).

There is not yet an init method to start from govendor but we can do govendor->glide->golang/dep.

I have allready tested a little and only blevesearch seems to block so before passing more time on it.
Are you ok to go that way ?

kinbuild kinproposal

Most helpful comment

I mean that the feature is that it will have less bug since it would be an offcial tool and have a wider base of user.
I think that if we migrate to it the most important part of PR is that I will need to document the process in contributing to add/update/delete vendor.

All 15 comments

I'm more than ok with that :)

Why should we move to golang/dep ?

@lunny in future it will come prebundled with golang compiler so we would have one dependency less

golang/dep is not yet ready to be scripted. Though it is "production ready" (can't find the youtube link 馃檮 ). But yes, we should move to that as soon as possible 馃檪

After testing, I have try to kept the same version as the one used rigth now in vendor.json but I maybe need to tweak somes.

I think govendor is enough currently. We don't need to change to another govendor - dep. What's the differences or advantages of dep ?

Mainly, It will be integrated in golang tooling and supported as the default. The goal for the golang dev is to not break olders solutions so we could also stay under govendor.

But, for example as it would be supported by golang tooling, I expect that we won't have any bug like hash that differ depending of platform. :smile:

@sapk Only different hash is a better thing, but it seems it's a bug of govendor not a feature of dep. I don't against to change to dep if it can fix the bug. I'm confusing by it many times.

I mean that the feature is that it will have less bug since it would be an offcial tool and have a wider base of user.
I think that if we migrate to it the most important part of PR is that I will need to document the process in contributing to add/update/delete vendor.

@sapk could you send a PR since you have some work on this issue?

it's still not clear what will happen with dep/vgo, but vgo at least plans to support migrations from dep, IIRC

@lunny this was done a long time ago but I will update it ;-)
@ptman From the go wiki, vgo is still early at this stage :

Current state
Currently vgo is in active development / prototype phase. It has some rough edges, changes will happen at a rapid pace. You are encouraged to try vgo and give your feedback, share your experience with it, and contribute to it.
For any production workloads, use dep, or migrate to it if you have not done so already.

@sapk yes, but some of the earlier comments about dep going to be integrated are no longer looking so certain

@sapk Guess we can close this, right?

Implemented by #3972

Was this page helpful?
0 / 5 - 0 ratings