Glide v0.12.0+ calls out to internet during glide install

[RochesterinNYC]

Previously, glide install would not have to call out to the internet at all if your packages were already properly vendored like in this fixture app.

However, as of v0.12.0, it seems that glide will, with the same fixture app, hit the internet once during glide install. The traffic log indicates the following:

internet traffic: P 172.17.0.2.53676 > 192.30.253.113.443: Flags [S], seq 567018780, win 29200, options [mss 1460,sackOK,TS val 175422899 ecr 0,nop,wscale 7], length 0

This seems to be a request to github.com.

Is there anything that was added in the v0.12 release that causes this?

[sdboyer]

Yes, v0.12.0 introduced a new system for retrieving and caching upstream repositories in a central location, and the change is, no doubt, a side effect of that.

I don't know if it's feasible in glide's current design to avoid that call, or not. (This is something that gps - #384 - has taken some steps towards, but it's not yet to the point where it would completely avoid touching the network in the case you describe.)

[RochesterinNYC]

Gotcha, is there a way to turn off this functionality for the time being? Our use case is using glide with a vendored app in a fire-walled environment that does not allow any external connections to be made.

Thanks so much for your clarifications.

[sdboyer]

Sure, happy to provide information. Sadly, there is not a way around this - this kind of central cache is to be the way of things moving forward. I hate to say it, but your best immediate bet is probably to downgrade :(

This is the first time I've seen someone report actually report this use case, though, so while it's been on my radar for a while, seeing that it's actually affecting someone boosts the priority of work towards the "no network" use case. Unfortunately, even if we do get gps merged in for glide v0.13.0, this particular fix is still probably a couple months away.

[RochesterinNYC]

Ah okay, gotcha. So the internet call might be eliminated with v0.13.0? Or did you mean that the work will still be pending until after the v0.13.0 release? Thanks for the response.

Yes, the context is that we support glide in the go buildpack for Cloud Foundry. A lot of Cloud Foundry users are enterprise companies and have completely fire-walled environments. Enterprise go developers are a thing apparently! I think for the time being, we'll stick to < v0.12.0 and keep up to date with the release notes and we'll update when, in the far future, offline capabilities are supported.

[mattfarina]

@RochesterinNYC I might be able to help and provide a little insight.

First, can you check it vendor/ exists and is not empty. If it does not exist or is empty then run glide install. This is safer no matter what version of Glide comes along.

Depending on the Glide flags you used, glide install has gone out to the Internet for some time. That includes versions prior to 0.12.x. If you didn't see that before I'd love to see more information.

[RochesterinNYC]

@mattfarina Okay, maybe our understanding of how to properly use glide is mistaken. If a vendor directory with the dependencies already exists, is running glide install redundant? Should we only be running glide install on Go apps that either do not have a vendor directory or that have an empty vendor directory?

If this is true, is there a non-install glide command that can check if the vendor directory has all the appropriate dependencies without calling out to internet?

[RochesterinNYC]

@mattfarina any advice on glide usage under these circumstances?

[sdboyer]

@RochesterinNYC yes, if you already have a fully populated vendor directory, then running glide install would be redundant.

I don't think a command exists now that does that. If one does, though, there's a low limit on the amount of "checking" it could do without relying on VCS repository data.

Basically, it could make sure that the directories specified in glide.lock exist, and that they have at least some go files in them...but that's it.

[RochesterinNYC]

@sdboyer I think a command like that would be valuable? It feels a little like bundle check or something. It feels a little odd to make a user that wants to check if their packages are already vendored run glide install. Moreso, if their packages are already correctly vendored and they run glide install, it ends up not truly being a no-op as it will hit the internet and etc. Open to thoughts here as we're coming here from a predominantly Ruby background.

[RochesterinNYC]

@sdboyer would y'all take a pull request for something like glide check that would determine if all the packages in vendor are present?

[sdboyer]

@RochesterinNYC 👍

Now, if the cache isn't populated already with the repos named in the lock file, then there's a limited to the amount of checking that can be done: you can't verify that what's there is correct, just that it's present. And there's not enough information to check for subpackages.

But still - a command that checks based on what information is on hand in the lock file? Sure, that sounds reasonable to me. @mattfarina?