diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml index 0c0d05388..cbf32afd8 100644 --- a/.github/workflows/tests.yml +++ b/.github/workflows/tests.yml @@ -135,7 +135,7 @@ jobs: verbose: true - name: Run the accessibility audit - run: python docs/a11y.py --no-serve + run: python docs/scripts/a11y.py --no-serve # Check the audit for threshold values # TODO: write this someplace after a PR is merged, and load? diff --git a/docs/_templates/custom-template.html b/docs/_templates/custom-template.html index be9854c83..0ed45ec1c 100644 --- a/docs/_templates/custom-template.html +++ b/docs/_templates/custom-template.html @@ -1,6 +1,6 @@ diff --git a/docs/_templates/navbar-version.html b/docs/_templates/navbar-version.html index 35aaf29b3..b23c1ca17 100644 --- a/docs/_templates/navbar-version.html +++ b/docs/_templates/navbar-version.html @@ -1 +1,2 @@ -v{{ version }} + +TEST: v{{ version }} diff --git a/docs/changelog.rst b/docs/changelog.rst deleted file mode 100644 index 369e044d2..000000000 --- a/docs/changelog.rst +++ /dev/null @@ -1,9 +0,0 @@ -********* -Changelog -********* - -See the `GitHub Releases `_ for the changelog of each release. - -.. meta:: - :description lang=en: - The historical releases for pydata-sphinx-theme. diff --git a/docs/conf.py b/docs/conf.py index cdbcf7aaa..a22633757 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -34,11 +34,12 @@ # ones. extensions = [ + "jupyter_sphinx", + "myst_parser", + "numpydoc", "sphinx.ext.autodoc", "sphinx.ext.autosummary", - "numpydoc", - "myst_parser", - "jupyter_sphinx", + "sphinxext.rediraffe", ] # -- Internationalization ------------------------------------------------ @@ -64,11 +65,6 @@ # This pattern also affects html_static_path and html_extra_path. exclude_patterns = ["_build", "Thumbs.db", ".DS_Store"] -html_sidebars = { - "contributing": ["search-field", "custom-template"], - "changelog": [], -} - # -- Options for HTML output ------------------------------------------------- # The theme to use for HTML and HTML Help pages. See the documentation for @@ -79,7 +75,11 @@ html_theme_options = { "external_links": [ - {"url": "https://pandas.pydata.org/pandas-docs/stable/", "name": "Pandas Docs"} + { + "url": "https://github.com/pydata/pydata-sphinx-theme/releases", + "name": "Changelog", + }, + {"url": "https://pandas.pydata.org/pandas-docs/stable/", "name": "Pandas Docs"}, ], "github_url": "https://github.com/pydata/pydata-sphinx-theme", "twitter_url": "https://twitter.com/pandas_dev", @@ -107,6 +107,14 @@ }, } +html_sidebars = { + "contribute/index": [ + "search-field", + "sidebar-nav-bs", + "custom-template", + ], # This ensures we test for custom sidebars +} + html_context = { "github_user": "pandas-dev", @@ -115,6 +123,10 @@ "doc_path": "docs", } +rediraffe_redirects = { + "contributing.rst": "contribute/index.rst", +} + # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". diff --git a/docs/contribute/index.md b/docs/contribute/index.md new file mode 100644 index 000000000..b397ec748 --- /dev/null +++ b/docs/contribute/index.md @@ -0,0 +1,58 @@ +--- +html_meta: + "description lang=en": "How to become a contributor to the pydata-sphinx-theme." +--- + +# Contribute + +These pages contain information about how you can get up-and-running with a development version of this theme, and how you can contribute to the project. + +## Workflow for contributing changes + +We follow a [typical GitHub workflow](https://guides.github.com/introduction/flow/) +of: + +- create a personal fork of this repo +- create a branch +- open a pull request +- fix findings of various linters and checks +- work through code review + +For each pull request, the demo site is built and deployed to make it easier to review +the changes in the PR. To access this, click on the "ReadTheDocs" preview in the CI/CD jobs. + +## Location and structure of documentation + +The documentation for this theme is in the `docs/` folder. +It is structured as a [Sphinx documentation site](https://sphinx-doc.org). +The content is written in a combination of reStructuredText and MyST Markdown. + +## Location and structure of CSS/JS assets + +The CSS and JS for this theme are built for the browser from `src/pydata_sphinx_theme/assets/*` with +[webpack](https://webpack.js.org/). The main entrypoints are: + +- CSS: `src/pydata_sphinx_theme/assets/styles/index.scss` + + - the main part of the theme assets + - customizes [Bootstrap](https://getbootstrap.com/) with [Sass](https://sass-lang.com) + - points to the `font-face` of vendored web fonts, but does not include their + CSS `@font-face` declaration + +- JS: `src/pydata_sphinx_theme/assets/scripts/index.js` + + - provides add-on Bootstrap features, as well as some custom navigation behavior + +- webpack: `webpack.config.js` + + - captures the techniques for transforming the JS and CSS source files in + `src/pydata_sphinx_theme/assets/*` into the production assets in `src/theme/pydata_sphinx_theme/static/` + +**For more information** about developing this theme, see the sections below and in the left sidebar. + +```{toctree} +:maxdepth: 2 +setup +topics +manual +``` diff --git a/docs/contribute/manual.md b/docs/contribute/manual.md new file mode 100644 index 000000000..7da89c758 --- /dev/null +++ b/docs/contribute/manual.md @@ -0,0 +1,76 @@ +(manual-environment)= + +# Set up a manual development environment + +If you prefer not to use automation tools like `nox`, or want to have more control over the specific version of packages that you'd like like installed, you may also manually set up a development environment locally. + +To do so, follow the instructions on this page. + +## Create a new development environment + +This is optional, but it's best to start with a fresh development environment so that you've isolated the packages that you're using for this repository. + +To do so, use a tool like [conda](https://docs.conda.io/en/latest/), [mamba](https://github.com/mamba-org/mamba), or [virtualenv](https://virtualenv.pypa.io/). + +## Clone the repository locally + +First clone this repository from the `pydata` organization, or from a fork that you have created: + +```console +$ git clone https://github.com/pydata/pydata-sphinx-theme +$ cd pydata-sphinx-theme +``` + +## Install the `sphinx-theme-builder` + +We use the `sphinx-theme-builder` to install `nodejs` locally and to compile all CSS and JS assets needed for the theme. +Install it like so (note the `cli` option so that we can run it from the command line): + +```console +$ pip install sphinx-theme-builder[cli] +``` + +## Install this theme locally + +Next, install this theme locally so that we have the necessary dependencies to build the documentation and testing suite: + +```console +$ pip install -e .[dev] +``` + +Note that the `sphinx-theme-builder` will automatically install a local copy of `nodejs` for building the theme's assets. +This will be placed in a `.nodeenv` folder. + +## Build the documentation + +To manually build the documentation, run the following command: + +```console +$ sphinx-build docs docs/_build/html +``` + +## Compile web assets (JS/CSS) + +To compile the javascript and CSS assets for the theme, run the following command: + +```console +$ stb compile +``` + +This will compile everything in the `src/pydata_sphinx_theme/assets` folder and place them in the appropriate places in our theme's folder structure. + +## Start a live-server to build and serve your documentation + +To manually open a server to watch your documentation for changes, build them, and display them locally in a browser, run this command: + +```console +$ stb serve docs --open-browser +``` + +## Run the tests + +To manually run the tests for this theme, first set up your environment locally, and then run: + +```console +$ pytest +``` diff --git a/docs/contribute/setup.md b/docs/contribute/setup.md new file mode 100644 index 000000000..aed420f18 --- /dev/null +++ b/docs/contribute/setup.md @@ -0,0 +1,163 @@ +# Get started with development + +This section covers the simplest way to get started developing this theme locally so that you can contribute. +It uses automation and as few steps as possible to get things done. +If you'd like to do more operations manually, see [](manual.md). + +## Clone the repository + +First off you'll need your own copy of the `pydata-sphinx-theme` codebase. +You can clone it for local development like so: + +1. **Fork the repository** so you have your own copy on GitHub. + See [the GitHub forking guide](https://docs.github.com/en/get-started/quickstart/fork-a-repo) for more information. +2. **Clone the repository locally** so that you have a local copy to work from: + + ```console + $ git clone https://github.com/{{ YOUR USERNAME }}/pydata-sphinx-theme + $ cd pydata-sphinx-theme + ``` + +## Install your tools + +Building a Sphinx site uses a combination of Python and Jinja to manage HTML, SCSS, and Javascript. +To simplify this process, we use a few helper tools: + +- [The Sphinx Theme Builder](https://sphinx-theme-builder.readthedocs.io/en/latest/) to automatically perform compilation of web assets. +- [pre-commit](https://pre-commit.com/) for automatically enforcing code standards and quality checks before commits. +- [nox](https://nox.thea.codes/), for automating common development tasks. + +In particular, `nox` can be used to automatically create isolated local development environments with all of the correct packages installed to work on the theme. +The rest of this guide focuses on using `nox` to start with a basic environment. + +```{seealso} +The information on this page covers the basics to get you started, for information about manually compiling assets, see [](manual.md). +``` + +### Setup `nox` + +To start, install `nox`: + +```console +$ pip install nox +``` + +You can call `nox` from the command line in order to perform common actions that are needed in building the theme. +`nox` operates with isolated environments, so each action has its own packages installed in a local directory (`.nox`). +For common development actions, you'll simply need to use `nox` and won't need to set up any other packages. + +### Setup `pre-commit` + +`pre-commit` allows us to run several checks on the codebase every time a new Git commit is made. +This ensures standards and basic quality control for our code. + +Install `pre-commit` with the following command: + +```console +$ pip install pre-commit +``` + +then navigate to this repository's folder and activate it like so: + +```console +$ pre-commit install +``` + +This will install the necessary dependencies to run `pre-commit` every time you make a commit with Git. + +:::{note} +Your `pre-commit` dependencies will be installed in the environment from which you're calling `pre-commit`, `nox`, etc. +They will not be installed in the isolated environments used by `nox`. +::: + +## Build the documentation + +Now that you have `nox` installed and cloned the repository, you should be able to build the documentation locally. + +To build the documentation with `nox`, run the following command: + +```console +$ nox -s docs +``` + +This will install the necessary dependencies and build the documentation located in the `docs/` folder. +They will be placed in a `docs/_build/html` folder. +If the docs have already been built, it will only build new pages that have been updated. +You can open one of the HTML files there to preview the documentation locally. + +Alternatively, you can invoke the built-in Python [http.server](https://docs.python.org/3/library/http.server.html#module-http.server) with: + +```console +$ python -m http.server -d docs/_build/html/ +``` + +This will print a local URL that you can open in a browser to explore the HTML files. + +### Change content and re-build + +Now that you've built the documentation, edit one of the source files to see how the documentation updates with new builds. + +1. **Make an edit to a page**. For example, add a word or fix a typo on any page. +2. **Rebuild the documentation** with `nox -s docs` + +It should go much faster this time, because `nox` is re-using the old environment, and because Sphinx has cached the pages that you didn't change. + +## Compile the CSS/JS assets + +The source files for CSS and JS assets are in `src/pydata_sphinx_theme/assets`. +These are then built and bundled with the theme (e.g., `scss` is turned into `css`). + +To compile the CSS/JS assets with `nox`, run the following command: + +```console +$ nox -s compile +``` + +This will compile all assets and place them in the appropriate folder to be used with documentation builds. + +```{note} +Compiled assets are **not committed to git**. +The `sphinx-theme-builder` will bundle these assets automatically when we make a new release, but we do not manually commit these compiled assets to git history. +``` + +## Run a development server + +You can combine the above two actions and run a development server so that changes to `src/` are automatically bundled with the package, and the documentation is immediately reloaded in a live preview window. + +To run the development server with `nox`, run the following command: + +```console +$ nox -s docs-live +``` + +When working on the theme, saving changes to any of these directories: + +- `src/js/index.js` +- `src/scss/index.scss` +- `docs/**/*.rst` +- `docs/**/*.py` + +will cause the development server to do the following: + +- bundle/copy the CSS, JS, and vendored fonts +- regenerate the Jinja2 macros +- re-run Sphinx + +## Run the tests + +This theme uses `pytest` for its testing, with a lightweight fixture defined +in the `test_build.py` script that makes it easy to run a Sphinx build using +this theme and inspect the results. + +In addition, we use [pytest-regressions](https://pytest-regressions.readthedocs.io/en/latest/) +to ensure that the HTML generated by the theme is what we'd expect. This module +provides a `file_regression` fixture that will check the contents of an object +against a reference file on disk. If the structure of the two differs, then the +test will fail. If we _expect_ the structure to differ, then delete the file on +disk and run the test. A new file will be created, and subsequent tests will pass. + +To run the tests with `nox`, run the following command: + +```console +$ nox -s test +``` diff --git a/docs/contribute/topics.md b/docs/contribute/topics.md new file mode 100644 index 000000000..8909f3d2b --- /dev/null +++ b/docs/contribute/topics.md @@ -0,0 +1,225 @@ +# Topic guides and how-tos + +These sections cover common operations and topics that are relevant to developing this theme. + +## Make a release + +This theme uses GitHub tags and releases to automatically push new releases to +PyPI. For information on this process, see [the release checklist](https://github.com/pydata/pydata-sphinx-theme/wiki/Release-checklist#release-instructions). + +## Update JavaScript dependencies and their versions + +The javascript dependencies for this package are defined in `package.json`, and broken down into a few categories like `dependencies` and `devDependencies`. + +To update or add JS dependency, modify (or append to) the list of packages that are listed in each of these sections. +The next time you build the documentation (either with `nox` or with `stb`), these new dependencies will be installed and bundled with the theme. + +## Using `nox` + +Here are a few extra tips for using `nox`. + +:::{seealso} +The [`nox` command line documentation](https://nox.thea.codes/en/stable/usage.html) has a lot of helpful tips for extra functionality you can enable with the CLI. +::: + +### Re-install dependencies + +To re-execute the installation commands, use this pattern: + +```console +$ nox -s docs -- reinstall +``` + +Or to completely remove the environment generated by `nox` and start from scratch: + +```console +$ rm -rf .nox/docs +``` + +### Use `nox` with your global environment + +If you'd like to use `nox` with your **global** environment (the one from which you are calling `nox`), you can do so with: + +```console +$ nox --force-venv-backend none + +# alternatively: +$ nox --no-venv +``` + +Using `none` will re-use your current global environment. +See +[the nox documentation](https://nox.thea.codes/en/stable/usage.html#forcing-the-sessions-backend) for more details. + +## Using `pre-commit` + +Here are a few tips for using `pre-commit`: + +### Skip the pre-commit checks + +Run the following command: + +```console +$ git commit --no-verify +``` + +### Run pre-commit on all files + +By default, `pre-commit` will run its checks on files that have been modified in a commit. +To instead run it on all files, use this command: + +```console +$ pre-commit run --all-files + +# Alternatively +$ pre-commit run -a +``` + +## Web asset compiling and bundling + +All of the CSS and JS assets stored in `src/pydata_sphinx_theme/assets` will be compiled and bundled with the theme when you build it locally. +These bundled assets will be placed in `src/pydata_sphinx_theme/theme/pydata_sphinx_theme/static`. + +The configuration that defines what happens upon compilation is at `webpack.config.js`. + +When assets are compiled, a `` is generated for each, and appended to the end of the asset's reference in the HTML templates of the theme. +This ensures the correct asset versions are served when viewers return to your +site after upgrading the theme. + +Web fonts, and their supporting CSS, are copied into +`src/pydata_sphinx_theme/theme/pydata_sphinx_theme/static/vendor///`. + +The links to these unique file names are captured as Jinja2 macros that are defined in HTML templates bundled with the theme. + +## Accessibility checks + +The accessibility checking tools can find a number of common HTML patterns which +assistive technology can't help users understand. + +In addition to [Lighthouse](https://developers.google.com/web/tools/lighthouse) +in CI, the `pa11y` stack is installed as part of the development environment. + +The key components are: + +- [pa11y](https://github.com/pa11y/pa11y) which uses a headless browser to analyze + an HTML page with a configurable set of rules based on publish standards +- [Pa11y-CI](https://github.com/pa11y/pa11y-ci) runs `pa11y` on multiple pages +- [pa11y-reporter-html](https://github.com/pa11y/pa11y-reporter-html) generates + some nice HTML reports, suitable for review + +:::{note} +Presently, the _default_ `pa11y` ruleset, `WCAG2AA` is used, a subset of +the [Web Content Accessibility Guidelines](https://www.w3.org/TR/WCAG21). +The [Quick Reference](https://www.w3.org/WAI/WCAG21/quickref) may provide +lighter reading. +::: + +### Errors in CI/CD and what to do + +We have a list of **known accessibility problems** in the file `docs/scripts/a11y-roadmap.txt`. +This contains a list of errors that we aim to fix in the future, and that **do not cause tests to fail**. + +When a pa11y accessibility audit is run in our CI/CD, it checks for any errors that are _not_ on this list, and if it finds them it will cause the job to error. + +When you see an error in your CI/CD job, look at the logs under the `Run accessibility audit` job. +You should see an output that looks like this: + +``` +JSON: /tmp/pa11y/pa11y-864/pa11y-ci-results.json +Roadmap: /home/runner/work/pydata-sphinx-theme/pydata-sphinx-theme/docs/a11y-roadmap.txt +not on roadmap: + WCAG2AA.Principle2.Guideline2_4.2_4_1.G1,G123,G124.NoSuchID: 4 +on roadmap: + WCAG2AA.Principle1.Guideline1_3.1_3_1.H39.3.LayoutTable: 1 + WCAG2AA.Principle1.Guideline1_3.1_3_1.H43,H63: 1 + WCAG2AA.Principle1.Guideline1_3.1_3_1.H43.HeadersRequired: 1 + WCAG2AA.Principle1.Guideline1_4.1_4_3.G18.Fail: 1828 + WCAG2AA.Principle3.Guideline3_2.3_2_2.H32.2: 48 + WCAG2AA.Principle4.Guideline4_1.4_1_2.H91.A.EmptyNoId: 9 +passed: false +total errors: 1892 +``` + +The problems that caused an error are in the `not on roadmap` section. +Anything that is "not on the roadmap" is an error we have unexpectedly introduced in the PR. +These should be identified and fixed. + +### Fix accessibility errors + +We keep a list of **known accessibility issues** in the {download}`accessibility roadmap <../scripts/a11y-roadmap.txt>`. +These are issues which are currently flagged by the toolset, but that have not yet +been fixed. + +To start working on one of the accessibility roadmap items, comment out one of the +lines in `docs/a11y-roadmap.txt`, and re-run the audit to establish a baseline. + +Then, fix the issue in either the HTML templates, CSS, or python code, and re-run +the audit until it is fixed. + +### Run an accessibility audit locally + +To run the accessibility problem finder locally: + +```console +$ nox -s compile # Compile the theme assets +$ nox -s docs # Build the documentation +$ python docs/scripts/a11y.py # Run a helper script for an accessibility audit +``` + +The output of the last command includes: + +- a short summary of the current state of the accessibility rules we are trying to maintain +- local paths to JSON and HTML reports which contain all of the issues found + +## Change fonts + +Three "styles" of the [FontAwesome 5 Free](https://fontawesome.com/icons?m=free) +icon font are used for {ref}`icon links ` and admonitions, and is +the only `vendored` font. Further font choices are described in the {ref}`customizing` +section of the user guide, and require some knowledge of HTML and CSS. + +The remaining vendored font selection is: + +- managed as a dependency in `package.json` + + - allowing the version to be managed centrally + +- copied directly into the site statics, including licenses + + - allowing the chosen font to be replaced (or removed entirely) with minimal + templating changes: practically, changing the icon font is difficult at this + point. + +- partially preloaded + + - reducing flicker and re-layout artifacts of early icon renders + +- mostly managed in `webpack.js` + + - allowing upgrades to be handled in a relatively sane, manageable way, to + ensure the most recent icons + +### Upgrade a font + +If _only_ the version of the `existing` font must change, for example to enable +new icons, edit the appropriate font version in `package.json`. +Then re-compile the theme with: + +```console +$ nox -s compile +``` + +### Change a font + +If the above doesn't work, for example if file names for an existing font change, +or a new font variant altogether is being added, hand-editing of `webpack.config.js` +is required. The steps are roughly: + +- install the new font, as above +- in `webpack.config.js`: + - add the new font to `vendorVersions` and `vendorPaths` + - add new `link` tags to the appropriate macro in `macroTemplate` + - add the new font files (including the license) to `CopyPlugin` + - remove references to the font being replaced/removed, if applicable + - see the `font-awesome` sections of this configuration to see what the end-result configuration looks like. +- re-compile the theme's assets: `nox -s compile` diff --git a/docs/contributing.rst b/docs/contributing.rst deleted file mode 100644 index 6d6fc992c..000000000 --- a/docs/contributing.rst +++ /dev/null @@ -1,452 +0,0 @@ -************ -Contributing -************ - -The documentation for this theme (what you are looking at now) also serves -as a demo site for the theme. -These sections describe how to get set up with a development environment, and begin contributing. - -.. _basic-environment: - -Set up a basic development environment -====================================== - -We automate many development tasks with these two tools: - -- `nox `_, for automating common development tasks -- `pre-commit `_ for automatically enforcing code standards - -At a minimum, set up your local environment with these two tools by running the following command: - -.. code-block:: console - - $ pip install .[dev] - -Then, activate ``pre-commit`` locally with the following command: - -.. code-block:: console - - $ pre-commit install - -Most sections below use ``nox`` to automate tasks and environments. -This allows you to run jobs in a contained environment so that you know what tools are installed. -There's also a section below that describes how to manually set up your environment. - - -Build the documentation -======================= - -Building the documentation will use ``sphinx`` to generate the latest documentation in ``docs/`` and place them in a ``docs/_build/html`` folder. -If the docs have already been built, it will only build new pages that have been updated. - -To build the documentation with ``nox``, first follow :ref:`basic-environment`, -then run the following command: - -.. code-block:: console - - $ nox -s docs - -This will re-use pre-existing environments if possible. To re-execute the installation commands, use this pattern: - -.. code-block:: console - - $ nox -s docs -- reinstall - -Or to completely remove the environment generated by ``nox`` and start from scratch: - -.. code-block:: console - - $ rm -rf .nox/docs - -.. admonition:: Use nox with your global environment - :class: tip - - If you'd like to use ``nox`` with your **global** environment (the one from - which you are calling ``nox``), you can do so with - - .. code-block:: console - - $ nox --force-venv-backend none - - # alternatively: - $ nox -fb none - - Using `none` will re-use your current global environment. See - `the nox documentation `_ - for more details. - -If you've :ref:`manually set up your environment `, you can build them with: - -.. code-block:: console - - $ cd docs - $ make html - -.. Note:: - - If you wish to customize the CSS or JS beyond what is available in the - :ref:`configuration` and :ref:`customizing` sections of the user guide, - extra steps are required. The next section covers the full workflow, from - changing the source files, to seeing the updated site. - -Build the CSS/JS assets -======================= - -The source files for CSS and JS assets are in ``src/``. -These are then built and bundled with the theme (e.g., ``scss`` is turned into ``css``). -Building the CSS/JS assets requires a javascript development stack (``yarn``, ``webpack``, and anything in ``yarn.lock``). - -To build the CSS/JS assets with ``nox``, first follow :ref:`basic-environment`, -then run the following command: - -.. code-block:: console - - $ nox -s build - -If you've :ref:`manually set up your environment `, you can build them with: - -.. code-block:: console - - $ yarn build:production - - -Run a development server -======================== - -You can run a development server so that changes to make to ``src/`` are automatically bundled with the package, and the documentation is immediately reloaded in a live preview window. - -When working on the theme, saving changes to any of these directories: - -- ``src/js/index.js`` -- ``src/scss/index.scss`` -- ``docs/**/*.rst`` -- ``docs/**/*.py`` - -will cause the development server to do the followin: - -- bundle/copy the CSS, JS, and vendored fonts -- regenerate the Jinja2 macros -- re-run Sphinx - -To run the development server with ``nox``, first follow :ref:`basic-environment`, -then run the following command: - -.. code-block:: console - - $ nox -s docs-live - - -Run the tests -============= - -This theme uses ``pytest`` for its testing, with a lightweight fixture defined -in the ``test_build.py`` script that makes it easy to run a Sphinx build using -this theme and inspect the results. - -In addition, we use `pytest-regressions `_ -to ensure that the HTML generated by the theme is what we'd expect. This module -provides a ``file_regression`` fixture that will check the contents of an object -against a reference file on disk. If the structure of the two differs, then the -test will fail. If we *expect* the structure to differ, then delete the file on -disk and run the test. A new file will be created, and subsequent tests will pass. - -To run the tests with ``nox``, first follow :ref:`basic-environment`, -then run the following command: - -.. code-block:: console - - $ nox -s test - -If you've :ref:`manually set up your environment `, you can build them with: - -.. code-block:: console - - $ pytest - -.. _manual-environment: - -Manually set up a development environment -========================================= - -To set up your development environment, you'll need to set up both a Python and a Javascript environment. -As a convenience, this environment is described in the file at ``environment.yml``. -However, the sections below cover how to install it manually. - -Install python development dependencies ---------------------------------------- - -To install this theme locally, along with the dependencies needed to develop it, take the following steps: - -1. **Clone the repository locally**. Run this command: - - .. code-block:: console - - $ git clone https://github.com/pydata/pydata-sphinx-theme - $ cd pydata-sphinx-theme - -2. **Install the theme with dev dependencies**. Run this command: - - .. code-block:: console - - $ pip install -e .[dev] - -Install javascript development dependencies -------------------------------------------- - -The javascript development workflow relies primarily on `the yarn package managed `__. -This will be used to install a number of javascript dependencies defined originally in ``package.json``, and with specific versions pinned in ``yarn.lock``. -The easiest way to accomplish this is using `conda-forge `_, which these instructions cover below. - -1. **Install yarn**: - - .. code-block:: console - - $ conda install -c conda-forge yarn "nodejs>=14,<15" - - Re recommend using node 14 as it is the latest LTS release of ``nodejs``. - -2. **Initialize your yarn environment**: - - .. code-block:: console - - $ yarn --frozen-lockfile - - This will install all of the dependencies defined in ``yarn.lock`` and place them in a folder at ``node_modules/``. - - .. note:: - - If you do not include ``--frozen-lockfile``, then yarn will update all of the frozen dependency versions in ``yarn.lock``. - If you accidentally do this, revert the changes to ``yarn.lock`` and re-run the command with ``--frozen-lockfile``. - - -Update JS dependencies and their versions -========================================= - -The javascript dependencies for this package are defined in ``package.json``, and broken down into a few categories like ``dependencies`` and ``devDependencies``. -While ``package.json`` defines files versions loosely, explicit versions are "frozen" into a file called ``yarn.lock``. - -If you wish to update the versions of this theme's JS dependencies, follow these steps: - -1. Update packages in ``packages.json``. -2. Run the ``yarn`` command **without** ``--frozen-lockfile``. - - .. code-block:: console - - $ yarn - -3. Commit changes to ``yarn.lock`` and ``package.json``. It's important that both of these are changed together to ensure our builds are reproducible. - - -Location and structure of CSS/JS assets -======================================= - -The CSS and JS for this theme are built for the browser from ``src/*`` with -`webpack `__. The main entrypoints are: - -- CSS: ``src/scss/index.scss`` - - - the main part of the theme assets - - customizes `Bootstrap `__ with `Sass `__ - - points to the ``font-face`` of vendored web fonts, but does not include their - CSS ``@font-face`` declaration - -- JS: ``src/js/index.js`` - - - provides add-on Bootstrap features, as well as some custom navigation behavior - -- webpack: ``webpack.js`` - - - captures the techniques for transforming the JS and CSS source files in - ``src/`` into the production assets in ``pydata_sphinx_theme/static/`` - -These entrypoints, and all files they reference, are bundled into -``pydata_sphinx_theme/static/{css,js}/index..{css,js}``. - -The ```` ensures the correct asset versions are served when viewers return to your -site after upgrading the theme, and is reproducibly derived from ``src/**/*``, -``webpack.js``, and the ``dependencies`` and ``devDependencies`` -in ``package.json``/``yarn.lock``. - -Web fonts, and their supporting CSS, are copied into -``pydata_sphinx_theme/static/vendor///``. Including -the ```` also ensures the correct assets are served when upgrading. - -The links to these unique file names are captured as Jinja2 macros in -``pydata_sphinx_theme/static/webpack-macros.html``. - -Finally, all of these files are committed to the repo, in-place, along with the -rest of the code. This allows use of the theme directly from a ``git`` checkout, -without any of the finicky web development dependencies, or even a ``nodejs`` -runtime. - -.. Hint:: - - Theme development was inspired by the - `ReadTheDocs Sphinx theme `__. - -Change fonts -============ - -Three "styles" of the `FontAwesome 5 Free `__ -icon font are used for :ref:`icon links ` and admonitions, and is -the only `vendored` font. Further font choices are described in the :ref:`customizing` -section of the user guide, and require some knowledge of HTML and CSS. - -The remaining vendored font selection is: - -- managed as a dependency in ``package.json`` - - - allowing the version to be managed centrally - -- copied directly into the site statics, including licenses - - - allowing the chosen font to be replaced (or removed entirely) with minimal - templating changes: practically, changing the icon font is difficult at this - point. - -- partially preloaded - - - reducing flicker and re-layout artifacts of early icon renders - -- mostly managed in ``webpack.js`` - - - allowing upgrades to be handled in a relatively sane, manageable way, to - ensure the most recent icons - - -Upgrade a font --------------- - -If *only* the version of the `existing` font must change, for example to enable -new icons, run: - -.. code-block:: bash - - yarn add @ - yarn build:production - -It *may* also be necessary to clear out old font versions from -``pydata_sphinx_theme/static/vendor/`` before committing. - - -Change a font -------------- - -If the above doesn't work, for example if file names for an existing font change, -or a new font variant altogether is being added, hand-editing of ``webpack.js`` -is required. The steps are roughly: - -- install the new font, as above, with ``yarn add`` -- in ``webpack.js``: - - - add the new font to ``vendorVersions`` and ``vendorPaths`` - - add new ``link`` tags to the appropriate macro in ``macroTemplate`` - - add the new font files (including the license) to ``CopyPlugin`` - - remove references to the font being replaced/removed, if applicable - -- restart the development server, if running -- rebuild the production assets, as above, with ``yarn build:production`` -- potentially remove the font being replaced from ``package.json`` and re-run ``yarn`` -- commit all of the changed files - - -Workflow for contributing changes -================================= - -We follow a `typical GitHub workflow `__ -of: - -- create a personal fork of this repo -- create a branch -- open a pull request -- fix findings of various linters and checks -- work through code review - -For each pull request, the demo site is built and deployed to make it easier to review -the changes in the PR. To access this, click on the "ReadTheDocs" preview in the CI/CD jobs. - - -Automate code standards with pre-commit -======================================= - -To ensure all source files have been correctly built, a `pre-commit `__ hook is available. - -Pre-commit should be installed automatically by following the instructions in :ref:`basic-environment`. - -After running ``pre-commit install``, the pre-commit checks will be run every time you make a commit to the repository. - -- **To skip the pre-commit checks**, run the following command: - - .. code-block:: bash - - git commit --no-verify - -- **To run pre-commit on all files**, run the following command: - - .. code-block:: bash - - pre-commit run --all-files - -Accessibility checks -==================== - -The accessibility checking tools can find a number of common HTML patterns which -assistive technology can't help users understand. - -In addition to `Lighthouse `__ -in CI, the ``pa11y`` stack is installed as part of the development environment. - -The key components are: - -- `pa11y `__ which uses a headless browser to analyze - an HTML page with a configurable set of rules based on publish standards -- `Pa11y-CI `__ runs ``pa11y`` on multiple pages -- `pa11y-reporter-html `__ generates - some nice HTML reports, suitable for review - -.. Note:: - - Presently, the *default* ``pa11y`` ruleset, ``WCAG2AA`` is used, a subset of - the `Web Content Accessibility Guidelines `__. - The `Quick Reference `__ may provide - lighter reading. - -To run the accessibility problem finder locally: - -.. code-block:: bash - - yarn build:production - cd docs - make html - python a11y.py - -The output of the last command includes: - -- a short summary of the current state of the accessibility rules we are trying to maintain -- local paths to JSON and HTML reports which contain all of the issues found - - -Fixing accessibility errors ---------------------------- - -Start by checking for issues on the -`accessibility roadmap `__. -These are issues which are currently flagged by the toolset, but that have not yet -been fixed. If that file is empty (or just comments), hooray! - -To start working on one of the accessibility roadmap items, comment out one of the -lines in `docs/a11y-roadmap.txt`, and re-run the audit to establish a baseline. - -Then, fix the issue in either the HTML templates, CSS, or python code, and re-run -the audit until it is fixed. - - -Make a release -============== - -This theme uses GitHub tags and releases to automatically push new releases to -PyPI. For information on this process, see `the release checklist `_. - -.. meta:: - :description lang=en: - How to become a contributor to the pydata-sphinx-theme. diff --git a/docs/index.rst b/docs/index.rst index 16fe0b6c1..fd4862fc9 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -23,14 +23,13 @@ Other sites that are using this theme: :maxdepth: 2 user_guide/index - contributing + contribute/index .. toctree:: :maxdepth: 2 :hidden: demo/index - changelog .. meta:: diff --git a/docs/a11y-roadmap.txt b/docs/scripts/a11y-roadmap.txt similarity index 100% rename from docs/a11y-roadmap.txt rename to docs/scripts/a11y-roadmap.txt diff --git a/docs/a11y.py b/docs/scripts/a11y.py similarity index 100% rename from docs/a11y.py rename to docs/scripts/a11y.py diff --git a/noxfile.py b/noxfile.py index 0b6beed86..0a1d9d6c7 100644 --- a/noxfile.py +++ b/noxfile.py @@ -1,22 +1,57 @@ import nox +from pathlib import Path nox.options.reuse_existing_virtualenvs = True +def _should_install(session): + """Decide if we should install an environment or if it already exists. + + This speeds up the local install considerably because building the wheel + for this package takes some time. + + We assume that if `sphinx-build` is in the bin/ path, the environment is + installed. + """ + if session.bin_paths is None: + session.log("Running with `--no-venv` so don't install anything...") + return False + bin_files = list(Path(session.bin).glob("*")) + sphinx_is_installed = any("sphinx-build" in ii.name for ii in bin_files) + force_reinstall = "reinstall" in session.posargs + should_install = not sphinx_is_installed or force_reinstall + if should_install: + session.log("Installing fresh environment...") + else: + session.log("Skipping environment install...") + return should_install + + +@nox.session +def compile(session): + if _should_install(session): + session.install(".") + session.install("sphinx-theme-builder[cli]") + session.run("stb", "compile") + + @nox.session def docs(session): - session.install(".[doc]") + if _should_install(session): + session.install(".[doc]") session.run("sphinx-build", "-b=html", "docs/", "docs/_build/html") @nox.session(name="docs-live") def docs_live(session): - session.install(".[doc]") - session.install("sphinx-theme-builder[cli]") + if _should_install(session): + session.install(".[doc]") + session.install("sphinx-theme-builder[cli]") session.run("stb", "serve", "docs", "--open-browser") @nox.session(name="test") def test(session): - session.install("-e", ".[test]") + if _should_install(session): + session.install("-e", ".[test]") session.run("pytest", *session.posargs) diff --git a/pyproject.toml b/pyproject.toml index 1c3ab0416..fce0c0c3f 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -39,13 +39,12 @@ classifiers = [ [project.optional-dependencies] doc = [ - "sphinx", "numpydoc", "myst-parser", "pandas", "pytest", "pytest-regressions", - "beautifulsoup4", + "sphinxext-rediraffe", "sphinx-sitemap", # For demo examples "jupyter_sphinx",