Vendor in apitools subset

[tseaver]

Pulls in the subset of apitools which #334 claims can be used to implement upload / download in gcloud.storage.key). These four modules do not use google-protorpc at all.

Updates the vendored-in modules to use relative imports (since they will only be used when the "real"
apitools is not available).

Updates our CI configuration to suppress PEP8 / lint checking for the vendored code.

[coveralls]

Coverage remained the same when pulling 3206541 on tseaver:334-vendor-apitools-subset into 572b864 on GoogleCloudPlatform:master.

[dhermes]

What is the diff between the code in https://github.com/craigcitro/apitools and those committed here? Can we also commit

• the SHA1 hash where we are syncing with the library
• a .patch file encapsulating our diff

If there is no diff, I'd be a fan of using a git submodule and just adding symlinks in the places we need.

Even if there is a diff, we could apply the .patch file in setup.py, though the complexity is probably not worth it.

[tseaver]

What is the diff between the code in https://github.com/craigcitro/apitools and those committed here?

This change copies in only the four modules expected (in #334) to be needed. It replaces the package-level __init__.py files with empty placeholders, and converts the imports to explicit relative form (from . import exceptions, for example).

Submodules are demon-spawn. :) We explicitly don't want all of apitools, because the bits that use protorpc are the problem we are trying to avoid.

I can see no benefit to applying a patch: we are going to have to garden these files by hand, but only until @craigcitro can get apitools to a released version supporting our desired versions (including transitive dependencies).

[coveralls]

Coverage remained the same when pulling 787a4d9 on tseaver:334-vendor-apitools-subset into 572b864 on GoogleCloudPlatform:master.

[dhermes]

I made https://gist.github.com/dhermes/0ba88c5dab4be4e60b9e with a patch file.

I am fine gardening the files by hand, but want to keep a clear record of how and when we changed it.

Hopefully it is quite temporary.

As for the imports, is there any reason we don't instead use absolute imports, since the path is fully under our control?

[coveralls]

Coverage remained the same when pulling e8d924a on tseaver:334-vendor-apitools-subset into 3b90004 on GoogleCloudPlatform:master.

[tseaver]

Rebased against master, adding explicit reference to source commit, plus description of deltas.

[coveralls]

Coverage remained the same when pulling fcb7a5e on tseaver:334-vendor-apitools-subset into 3b90004 on GoogleCloudPlatform:master.

[dhermes]

Can you check in the content from the source commit as part of the repo? People are likely to give up going through commit history to find it.

I know this seems a bit over the top, but there is a chance we'll be burdened with this code for awhile and I don't want to lose track of the delta from the source of "truth".

[tseaver]

I'll redo on a different PR.