current build. It utilizes the `_api/v2/api_packages.txt` list of packages from
the local wheel file specified in the `requirements_lock_<python_version>.txt`.

Packages are imported one by one in alphabetical order during runtime.

The test doesn't identify package's order-dependent issues; for instance,
importing "tf.foo" followed by "tf.bar" won't reveal that "tf.bar" depends on
"tf.foo" being imported first.

# use the wheel's TensorFlow installation instead of the one made available
# through bazel. This must be done in a different root directory, //bazel_pip/...,
# because "import tensorflow" run from the root directory would instead import
# the folder instead of the venv package.
# 
# Pass --config=pip to run the same suite of tests. If you want to run just one
# test for investigation, you'll need --config=pip_venv instead, and then you

    airtime before a decision is made regarding whether they are to be migrated
    to the core.
*   As every PR requires several CPU/GPU hours of CI testing, we discourage
    submitting PRs to fix one typo, one warning,etc. We recommend fixing the
    same issue at the file level at least (e.g.: fix all typos in a file, fix
    all compiler warnings in a file, etc.)
*   Tests should follow the

- TensorFlow installation (pip package or built from source):
- TensorFlow library (version, if pip package or github SHA, if built from source):

### 2. Code

Provide code to help us reproduce your issues using one of the following options:

#### Option A: Reference colab notebooks

# use the wheel's TensorFlow installation instead of the one made available
# through bazel. This must be done in a different root directory, //bazel_pip/...,
# because "import tensorflow" run from the root directory would instead import
# the folder instead of the venv package.
# 
# Pass --config=pip to run the same suite of tests. If you want to run just one
# test for investigation, you'll need --config=pip_venv instead, and then you

implement, and therefore security issues deriving from their absence are not
considered a vulnerability in TensorFlow.

### Resource allocation

A denial of service caused by one model could bring down the entire server, but
we don't consider this as a vulnerability, given that models can exhaust
resources in many different ways and solutions exist to prevent this from

  bazel query --keep_going 'kind(py_test, //tensorflow/python/...) - attr("tags", "no_pip|manual", //tensorflow/python/...)' | grep -v -f $BATS_TEST_TMPDIR/ignore_deps_for_these_packages | paste -sd "+" - > $BATS_TEST_TMPDIR/deps
  # Find all one-step dependencies of those tests which are from //tensorflow
  # (since external deps will come from Python-level pip dependencies),
  # excluding dependencies and files that are known to be unneccessary.

        policy with `tf.data.experimental.service.ShardingPolicy` enum. It can
        be one of `OFF` (equivalent to today's `"parallel_epochs"` mode),
        `DYNAMIC` (equivalent to today's `"distributed_epoch"` mode), or one of
        the static sharding policies: `FILE`, `DATA`, `FILE_OR_DATA`, or `HINT`
        (corresponding to values of `tf.data.experimental.AutoShardPolicy`).

  # Find all one-step dependencies of those tests which are from //tensorflow
  # (since external deps will come from Python-level pip dependencies),
  # excluding dependencies and files that are known to be unneccessary.

#
# This setting is currently experimental. The 'v2' implementation does _not_
# correspond to a particular, finalized design; rather, it relates to
# developing one.
#
# The current aim of the 'v2' implementation is to allow 'unused' ops and
# kernels to be discarded by the linker (to the benefit of binary size).
bool_flag(
    name = "enable_registration_v2",