sphinx-roles 0.0.1__tar.gz

sphinx_roles-0.0.1/.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,5 @@
+- [ ] Have you followed the guidelines for contributing?
+- [ ] Have you signed the [CLA](http://www.ubuntu.com/legal/contributors/)?
+- [ ] Have you successfully run `make lint && make test`?
+
+---

sphinx_roles-0.0.1/.github/release-drafter.yml

@@ -0,0 +1,24 @@
+categories:
+  - title: "New Features"
+    labels:
+      - "enhancement"
+  - title: "Maintenance"
+    labels:
+      - "maintenance"
+  - title: "Bug Fixes"
+    labels:
+      - "bug"
+  - title: "Specifications and Documentation"
+    label:
+      - "specification"
+      - "doc"
+  - title: "Tooling"
+    label:
+      - "tooling"
+change-template: "- $TITLE @$AUTHOR (#$NUMBER)"
+template: |
+  Special thanks to the contributors that made this release happen: $CONTRIBUTORS
+
+  ## Full list of changes
+
+  $CHANGES

sphinx_roles-0.0.1/.github/workflows/policy.yaml

@@ -0,0 +1,15 @@
+name: Check policy
+on:
+  pull_request:
+  push:
+    branches:
+      - main
+      - hotfix/*
+      - work/check-policy # For development
+
+jobs:
+  policy:
+    uses: canonical/starflow/.github/workflows/policy.yaml@main
+  python-scans:
+    name: Security scan
+    uses: canonical/starflow/.github/workflows/scan-python.yaml@main

sphinx_roles-0.0.1/.github/workflows/qa.yaml

@@ -0,0 +1,16 @@
+name: QA
+on:
+  push:
+    branches:
+      - "main"
+      - "feature/*"
+      - "hotfix/*"
+      - "release/*"
+      - "renovate/*"
+  pull_request:
+
+jobs:
+  lint:
+    uses: canonical/starflow/.github/workflows/lint-python.yaml@main
+  test:
+    uses: canonical/starflow/.github/workflows/test-python.yaml@main

sphinx_roles-0.0.1/.github/workflows/release-drafter.yaml

@@ -0,0 +1,16 @@
+name: Release Drafter
+
+on:
+  push:
+    # branches to consider in the event; optional, defaults to all
+    branches:
+      - main
+
+jobs:
+  update_release_draft:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Release Drafter
+        uses: release-drafter/release-drafter@v6.1.0
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

sphinx_roles-0.0.1/.github/workflows/release-publish.yaml

@@ -0,0 +1,72 @@
+name: Release
+on:
+  push:
+    tags:
+      # These tags should be protected, remember to enable the rule:
+      # https://github.com/canonical/starbase/settings/tag_protection
+      - "[0-9]+.[0-9]+.[0-9]+"
+
+permissions:
+  contents: write
+
+jobs:
+  source-wheel:
+    runs-on: [self-hosted, jammy]
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Fetch tag annotations
+        run: |
+          # Note: we fetch the tags here instead of using actions/checkout's "fetch-tags"
+          # because of https://github.com/actions/checkout/issues/1467
+          git fetch --force --tags --depth 1
+          git describe --dirty --long --match '[0-9]*.[0-9]*.[0-9]*' --exclude '*[^0-9.]*'
+      - name: Setup Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: "3.10"
+          check-latest: true
+      - name: Build packages
+        run: |
+          pip install build twine
+          python3 -m build
+          twine check dist/*
+      - name: Upload pypi packages artifact
+        uses: actions/upload-artifact@v4
+        with:
+          name: pypi-packages
+          path: dist/
+  pypi:
+    needs: ["source-wheel"]
+    runs-on: [self-hosted, jammy, amd64]
+    permissions:
+      # IMPORTANT: this permission is mandatory for trusted publishing
+      id-token: write
+    steps:
+      - name: Get packages
+        uses: actions/download-artifact@v4
+        with:
+          name: pypi-packages
+          path: dist/
+      - name: Publish to pypi
+        # Note: this action uses PyPI's support for Trusted Publishers
+        # It needs a configuration on the PyPI project - see:
+        # https://docs.pypi.org/trusted-publishers/adding-a-publisher/#github-actions
+        uses: pypa/gh-action-pypi-publish@release/v1
+  github-release:
+    needs: ["source-wheel"]
+    runs-on: [self-hosted, jammy]
+    steps:
+      - name: Get pypi artifacts
+        uses: actions/download-artifact@v4
+        with:
+          name: pypi-packages
+      - name: Release
+        uses: softprops/action-gh-release@v2
+        with:
+          # Generate release notes on the new GH release
+          generate_release_notes: true
+          # Add wheel and source tarball
+          files: |
+            *.whl
+            *.tar.gz

sphinx_roles-0.0.1/.gitignore

@@ -0,0 +1,149 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+pip-wheel-metadata/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+*.snap
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+.results.*.xml
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+docs/spelling/
+
+# PyBuilder
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+.python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.direnv
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# Caches for various tools
+/.*_cache/
+
+# Test results
+/results/
+.test_output/
+
+# direnv
+.envrc
+
+# Ignore version module generated by setuptools_scm
+*/_version.py
+
+# Visual Studio Code
+.vscode/

sphinx_roles-0.0.1/.pre-commit-config.yaml

@@ -0,0 +1,28 @@
+# See https://pre-commit.com for more information
+# See https://pre-commit.com/hooks.html for more hooks
+repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: "v5.0.0"
+    hooks:
+      - id: trailing-whitespace
+      - id: end-of-file-fixer
+      - id: check-yaml
+      - id: check-added-large-files
+      - id: check-merge-conflict
+      - id: check-toml
+      - id: fix-byte-order-marker
+      - id: mixed-line-ending
+  - repo: https://github.com/astral-sh/ruff-pre-commit
+    rev: "v0.11.13"
+    hooks:
+      # Run the linter
+      - id: ruff
+        args: [--fix, --exit-non-zero-on-fix]
+      # Run the formatter
+      - id: ruff-format
+  - repo: https://github.com/pre-commit/mirrors-prettier
+    rev: "" # Intentionally blank, despite the warning.
+    hooks:
+      - id: prettier
+        additional_dependencies:
+          - prettier@3.4.2

sphinx_roles-0.0.1/CONTRIBUTING.md

@@ -0,0 +1,219 @@
+# Contributing
+
+All contributors should become familiar with this guide. It outlines the expectations
+and practices for participating in the project.
+
+## Review the project expectations
+
+Before you start working on the project, there are three documents for you to digest.
+
+### Ubuntu Code of Conduct
+
+Projects governed by Canonical expect good conduct and excellence from every member. The
+specific principles are laid out in the [Ubuntu Code of
+Conduct](https://ubuntu.com/community/ethos/code-of-conduct).
+
+### Canonical Contributor License Agreement
+
+As a contributor, you retain your copyright and attribution rights, provided you sign
+the [Canonical Contributor Licence Agreement](http://www.ubuntu.com/legal/contributors).
+Before committing any code, review its terms. If you agree and sign it, your code can be
+incorporated into the repository.
+
+### Open source license
+
+This project is licensed under [GPL-3.0](LICENSE).
+
+## Report an issue or open a request
+
+If you find a bug or feature gap in the project, look for it in the [project's GitHub
+issues](https://github.com/canonical/sphinx-roles/issues) first. If you have fresh
+input, add your voice to the issue.
+
+If the bug or feature doesn't have an issue, we invite you to [open
+one](https://github.com/canonical/sphinx-roles/issues/new/choose).
+
+## Set up for development
+
+This project uses a forking, feature-based workflow. Most work occurs on people's local
+systems and is heavily terminal-dependent. Remote testing and building is provided on
+GitHub for continuous integration and delivery.
+
+Start by [creating a personal fork](https://github.com/canonical/sphinx-roles/fork) of
+the repository on GitHub.
+
+Next, on your host system, clone your fork and sync it with the upstream repository:
+
+```bash
+git clone git@github.com:<username>/sphinx-roles --recurse-submodules
+cd sphinx-roles
+git remote add upstream git@github.com:canonical/sphinx-roles
+git fetch upstream
+```
+
+If you don't authenticate with SSH, clone with
+[HTTPS](https://docs.github.com/en/get-started/git-basics/about-remote-repositories#cloning-with-https-urls)
+instead:
+
+```bash
+git clone https://github.com/<username>/sphinx-roles --recurse-submodules
+cd sphinx-roles
+git remote add upstream https://github.com/canonical/sphinx-roles
+git fetch upstream
+```
+
+Inside the project directory, set up the virtual development environment and install all
+dependencies, linters, and testers:
+
+```bash
+make install
+make lint
+make test
+```
+
+If all linting and testing completes without errors, your local environment is ready.
+
+## Contribute a change
+
+With the prerequisites out of the way, let's walk through how to make a contribution to
+the project.
+
+### Research the topic
+
+All significant work should be tied to an existing issue or ticket.
+
+If you'd like to add a small feature or fix, check the project's GitHub issues to see if
+others have reported it. If they have, look into the current status of the topic. If no
+one else is working on it, add a comment stating that you'd like to take it on, and a
+maintainer will assign it to you.
+
+If you're ever in doubt about developments in the project, ask!
+
+### Create a development branch
+
+Once you've settled on a topic to work on, it's time to set up a local branch.
+
+Always start by syncing against the branch and the dependencies you're basing your
+changes on.
+
+```bash
+git checkout main
+git pull upstream main
+git checkout -b <new-branch-name>
+make install
+```
+
+The new branch name should be brief, at no more than 80 characters. Format your branch
+name as `<ticket-id>-<description>`. For example, if you're working on GitHub issue
+\#235, and it's about adding a string sanitizer, you'd name your branch
+`issue-235-add-string-sanitizer-method`.
+
+````
+
+### Commit a change
+
+Once you've made the changes to the code and you're ready to test it, start by
+committing:
+
+```bash
+git add -A
+git commit
+````
+
+Format the commit message according to the [Conventional
+Commits](https://www.conventionalcommits.org/en/v1.0.0/) style. For the sanitizer
+example, an appropriate commit title would be:
+
+```
+feat: add text sanitizer
+```
+
+If you need help determining the type of conventional commit for your change, look at
+the history of the file in question with `git log --oneline <filename>` . When you're
+done browsing, press `Q` to exit the interactive log.
+
+> **Tip**
+>
+> With complex changes, you might get stuck choosing a conventional commit type.
+>
+> This may signal that a commit is doing more than one thing and should be broken into
+> multiple smaller commits. A commit should not, for example, refactor code and fix a
+> bug. That should be two separate commits.
+>
+> In other scenarios, multiple types could be appropriate because of the nature of the
+> commit. This can happen with `test` and `docs`, which can be used as either types
+> or scopes.
+>
+> Run down the following list and select the highest-ranked type that fits your change:
+>
+> - ci
+> - build
+> - feat
+> - fix
+> - perf
+> - refactor
+> - style
+> - test
+> - docs
+> - chore
+
+Committing triggers the [pre-commit](https://pre-commit.com/) hook, which runs the
+automatic code formatter and the fast linters.
+
+If the linters reformatted any of the files, the commit was cancelled. To make the
+changes stick, restage the modified files with `git add -A` and commit again.
+
+### Test the change
+
+All nontrivial code changes should be accompanied by a reasonable set of tests.
+
+The sphinx-roles test suite includes both unit and integration tests. If you're not
+sure which tests you should add, go with your best judgement – additional tests can be
+added during the review process.
+
+Once you've made your changes, run the test suite:
+
+```bash
+make test
+```
+
+When iterating and testing, it's a good practice to clean the local temporary files that
+the tests generate:
+
+```bash
+make clean
+```
+
+In rare instances, tests can fail in unpredictable ways, regardless of the state of your
+code. In such cases, it's best to delete your virtual environment and start over:
+
+```bash
+rm -rf .venv
+make clean
+make install
+```
+
+### Push the branch and open a PR
+
+Once your work is committed to your branch, push it to your fork:
+
+```bash
+git push -u origin <branch-name>
+```
+
+Finally, [open a PR](https://github.com/canonical/sphinx-roles/compare) for it on
+GitHub. If your branch has one commit, GitHub will title the PR after it. If your branch
+has more than one commit, name the PR after the most significant. Once open, reviewers
+are assigned automatically to your work.
+
+### Follow up for the review
+
+When a maintainer reviews your PR, they typically leave inline comments and suggestions
+on the code.
+
+If the comment is a request, accommodate it by pushing one or more additional commits to
+the branch. It's simplest to add the commits locally and push, rather than in the GitHub
+interface, as it leads to fewer potential conflicts with syncs.
+
+Don't force-push changes to the branch. It destroys the history of the review and makes
+it harder for maintainers to see code changes.