Project scaffold overhaul

.github/workflows/release.yml

@@ -1,34 +1,19 @@
-# This workflow runs the publication to pypi
 name: release
 on:
   release:
     types: [published]
   workflow_dispatch: {}
 jobs:
-  build-38:
+  publish:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v5
-      - name: Run release
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - uses: astral-sh/setup-uv@v5
+      - name: Build sdist and wheel
+        run: uv build
+      - name: Publish to PyPI
+        run: uv publish
         env:
-          PYPI_TOKEN: ${{ secrets.PYPI_TOKEN }}
-          PYTHON_VERSION: "3.8"
-        run: REF="${{ github.ref }}" ./scripts/release.sh
-  build-39:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v5
-      - name: Run release
-        env:
-          PYPI_TOKEN: ${{ secrets.PYPI_TOKEN }}
-          PYTHON_VERSION: "3.9"
-        run: REF="${{ github.ref }}" ./scripts/release.sh
-  build-310:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v5
-      - name: Run release
-        env:
-          PYPI_TOKEN: ${{ secrets.PYPI_TOKEN }}
-          PYTHON_VERSION: "3.10"
-        run: REF="${{ github.ref }}" ./scripts/release.sh
+          UV_PUBLISH_TOKEN: ${{ secrets.PYPI_TOKEN }}

.github/workflows/tests.yml

@@ -1,4 +1,3 @@
-# This workflow runs the python unit tests
 name: tests
 on:
   push:
@@ -7,21 +6,16 @@ on:
     branches: [main]
   workflow_dispatch: {}
 jobs:
-  build-310:
+  test:
     runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        python-version: ["3.10", "3.11", "3.12", "3.13", "3.14"]
     steps:
-      - uses: actions/checkout@v5
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - uses: astral-sh/setup-uv@v5
       - name: Run unit tests
-        run: docker build . --target=test --build-arg PYTHON_VERSION=3.10
-  build-311:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v5
-      - name: Run unit tests
-        run: docker build . --target=test --build-arg PYTHON_VERSION=3.11
-  build-312:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v5
-      - name: Run unit tests
-        run: docker build . --target=test --build-arg PYTHON_VERSION=3.12
+        run: uv run --python ${{ matrix.python-version }} --extra test pytest

.gitignore

@@ -10,3 +10,6 @@ reports
 htmlcov
 .coverage
 .bash_history
+uv.lock
+*_pb2.py
+*_pb2_grpc.py

.pre-commit-config.yaml

@@ -1,16 +1,15 @@
 repos:
   - repo: https://github.com/pre-commit/mirrors-prettier
-    rev: v2.1.2
+    rev: v3.0.0
     hooks:
       - id: prettier
   - repo: https://github.com/psf/black
-    rev: 20.8b1
+    rev: 24.3.0
     hooks:
       - id: black
         exclude: imports
-        additional_dependencies: ["click==8.0.4"]
   - repo: https://github.com/PyCQA/isort
-    rev: 5.11.5
+    rev: 5.13.2
     hooks:
       - id: isort
         exclude: imports

CONTRIBUTING.md

