Add copy button to code blocks in PPT. (#408)

docs/conf.py

@@ -27,6 +27,17 @@
 html_static_path = ["static"]
 html_css_files = ["custom.css"]
 
+extensions = ["sphinx_copybutton"]
+
+# -- sphinx-copybutton configuration ----------------------------------------
+## sets up the expected prompt text from console blocks, and excludes it from
+## the text that goes into the clipboard.
+copybutton_exclude = '.linenos, .gp'
+copybutton_prompt_text = ">> "
+
+## lets us suppress the copy button on select code blocks.
+copybutton_selector = "div:not(.no-copybutton) > div.highlight > pre"
+
 # -- Options for HTML output -------------------------------------------------
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-html-output
 

docs/practices/ci_benchmarking.rst

@@ -33,9 +33,9 @@ airspeed velocity. You may need to perform minor changes to this file. For examp
 to install dependencies declared on a ``requirements.txt`` file, you may want to set the
 ``install_command`` as follows:
 
-    .. code:: bash
+    .. code:: console
 
-        python -m pip install -r requirements.txt {wheel_file}
+      >> python -m pip install -r requirements.txt {wheel_file}
 
 For more information about this configuration file, visit the
 `asv.conf.json reference <https://asv.readthedocs.io/en/stable/asv.conf.json.html>`_.
@@ -66,7 +66,7 @@ This workflow is triggered on pushes to the main branch.
   the first run will take a while because it will process every commit on the repository to the present day, 
   but subsequent runs will be faster.
 
-   .. code:: bash
+   .. code:: console
 
       >> asv run ALL --skip-existing
 
@@ -127,15 +127,15 @@ are several questions you'll be asked the first time, and you may need to instal
 a new python venv. When your local environment is properly configured, it runs 
 the benchmarking suite for your most recent commit
 
-.. code:: bash
+.. code:: console
 
     >> cd benchmarks
     >> asv run
 
 You will need to commit changes locally for the new code to be picked up by ASV.
 Having benchmarks for several revisions, you can find them and compare them with ease.
 
-.. code:: bash
+.. code:: console
     
     >> asv show
       Commits with results:
@@ -153,7 +153,7 @@ of commits and even tags. For more information visit ASV's
 
 If your benchmark fails, you can re-run and find more information with the following:
 
-.. code:: bash
+.. code:: console
 
     >> asv run --show-stderr
 

docs/practices/code_coverage.rst

@@ -22,6 +22,6 @@ install the GitHub app, Codecov.
 * Select your repository and follow the instructions
 
 On your Codecov repository click "Settings" and under "Tokens" copy the value of
-`CODECOV_TOKEN`. Add it as a secret on your GitHub repository and you're all set!
+``CODECOV_TOKEN``. Add it as a secret on your GitHub repository and you're all set!
 
 Future pull requests and commits will now include code coverage information. Neato!

docs/practices/git-lfs.rst

@@ -8,7 +8,7 @@ After cloning a repository and connecting to the resulting working tree confirm
 that you have ``git-lfs`` and then issue ``git lfs install`` to install 
 configuration and hooks and then ``git lfs track`` to designate targets for git-lfs.
 
-.. code-block:: bash
+.. code-block:: console
 
     git-lfs --version
     git lfs install --local
@@ -53,7 +53,7 @@ That site will show you instructions most appropriate for your platform.
 
 You may also use conda as it has a ``git-lfs`` package appropriately named.
 
-.. code-block:: bash
+.. code-block:: console
 
     conda install git-lfs
 
@@ -65,7 +65,7 @@ Install git-lfs in the local repository
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Once you have git-lfs use it to install support into the repository with the command
 
-.. code-block:: bash
+.. code-block:: console
 
     git lfs install --local
 
@@ -85,13 +85,13 @@ the needed changes and create the file if necessary.
 For example, if you want to specify that ``FITS`` files are handled by git-lfs 
 then you might use these commands
 
-.. code-block:: bash
+.. code-block:: console
 
     git lfs track '*.fits' '*.fits.fz'
 
 You can see a list of currently tracked names
 
-.. code-block:: bash
+.. code-block:: console
 
     git lfs track
 
@@ -109,7 +109,7 @@ specified the ``--local`` option you should also specify it here.
 Probably it is safer to always include the ``--local`` option so you restrict 
 impact to the current repository.
 
-.. code-block:: bash
+.. code-block:: console
 
     git lfs uninstall --local
 
@@ -120,7 +120,7 @@ Note that we recommend against uninstalling git-lfs as it causes confusion.
 
 You can see what files are controlled by git-lfs using the ``git lfs ls-files`` command
 
-.. code-block:: bash
+.. code-block:: console
 
     git lfs ls-files
 

docs/practices/linting.rst

@@ -62,13 +62,13 @@ linting tool, that can also perform auto-formatting.
 
 This tool can be run on its own in *linting* (warning) mode with command like:
 
-.. code:: bash
+.. code:: console
 
     >> ruff check
 
 This tool can be run on its own in *auto-formatting* mode with command like:
 
-.. code:: bash
+.. code:: console
 
     >> ruff format
 
@@ -121,7 +121,7 @@ formatting (e.g. spacing, quote styles, line breaks).
 
 This tool can be run on its own with command like:
 
-.. code:: bash
+.. code:: console
 
     >> black .
 
@@ -141,7 +141,7 @@ the `.py` and `.pyi` files in your project.
 
 This tool can be run on its own with command like:
 
-.. code:: bash
+.. code:: console
 
     >> isort .
 

docs/practices/namespace_project.rst

@@ -36,7 +36,7 @@ Example
 Follow the instructions at :doc:`New Project <../source/new_project>` to create a new 
 project named **acme-supernovae** with a package named **supernovae**.
 
-.. code-block:: bash
+.. code-block:: console
 
     copier copy gh:lincc-frameworks/python-project-template acme-supernovae
     cd acme-supernovae
@@ -51,7 +51,7 @@ might break over time as code changes and other uses of **src** are confused by
 Define bash functions to find the files containing **src** and to perform the change using 
 sed so first add the shell functions.
 
-.. code-block:: bash
+.. code-block:: console
 
     organization=acme
     subpackage=supernovae
@@ -65,21 +65,21 @@ sed so first add the shell functions.
 
 It is wise to review the changes before committing them.
 
-.. code-block:: bash
+.. code-block:: console
 
     git diff
 
 Assuming all is good
 
-.. code-block:: bash
+.. code-block:: console
 
     git add .
     git commit -m "finished move from src to ${organization}"
 
 Add a clause to pyproject.toml to declare this as a namespace package. Again, you might want to
 review the results before committing. At least take a look so you see what it added.
 
-.. code-block:: bash
+.. code-block:: console
 
     tr '|' '\n' <<<'|[tool.setuptools.packages.find]|where = ["."]|include = ["'"${organization}"'"]|namespaces = true' >>pyproject.toml
     git add .
@@ -90,7 +90,7 @@ the package is now a namespace package. This is done by adding a clause to the i
 
 This might be the trickiest bit although for a brand new project it does very little.
 
-.. code-block:: bash
+.. code-block:: console
 
     myfiles2() { find . -name .git -prune -o -type f \( -name '*.py' -o -name '*.ipynb' \) -print; }
     mysed2() { sed -e "/import/s%${subpackage}%${organization}.${subpackage}%g;" "${1}" >.tmpfile && mv "${1}" .oldfile && mv .tmpfile "${1}" && rm .oldfile; }
@@ -104,15 +104,15 @@ This might be the trickiest bit although for a brand new project it does very li
 Build the project and install. We recommend that you do this in a virtual environment.
 In this example we build for '.[dev]' and also run the pre-commit hooks as a verification step.
 
-.. code-block:: bash
+.. code-block:: console
 
     pip install -e '.[dev]'
     pre-commit run --all-files
 
 Create a new project named **acme-utilities** with a package named **utilities** and convert it to a namespace package
 using exactly the same process as above but with different names.  Then install and check with pre-commit hooks.
 
-.. code-block:: bash
+.. code-block:: console
 
     cd ..
     copier copy gh:lincc-frameworks/python-project-template acme-utilities
@@ -153,7 +153,7 @@ using exactly the same process as above but with different names.  Then install
 
 Try it out.  In this example we use the python interpreter to import the subpackages and run the examples.
 
-.. code-block:: bash
+.. code-block:: console
 
     $ python
     >>> from acme import supernovae, utilities
@@ -167,6 +167,6 @@ Try it out.  In this example we use the python interpreter to import the subpack
 
 You might want to uninstall the packages to avoid python environment bloat!
 
-.. code-block:: bash
+.. code-block:: console
 
     pip uninstall acme-supernovae acme-utilities

docs/practices/pipx.rst

@@ -41,7 +41,7 @@ installation process that is most straightforward for you system.
 
 An example installation of ``pipx`` might look like this. 
 
-.. code-block:: bash
+.. code-block:: console
     
         >> conda install -c conda-forge pipx
         >> pipx ensurepath

docs/practices/precommit.rst

@@ -14,7 +14,7 @@ development. Additional documentation can be found
 To configure pre-commit for your project, run the following command to register 
 pre-commit hooks with ``.git/hooks/pre-commit``.
 
-.. code-block:: bash
+.. code-block:: console
     
     pre-commit install
 

docs/practices/pytest_timeout.rst

@@ -76,7 +76,7 @@ Other fun things you can do
 Even if you're not using this package, you can find slow-running tests in your
 suite with the ``--durations`` flag.
 
-.. code-block:: bash
+.. code-block:: console
 
     pytest --durations=10
 

docs/practices/sphinx.rst

@@ -42,7 +42,7 @@ How to manage
 To build the documentation in your local development environment, it's best to 
 follow the same steps as readthedocs will perform when building your documentation.
 
-.. code-block:: bash
+.. code-block:: console
 
     cd $project_directory
     pip install -e .
@@ -74,7 +74,7 @@ Alternatively, you can make Sphinx ignore all of the notebooks in your documenta
 while still building everything else. To do so, you will need to run sphinx in make 
 mode, which allows the use of the -D flag to override excluded files.
 
-.. code-block:: bash
+.. code-block:: console
 
     cd $project_directory
     pip install -e .
@@ -83,7 +83,7 @@ mode, which allows the use of the -D flag to override excluded files.
 
 Or, using the command in the included Makefile,
 
-.. code-block:: bash
+.. code-block:: console
 
     cd $project_directory
     pip install -e .

docs/requirements.txt

@@ -1,2 +1,3 @@
 sphinx
 sphinx-rtd-theme
+sphinx-copybutton

docs/source/contributing.rst

@@ -33,7 +33,7 @@ You probably don't want to create new tags while you're working on the template.
 Create a test project using the following command to let Copier know to use the
 latest local version.
 
-.. code-block:: bash
+.. code-block:: console
 
     >> copier copy --vcs-ref HEAD </local/path/to/template> </test/project/directory>
 

docs/source/existing_project.rst

@@ -55,7 +55,7 @@ make it easier to see what changes are being made.
 Hydrate a copy of the template into your project
 ................................................
 
-.. code:: bash
+.. code:: console
 
     >> cd <existing_project_directory>
     >> copier copy gh:lincc-frameworks/python-project-template .
@@ -72,7 +72,7 @@ that tests will be contained in a first level directory named ``tests``.
 For example, if your project is in a directory named ``/science``, and your package
 is named ``new_science``, your source code and tests might look like this:
 
-.. code:: bash
+.. code:: console
 
     /science/src/new_science/module.py
     /science/tests/new_science/test_module.py
@@ -108,7 +108,8 @@ and Copier does not have the ability permanently overwrite your files.
 The following example is output from a Copier update. Note again that ``conflict`` is 
 simply an indicator that you should review that file before committing.
 
-.. code :: bash
+.. code-block:: console
+    :class: no-copybutton
 
     Copying from template version 1.2.1
     identical  .
@@ -148,7 +149,7 @@ You should attempt to use ``pip`` to build your package and install dependencies
 Failure to build successfully may be an indicator of a corrupted pyproject.toml file
 or missing dependencies.
 
-.. code:: bash
+.. code:: console
 
     >> pip install -e .'[dev]'
 
@@ -191,7 +192,7 @@ Install and use ``pre-commit``. It may seem annoying at first, but it will save
 you many cycles of "see a test fail on GitHub, make and push a change, hope the 
 test passes". Installation is easy!
 
-.. code:: bash
+.. code:: console
 
     >> pre-commit install
 
@@ -215,7 +216,7 @@ or another linting tool, it's reasonable to skip the linting check on the first
 For instance if you selected ``black`` as your new linter, use the following to 
 bypass the pre-commit linting check on the first commit.
 
-.. code :: bash
+.. code:: bash
 
     >> SKIP=black git commit -m 'Incorporating LINCC Frameworks PPT'