pip_import() chokes on requirement markers/specifiers

[michaelsafyan]

Summary

The requirements format supports not just version numbers but also markers for various options. When a dependency uses these indirectly for its own dependencies, it produces a breakage.

Reproduce case

WORKSPACE:

load("@io_bazel_rules_python//python:pip.bzl", "pip_repositories", "pip_import")
pip_repositories()
pip_import(
   name = "pip_deps",
   requirements = "//:requirements.txt",
 )
 load("@pip_deps//:requirements.bzl", "pip_install")
 pip_install()

requirements.txt:

 google-cloud-datastore==1.4.0

Observed

The generated file external/pypi__gapic_google_cloud_datastore_v1_0_15_3/BUILD contains:

package(default_visibility = ["//visibility:public"])

load("@pip_deps//:requirements.bzl", "requirement")

py_library(
     name = "pkg",
     srcs = glob(["**/*.py"]),
     data = glob(["**/*"], exclude=["**/*.py", "**/* *", "BUILD", "WORKSPACE"]),
     # This makes this directory a top-level in the python import
     # search path for anything that depends on this.
     imports = ["."],
     deps = [requirement("google-gax"),requirement("googleapis-common-protos[grpc]"),requirement("oauth2client"),requirement("proto-google-cloud-datastore-v1[grpc]")],
 )

Note in the above the [grpc] marker attached to some of these requirements. The "requirement()" function does not handle these properly, and the result is an error that looks like:

 key "googleapis_common_protos[grpc]" not found in dictionary

It seems like the code that generates the BUILD file here should omit the bracketed terms (these terms should factor in the particular version/variant fetched but not in the reference to the library).

Expected

Depending on google-cloud-datastore==1.4.0 (or any pip dependency) should work.

[michaelsafyan]

Note: I observed this issue with commit="8f3daa17c1e5050cf0382f7fe60c1cd7c7067f3c". It appears that the issue no longer reproduces when synced to a more recent revision (I can no longer reproduce this when synced to "3e167dcfb17356c68588715ed324c5e9b76f391d"). Sorry for re-reporting this.