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.

The `_api/v2/api_packages.txt` file is generated during the TensorFlow API v2
init files creation process and is subsequently stored in the wheel file after

    hdrs = ["filesystem_interface.h"],
    visibility = ["//visibility:public"],
    deps = [
        "//tensorflow/c:tf_file_statistics",
        "//tensorflow/c:tf_status",
    ],
)

# Core TensorFlow depends on this, will be included in main library
cc_library(
    name = "modular_filesystem",
    srcs = [
        "modular_filesystem.cc",
        "modular_filesystem_registration.cc",
    ],
    hdrs = [

available to TensorFlow is powerful enough that you should assume that the
TensorFlow process effectively executes arbitrary code.

The risk of loading untrusted checkpoints depends on the code or graph that you
are working with. When loading untrusted checkpoints, the values of the traced
variables from your model are also going to be untrusted. That means that if

# instead depend on the dummy plugins in @local_tsl//tsl/platform/default/build_config
# and use header only targets.
# TODO(ddunleavy): This seems completely broken. :tensorflow_cc depends on
# cuda_platform from tf_additional_binary_deps and this doesn't break.
check_deps(
    name = "cuda_plugins_check_deps",
    disallowed_deps = if_static(
        [],
        otherwise = [

*   Improved DirectSession::Run() overhead and error checking. Feeding a value
    of the wrong type will now synchronously raise an INVALID_ARGUMENT error
    instead of asynchronously raising an INTERNAL error. Code that depends on
    the (undefined) behavior when feeding a tensor of the wrong type may need to
    be updated.
*   Added unreduced NONE, and reduced MEAN options for losses. Removed

build:rbe_cross_compile_base --config=rbe_base
build:rbe_cross_compile_base --remote_instance_name=projects/tensorflow-testing/instances/default_instance

# XLA depends on some local Python headers that are configured as Genrule. They
# are present on the local host machine but not on the remote execution machine,
# leading to build failures. To resolve the issue, the following line is added

// TF_SessionRun will no longer extend the session on every call.
//
// We expose this here to allow fine-grained synchronization in multi-threaded
// workloads, which is required since the Python implementation depends on the
// above mutation methods. This allows us to prevent modifications to nodes in
// the graph after the session has been made aware of them.
TF_CAPI_EXPORT extern void TF_ExtendSession(TF_Session* session,