Do you check in vendor packages?

[Will Faught]

According to https://github.com/golang/dep/blob/master/docs/FAQ.md#should-i-commit-my-vendor-directory, the pros and cons are:

Pros:

- Only way to get truly reproducible builds

- Don't need to `dep ensure` (or whatever your tool is) every time you check out or merge/pull

Cons:

- PR vendor diffs (although apparently "suppressed" by GitHub, according to the dep FAQ)

- Bigger repository size

I've argued successfully in the past for projects to check in their dependencies. For a current project, though, someone has counter-argued that some of the dependencies are just too large (like k8s.io/* packages), with too much churn, to check in, and I can see their point. When a dependency update can add 5+ MB, that's a pretty steep price.

Is there consensus yet on whether or when to check in dependencies?

[Kevin Malachowski]

I generally vote for checking in, or at least ensuring that /something/ has an in-house copy of all dependencies. The worst thing that can happen is someone deleting their repository and having your project being super broken.

(See also https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)

[Henrik Johansson]

I always check in. It is super nice to not have to download separately and have one transitive dep destroy everything when you need it the least.

On Fri, 15 Sep 2017, 02:37 Kevin Malachowski <nifta...@gmail.com> wrote:

I generally vote for checking in, or at least ensuring that /something/ has an in-house copy of all dependencies. The worst thing that can happen is someone deleting their repository and having your project being super broken.

(See also https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Will Faught]

Kevin, Henrik:

Thanks for replying!

Have you ever had to check in very large dependencies? Would you still do it if just one dep added 30 MB to your 10 MB repo? What if the size of your code is dwarfed by the size of your deps 10:1? I'm curious how far people are willing to go to check in their deps—do they check in regardless of size? Or is a hybrid approach the best, where you check in all but the very large deps?

I've been wondering whether the dep size cost is mostly a one-time, up-front cost when you first check it in, and updates thereafter are relatively very small, such that in the long run the size cost is maybe at most 2x the initial size, which is basically a fixed, constant cost compared to the ongoing size growth of your overall repo in the long run.

On Thu, Sep 14, 2017 at 11:54 PM, Henrik Johansson <dahan...@gmail.com> wrote:

I always check in. It is super nice to not have to download separately and have one transitive dep destroy everything when you need it the least.

On Fri, 15 Sep 2017, 02:37 Kevin Malachowski <nifta...@gmail.com> wrote:

I generally vote for checking in, or at least ensuring that /something/ has an in-house copy of all dependencies. The worst thing that can happen is someone deleting their repository and having your project being super broken.

(See also https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/EapE_L8TCdA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@googlegroups.com.

[gurp...@gmail.com]

Create a separate repo for vendor directory. Set it to "auto check-in" in main repo's git push hook. Done.

Moreover, with submodule hash info included in main repo commits, the vendor repo can map better on checkouts. You could this skip submodules mapping if you don't mind rewinding manually when needed (which isn't often, is it?).

Regards,

Gurpartap Singh

On Saturday, September 16, 2017 at 12:21:38 AM UTC+5:30, Will Faught wrote:

Kevin, Henrik:

Thanks for replying!

Have you ever had to check in very large dependencies? Would you still do it if just one dep added 30 MB to your 10 MB repo? What if the size of your code is dwarfed by the size of your deps 10:1? I'm curious how far people are willing to go to check in their deps—do they check in regardless of size? Or is a hybrid approach the best, where you check in all but the very large deps?

I've been wondering whether the dep size cost is mostly a one-time, up-front cost when you first check it in, and updates thereafter are relatively very small, such that in the long run the size cost is maybe at most 2x the initial size, which is basically a fixed, constant cost compared to the ongoing size growth of your overall repo in the long run.

On Thu, Sep 14, 2017 at 11:54 PM, Henrik Johansson <dahan...@gmail.com> wrote:

I always check in. It is super nice to not have to download separately and have one transitive dep destroy everything when you need it the least.

On Fri, 15 Sep 2017, 02:37 Kevin Malachowski <nifta...@gmail.com> wrote:

I generally vote for checking in, or at least ensuring that /something/ has an in-house copy of all dependencies. The worst thing that can happen is someone deleting their repository and having your project being super broken.

(See also https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/EapE_L8TCdA/unsubscribe.

To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.