chore: remove unused scripts

.dockerignore

@@ -2,10 +2,6 @@
 .git
 .gitignore
 
-# Docker scaffolding
-Dockerfile
-.dockerignore
-
 # Python scaffolding
 *.py[cod]
 *.egg

docs/getting-started/_verifying.rst

@@ -1,8 +1,8 @@
 Verifying the Library
 ---------------------
 
-Once you have compiled a client library, whether using a Docker image,
-local installation or bazel, it is time for the fun part: actually running it!
+Once you have compiled a client library, whether using a local installation
+or bazel, it is time for the fun part: actually running it!
 
 Create a virtual environment for the library:
 

docs/getting-started/index.rst

@@ -5,29 +5,13 @@ This code generator is implemented as a plugin to ``protoc``, the compiler
 for `protocol buffers`_, and will run in any environment that Python 3.7+ and
 protocol buffers do.
 
-Because dependency management and such can be a significant undertaking, we
-offer a Docker image and interface which requires you only to have Docker
-installed and provide the protos for your API. Alternatively, the generator is
-also invocable via bazel rules.
+It is recommended to install the tool locally and run it through ``protoc``.
 
-It is also possible to install the tool locally and run it through ``protoc``,
-and this approach is fully supported.
-
-.. note::
-
-    The Docker approach is recommended for users new to this ecosystem, or
-    those which do not have a robust Python environment available. If you want
-    to experiment with generating client libraries but do not want to make
-    changes to the generator itself, try the Docker image first.
-
-    The bazel approach is recommended for established pipelines. It is more
-    lightweight than the Docker image but may take some more effort to set up.
 
 .. _protocol buffers: https://developers.google.com/protocol-buffers/
 
 .. toctree::
    :maxdepth: 4
 
-   docker
    local
    bazel

docs/getting-started/local.rst

@@ -3,11 +3,7 @@
 Local Installation
 ==================
 
-If you are just getting started with code generation for protobuf-based APIs,
-or if you do not have a robust Python environment already available, it is
-probably easier to get started using Docker: :ref:`getting-started/docker`
-
-However, this tool offers first-class support for local execution using
+This tool offers first-class support for local execution using
 ``protoc``. It is still reasonably easy, but initial setup will take a bit
 longer.
 

docs/templates.rst

@@ -130,33 +130,5 @@ provided by this library, use the special `DEFAULT` string:
     --python_gapic_opt="python-gapic-templates=/path/to/templates"
     --python_gapic_opt="python-gapic-templates=DEFAULT"
 
-Building with Docker
-~~~~~~~~~~~~~~~~~~~~
-
-When building with Docker, you instead provide the ``--python-gapic-templates``
-argument after the ``docker run`` command:
-
-.. code-block:: shell
-
-    $ docker run \
-      --mount type=bind,source=google/cloud/vision/v1/,destination=/in/google/cloud/vision/v1/,readonly \
-      --mount type=bind,source=dest/,destination=/out/ \
-      --mount type=bind,source=/path/to/templates,destination=/templates/,readonly \
-      --rm \
-      --user $UID \
-      gcr.io/gapic-images/gapic-generator-python \
-      --python-gapic-templates /templates/ \
-      --python-gapic-templates DEFAULT
-
-As before, to provide more than one location for templates, specify the
-argument more than once.
-
-.. warning::
-
-    If you are using custom templates with Docker, be sure to also mount
-    the directory with the templates into the Docker image; otherwise
-    the generator will not be able to read that directory. When specifying
-    the ``--python-gapic-templates`` argument, it is the path *inside*
-    the Docker image that matters!
 
 .. _Jinja: http://jinja.pocoo.org/docs/2.10/