docs(all): misc clean-up and add a navigation footer (#1846)

Author: kclowes

README.md

@@ -6,6 +6,8 @@
 [![uv](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/astral-sh/uv/main/assets/badge/v0.json)](https://github.com/astral-sh/uv)
 [![License](https://img.shields.io/github/license/ethereum/execution-spec-tests)](https://github.com/ethereum/execution-spec-tests/blob/main/LICENSE)
 
+The full execution-spec-tests documentation can be found [here](https://eest.ethereum.org/main/).
+
 [ethereum/execution-spec-tests](https://github.com/ethereum/execution-spec-tests) is both a collection of test cases and a framework implemented in Python to generate tests for Ethereum execution clients.
 
 The framework collects and executes the test cases in order to generate _test fixtures_ (JSON) which can be consumed by any execution client to verify their implementation of [ethereum/execution-specs](https://github.com/ethereum/execution-specs). The fixtures, which define state transition and block tests, are generated by the framework using one of the `t8n` command-line tools that are provided by most execution clients, see below for an overview of the supported `t8n` tools.

docs/CHANGELOG.md

@@ -57,6 +57,7 @@ Users can select any of the artifacts depending on their testing needs for their
 
 ### 📋 Misc
 
+- 🔀 Misc. doc updates, including a navigation footer ([#1846](https://github.com/ethereum/execution-spec-tests/pull/1846)).
 - 🔀 Remove Python 3.10 support ([#1808](https://github.com/ethereum/execution-spec-tests/pull/1808)).
 - 🔀 Modernize codebase with Python 3.11 language features ([#1812](https://github.com/ethereum/execution-spec-tests/pull/1812)).
 - ✨ Add changelog formatting validation to CI to ensure consistent punctuation in bullet points [#1691](https://github.com/ethereum/execution-spec-tests/pull/1691).

docs/filling_tests/filling_tests_command_line.md

@@ -6,7 +6,7 @@ The execution-spec-tests test framework uses the [pytest framework](https://docs
     The command-line options specific to filling tests can be listed via:
 
     ```console
-    fill --help
+    uv run fill --help
     ```
 
     See [Custom `fill` Command-Line Options](#custom-fill-command-line-options) for all options.
@@ -16,35 +16,35 @@ The execution-spec-tests test framework uses the [pytest framework](https://docs
 The test cases implemented in the `./tests` sub-directory can be listed in the console using:
 
 ```console
-fill --collect-only
+uv run fill --collect-only
 ```
 
 and can be filtered (by test path, function and parameter substring):
 
 ```console
-fill --collect-only -k warm_coinbase
+uv run fill --collect-only -k warm_coinbase
 ```
 
 Docstrings are additionally displayed when ran verbosely:
 
 ```console
-fill --collect-only -k warm_coinbase -vv
+uv run fill --collect-only -k warm_coinbase -vv
 ```
 
 ## Execution
 
 By default, test cases are filled for all forks already deployed to mainnet, but not for forks still under active development, i.e., as of time of writing, Q2 2023:
 
 ```console
-fill
+uv run fill
 ```
 
 will generate fixtures for test cases from Frontier to Shanghai.
 
 To generate all the test fixtures defined in the `./tests/shanghai` sub-directory and write them to the `./fixtures-shanghai` directory, run `fill` in the top-level directory as:
 
 ```console
-fill ./tests/shanghai --output="fixtures-shanghai"
+uv run fill ./tests/shanghai --output="fixtures-shanghai"
 ```
 
 !!! note "Test case verification"
@@ -53,25 +53,25 @@ fill ./tests/shanghai --output="fixtures-shanghai"
 To generate all the test fixtures in the `tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py` module, for example, run:
 
 ```console
-fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py
+uv run fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py
 ```
 
 To generate specific test fixtures from a specific test function or even test function and parameter set, obtain the corresponding test ID using:
 
 ```console
-fill --collect-only -q -k test_warm_coinbase
+uv run fill --collect-only -q -k test_warm_coinbase
 ```
 
 This filters the tests by `test_warm_coinbase`. Then find the relevant test ID in the console output and provide it to fill, for example, for a test function:
 
 ```console
-fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py::test_warm_coinbase_gas_usage
+uv run fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py::test_warm_coinbase_gas_usage
 ```
 
 or, for a test function and specific parameter combination:
 
 ```console
-fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py::test_warm_coinbase_gas_usage[fork_Paris-DELEGATECALL]
+uv run fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py::test_warm_coinbase_gas_usage[fork_Paris-DELEGATECALL]
 ```
 
 ## Execution for Development Forks
@@ -80,10 +80,10 @@ fill tests/shanghai/eip3651_warm_coinbase/test_warm_coinbase.py::test_warm_coinb
     By default, test cases are not filled for upcoming Ethereum forks so that they can be readily filled using the `evm` tool from the latest `geth` release.
 
     In order to fill test cases for an upcoming fork, ensure that the `evm` tool used supports that fork and features under test and use the `--until` or `--fork` flag.
-    
+
     For example, as of Q2 2023, the current fork under active development is `Cancun`:
     ```console
-    fill --until Cancun
+    uv run fill --until Cancun
     ```
 
     See: [Filling Tests for Features under Development](./filling_tests_dev_fork.md).
@@ -95,10 +95,10 @@ The `--evm-dump-dir` flag can be used to dump the inputs and outputs of every ca
 ## Other Useful Pytest Command-Line Options
 
 ```console
-fill -vv            # More verbose output
-fill -x             # Exit instantly on first error or failed test case
-fill --pdb -nauto   # Drop into the debugger upon error in a test case
-fill -s             # Print stdout from tests to the console during execution
+uv run fill -vv            # More verbose output
+uv run fill -x             # Exit instantly on first error or failed test case
+uv run fill --pdb -nauto   # Drop into the debugger upon error in a test case
+uv run fill -s             # Print stdout from tests to the console during execution
 ```
 
 ## Custom `fill` Command-Line Options
@@ -108,7 +108,7 @@ To see all the options available to fill, including pytest and pytest plugin opt
 To list the options that only specific to fill, use:
 
 ```console
-fill --help
+uv run fill --help
 ```
 
-For a complete, up-to-date list of all command-line options, see the [Fill Command-Line Options](filling_tests_command_line_options.md) page, which is automatically generated from the current `fill --help` output.
+For a complete, up-to-date list of all command-line options, see the [Fill Command-Line Options](filling_tests_command_line_options.md) page, which is automatically generated from the current `uv run fill --help` output.

docs/filling_tests/filling_tests_dev_fork.md

@@ -10,26 +10,26 @@ By default, execution-spec-tests only generates fixtures for forks that have bee
     === "via the `--fork` flag"
 
           ```console
-          fill -k 4844 --fork=Cancun -v
+          uv run fill -k 4844 --fork=Cancun -v
           ```
 
     === "via the `--from` flag"
 
           ```console
-          fill -k 4844 --from=Cancun -v
+          uv run fill -k 4844 --from=Cancun -v
           ```
 
     === "via the `--until` flag"
 
           ```console
-          fill -k 4844 --until=Cancun -v
+          uv run fill -k 4844 --until=Cancun -v
           ```
 
 !!! note "Specifying the `evm` binary via `evm-bin`"
      It is possible to explicitly specify the `evm` binary used to generate fixtures via the `--evm-bin` flag, for example,
 
      ```console
-     fill --fork=Cancun --evm-bin=/opt/bin/evm -v
+     uv run fill --fork=Cancun --evm-bin=/opt/bin/evm -v
      ```
 
 ## Further Help

docs/navigation.md

@@ -43,7 +43,6 @@
           * [Blockchain Tests](running_tests/test_formats/blockchain_test.md)
           * [Blockchain Engine Tests](running_tests/test_formats/blockchain_test_engine.md)
           * [Blockchain Engine X Tests](running_tests/test_formats/blockchain_test_engine_x.md)
-          * [EOF Tests](running_tests/test_formats/eof_test.md)
           * [Transaction Tests](running_tests/test_formats/transaction_test.md)
           * [Common Types](running_tests/test_formats/common_types.md)
           * [Exceptions](running_tests/test_formats/exceptions.md)

docs/running_tests/releases.md

@@ -26,7 +26,7 @@ Please see below for an explanation of the optional `<pre_release_name>` that is
 
 ### Standard Releases
 
-Releases are published on the @ethereum/execution-spec-tests [releases](https://github.com/ethereum/execution-spec-tests/releases) page. Standard releases are tagged using the format `vX.Y.Z` (they don't have a don't `<pre_release_name>`).
+Releases are published on the @ethereum/execution-spec-tests [releases](https://github.com/ethereum/execution-spec-tests/releases) page. Standard releases are tagged using the format `vX.Y.Z` (they don't have a `<pre_release_name>`).
 
 For standard releases, two tarballs are available:
 

docs/running_tests/running.md

@@ -110,7 +110,7 @@ See [Execute Command](./execute/index.md).
 
 ## Two Methods to Run EEST Simulators
 
-Many of the methods use the Hive Testing Environment to interact clients and run tests against them. These methods are also called Hive simulators. While Hive is always necessary to run simulators, they can be called in two different ways. Both of these commands execute the same simulator code, but in different environments, we take the example of the `eest/consume-engine` simulator:
+Many of the methods use the Hive Testing Environment to interact with clients and run tests against them. These methods are also called Hive simulators. While Hive is always necessary to run simulators, they can be called in two different ways. Both of these commands execute the same simulator code, but in different environments, we take the example of the `eest/consume-engine` simulator:
 
 1. `./hive --sim=eest/consume-engine` is a standalone command that installs EEST and the `consume` command in a dockerized container managed by Hive. This is the standard method to execute EEST [fixture releases](./releases.md) against clients in CI environments and is the method to generate the results at [hive.ethpandaops.io](https://hive.ethpandaops.io). See [Hive](./hive/index.md) and its [Common Options](./hive/common_options.md) for help with this method.
 2. `uv run consume engine` requires the user to clone and [install EEST](../getting_started/installation.md) and start a Hive server in [development mode](./hive/dev_mode.md). In this case, the simulator runs on the native system and communicate to the client via the Hive API. This is particularly useful during test development as fixtures on the local disk can be specified via `--input=fixtures/`. As the simulator runs natively, it is easy to drop into a debugger and inspect the simulator or client container state. See [Hive Developer Mode](./hive/dev_mode.md) for help with this method.

docs/running_tests/test_formats/eof_test.md

@@ -51,6 +51,7 @@ theme:
     - navigation.indexes
     - navigation.instant
     - navigation.tabs
+    - navigation.footer
   # disabled due to https://github.com/ethereum/execution-spec-tests/issues/816
   # palette:
   #   # Palette toggle for automatic mode