instead of 2.15, or users could receive an installation error due to
        those missing dependencies.
*   TensorFlow 2.15.0.post1 is being released for Linux x86_64 to resolve this
    issue as quickly as possible.
    *   This version removes the `tensorrt` Python package dependencies from the
        tensorflow[and-cuda] installation method to ensure `pip install

// Specify the server_def that enables collective ops.
// This is different to the above function in that it doesn't create remote
// contexts, and remotely executing ops is not possible. It just enables
// communication for collective ops.
TF_CAPI_EXPORT extern void TFE_EnableCollectiveOps(TFE_Context* ctx,
                                                   const void* proto,

    echo "Look at the instructions for ':api_compatibility_test -- --update_goldens=True'"
}

# See b/279852433 (internal).
# TODO(b/279852433) Replace deps(//tensorflow/...) with deps(//...)
@test "Verify that it's possible to query every TensorFlow target without BUILD errors" {
    bazel query "deps(//tensorflow/...)" > /dev/null
}

teardown_file() {
    bazel shutdown

  // operations and may be fetched by calling FetchJVP. ForwardAccumulator
  // maintains a reference to these JVPs: if an `output_tensors` Tensor is
  // deleted, `DeleteGradient` should be called as soon as possible to free the
  // (now inaccessible) corresponding JVPs, but ForwardAccumulator's destructor
  // will release remaining references.
  //
  // This method is not thread-safe (and in general ForwardAccumulator is not

build:windows --copt=/d2ReducedOptimizeHugeFunctions
build:windows --host_copt=/d2ReducedOptimizeHugeFunctions

# Enable the runfiles symlink tree on Windows. This makes it possible to build
# the pip package on Windows without an intermediate data-file archive, as the
# build_pip_package script in its current form (as of Aug 2023) uses the
# runfiles symlink tree to decide what to put into the Python wheel.

    python_lib_paths = get_python_path(environ_cp, python_bin_path)
    if environ_cp.get('USE_DEFAULT_PYTHON_LIB_PATH') == '1':
      python_lib_path = python_lib_paths[0]
    else:
      print('Found possible Python library paths:\n  %s' %
            '\n  '.join(python_lib_paths))
      default_python_lib_path = python_lib_paths[0]
      python_lib_path = get_input(

```

**Standalone code to reproduce the issue** 
Provide a reproducible test case that is the bare minimum necessary to generate
the problem. If possible, please share a link to Colab/Jupyter/any notebook.

Also, please include a link to a GraphDef or the model if possible.

**Any other info / logs**

Include any logs or source code that would be helpful to diagnose the problem.

fi
source ci/official/utilities/get_versions.sh

# Note on gsutil commands:
# "gsutil cp" always "copies into". It cannot act on the contents of a directory
# and it does not seem possible to e.g. copy "gs://foo/bar" as anything other than
# "/path/bar". This script uses "gsutil rsync" instead, which acts on directory
# contents. About arguments to gsutil:
# "gsutil -m rsync" runs in parallel.

# limitations under the License.
# ==============================================================================
#
# Common setup for all TF scripts.
#
# Make as FEW changes to this file as possible. It should not contain utility
# functions (except for tfrun); use dedicated scripts instead and reference them
# specifically. Use your best judgment to keep the scripts in this directory

//   and fills it with error info on failure.
// * unsigned char is used for booleans (instead of the 'bool' type).
//   In C++ bool is a keyword while in C99 bool is a macro defined
//   in stdbool.h. It is possible for the two to be inconsistent.
//   For example, neither the C99 nor the C++11 standard force a byte
//   size on the bool type, so the macro defined in stdbool.h could