@@ -48,22 +48,27 @@ Improvements to existing functionality are tracked as [GitHub issues using the U
 
 ### Set up your dev environment
 
-#### Using Docker
+#### Using uv
 
-The easiest way to get up and running is to use the dockerized development environment which you can launch using:
+The recommended way to get up and running is to use [`uv`](https://github.com/astral-sh/uv) for managing the Python environment:
 
 ```sh
-make develop
-```
+# Install dependencies including test tools
+uv sync --extra test
+
+# Run tests
+uv run pytest
 
-Within the `develop` shell, any of the `make` targets that do not require `docker` can be run directly. The shell has the local files mounted, so changes to the files on your host machine will be reflected when commands are run in the `develop` shell.
+# Run formatting
+uv run pre-commit run --all-files
+```
 
 #### Locally
 
 You can also develop locally using standard python development practices. You'll need to install the dependencies for the unit tests. It is recommended that you do this in a virtual environment such as [`conda`](https://docs.conda.io/en/latest/miniconda.html) or [`pyenv`](https://github.com/pyenv/pyenv) so that you avoid version conflicts in a shared global dependency set.
 
 ```sh
-pip install -r requirements_test.txt
+pip install -e ".[test]"
 ```
 
 ### Run unit tests
@@ -74,14 +79,19 @@ Running the tests is as simple as:
 make test
 ```
 
-If you want to use the full set of [`pytest` CLI arguments](https://docs.pytest.org/en/6.2.x/usage.html), you can run the `scripts/run_tests.sh` script directly with any arguments added to the command.
+If you want to use the full set of [`pytest` CLI arguments](https://docs.pytest.org/en/6.2.x/usage.html), you can run the `scripts/run_tests.sh` script directly with any arguments added to the command. For example, to run only a single test without capturing output, you can do:
+
+```sh
+./scripts/run_tests.sh tests/test_tls_test_tools.py
+```
 
 ### Code formatting
 
-This project uses [pre-commit](https://pre-commit.com/) to enforce coding style using [black](https://github.com/psf/black). To set up `pre-commit` locally, you can:
+This project uses [pre-commit](https://pre-commit.com/) to enforce coding style using [black](https://github.com/psf/black) and [isort](https://pycqa.github.io/isort/). To set up `pre-commit` locally, you can:
 
 ```sh
 pip install pre-commit
+pre-commit install
 ```
 
 Coding style is enforced by the CI tests, so if not installed locally, your PR will fail until formatting has been applied.
@@ -97,7 +107,7 @@ Unsure where to begin contributing? You can start by looking through these issue
 
 To contribute to this repo, you'll use the Fork and Pull model common in many open source repositories. For details on this process, watch [how to contribute](https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github).
 
-When ready, you can create a pull request. Pull requests are often referred to as "PR". In general, we follow the standard [github pull request](https://help.github.com/en/articles/about-pull-requests) process. Follow the template to provide details about your pull request to the maintainers.
+When ready, you can create a pull request. Pull requests are often referred to as "PR". In general, we follow the standard [github pull request](https://help.github.com/en/articles/about-pull-request) process. Follow the template to provide details about your pull request to the maintainers.
 
 Before sending pull requests, make sure your changes pass tests.
 
@@ -110,6 +120,13 @@ Once you've [created a pull request](#how-to-contribute), maintainers will revie
 - Write detailed commit messages
 - Break large changes into a logical series of smaller patches, which are easy to understand individually and combine to solve a broader issue
 
-<!-- ## Releasing (Maintainers only)
+## Releasing (Maintainers only)
+
+The responsibility for releasing new versions of the libraries falls to the maintainers. Releases will follow standard [semantic versioning](https://semver.org/) and be hosted on [pypi](https://pypi.org/project/tls-test-tools/).
+
+To create a release:
 
-The responsibility for releasing new versions of the libraries falls to the maintainers. Releases will follow standard [semantic versioning](https://semver.org/) and be hosted on [pypi](https://pypi.org/project/jtd-to-proto/). -->
+1. Tag the release: `git tag -a vX.Y.Z -m "Release vX.Y.Z"`
+2. Push the tag: `git push origin vX.Y.Z`
+3. Create a GitHub release for the tag
+4. The CI will automatically build and publish to PyPI

Makefile

@@ -9,28 +9,12 @@ help: ## Display this help.
 
 .PHONY: test
 test: ## Run the unit tests
-	./scripts/run_tests.sh
-
-.PHONY: test.develop
-test.develop:	develop.build ## Run the unit tests in the develop shell
-	./scripts/develop.sh ./scripts/run_tests.sh
+	uv run --extra test pytest
 
 .PHONY: fmt
 fmt: ## Run code formatting
 	./scripts/fmt.sh
 
-.PHONY: wheel
-wheel: ## Build release wheels
-	./scripts/build_wheel.sh
-
-##@ Develop
-
-PYTHON_VERSION ?= 3.8
-
-.PHONY: develop.build
-develop.build: ## Build the development environment container
-	docker build . --target=base -t tls-test-tools-develop --build-arg PYTHON_VERSION=${PYTHON_VERSION}
-
-.PHONY: develop
-develop:	develop.build ## Run the develop shell with the local codebase mounted
-	./scripts/develop.sh
+.PHONY: build
+build: ## Build sdist and wheel
+	uv build

README.md

@@ -1,6 +1,6 @@
 # TLS Test Tools
 
-This project is a collection of tools for managing ephemeral TLS secrets in unit tests.
+This project is a library of tools for managing ephemeral TLS secrets in unit tests.
 
 When writing code that needs to either host a server with TLS enabled or make connections to a TLS enabled server, it's
 often difficult to write succinct unit tests that exercise these connections. This package aims to fix that! It provides
@@ -9,8 +9,18 @@ ports to host temporary servers on.
 
 ## Installation
 
-To install, simply use `pip`
+To install, simply use `pip`:
 
 ```sh
 pip install tls-test-tools
 ```
+
+Or use `uv` for faster installation:
+
+```sh
+uv add tls-test-tools
+```
+
+## Development
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) for information on setting up a development environment and contributing to this project.