search

go-modules-by-example / index

Go modules by example is a series of work-along guides
BSD 3-Clause "New" or "Revised" License
1.09k stars 90 forks source link

Clarification about using the "modules download cache" instead of vendoring #105

Closed hartzell closed 5 years ago

hartzell commented 5 years ago

The 012_modvendor intro includes this statement vis-a-vis vendoring:

In a modules world, the module download cache can be used as a higher fidelity source of module dependencies.

That sentence is a bit of a mind-blower. I'm unclear about how it can be higher fidelity; it seems that either the result of go mod vendor is correct or it isn't.

On the off chance that other folks are also confused, it'd be great if you can expand on the topic a bit. If you can clue me in I can write it up and PR it if that's easier for you.

Thanks!

myitcv commented 5 years ago

@hartzell "fidelity" is indeed the wrong word here with respect to a "clean" go mod vendor. The result of go mod vendor is a strict subset of the contents of the module download cache's zip file for the same module.

However, the point I was trying to convey here is that it's also quite easy for the contents of vendor to get outdated/modified etc. And unless you have suitable CI checks in place, you can't be sure it's identical to a clean go mod vendor, or the module download cache. Hence "higher fidelity".

This will, however, change with https://github.com/golang/go/issues/33848

hartzell commented 5 years ago

Ahhh.

Repeating back to see if I understand, the issue is that the module cache is updated every time go build (or many of the other commands) is run, whereas the vendor cache is only updated when someone explicitly invokes go mod vendor.

Do you think there's any point in updating 012_modvendor, or am I a rare duck?

I ran into golang/go#33848 separately (in the same research spree that led me here) and I'm enthusiastic about making vendoring a first class citizen.

Thanks!

myitcv commented 5 years ago

Repeating back to see if I understand, the issue is that the module cache is updated every time go build (or many of the other commands) is run, whereas the vendor cache is only updated when someone explicitly invokes go mod vendor.

Exactly.

Do you think there's any point in updating 012_modvendor, or am I a rare duck?

It might be worth it, although at some point we have to draw a line between how much detail we go into vs creating a neat summary. There are so many nuances of all this stuff... we could write a book!

hartzell commented 5 years ago

Lets see if anyone else stumbles on this issue and says "Me too!". I'll bet that https://github.com/golang/go/issues/33848 lands first.

myitcv commented 5 years ago

Sounds good. Thanks for raising for discussion in any case.