DEP: Remove tox

Author: cortadocodes

README.md

@@ -93,12 +93,6 @@ Then, from the repository root, run
 python3 -m unittest
 ```
 
-or
-
-```shell
-tox
-```
-
 ## Contributing
 
 Take a look at our [contributing](/docs/contributing.md) page.

docs/contributing.md

@@ -1,21 +1,23 @@
 # Contributing
 
 ## Developing the SDK
+
 - We follow a test-driven development (TDD) approach and require a high test coverage of each PR.
 - We use [`pre-commit`](https://pre-commit.com/) to apply consistent code quality checks and linting to new code, commit messages, and documentation - see [below](#pre-commit) for how to set this up
 - Documentation is automatically built by `pre-commit` but needs to be updated with any changes to public interface of the package
 
-
 ## Releases
+
 We use continuous deployment and semantic versioning for our releases:
+
 - Continuous deployment - each pull request into `main` constitutes a new version
 - [Semantic versioning](https://semver.org/) supported by [Conventional Commits](https://github.com/octue/conventional-commits) - to automate meaningful version numbering
 - Conventional Commit messages - these are essential for the above to be automated. We've developed a `pre-commit` check that guides and enforces this.
 
-
 ## Pull requests
 
 ### Internal developers
+
 1. Check out a new branch
 2. Create a pull request into the `main` branch
 3. Undertake your changes, committing and pushing to your branch
@@ -27,11 +29,13 @@ We use continuous deployment and semantic versioning for our releases:
 9. Merge into `main`. A release will automatically be created on GitHub and published to PyPi and Docker Hub.
 
 ### External developers
+
 - Please [raise an issue](https://github.com/octue/octue-sdk-python/issues) (or add your $0.02 to an existing issue) so
   the maintainers know what's happening and can advise/steer you.
 
 - Create a fork of `octue-sdk-python`, undertaking your changes on a new branch, (see `.pre-commit-config.yaml` for
   branch naming conventions). To run tests and make commits, you'll need to do something like:
+
   ```
   git clone <your_forked_repo_address>                          # Fetches the repo to your local machine
   cd octue-sdk-python                                           # Move into the repo directory
@@ -40,17 +44,18 @@ We use continuous deployment and semantic versioning for our releases:
   pip install poetry                                            # Installs the poetry package manager
   poetry install --all-extras                                   # Installs the package editably, including developer dependencies (e.g. testing and code formatting utilities)
   pre-commit install && pre-commit install -t commit-msg        # Installs the pre-commit hooks in the git repo
-  tox                                                           # Runs the tests
+  poetry run python3 -m unittest                                # Runs the tests
   ```
 
 - Open a pull request into the `main` branch of `octue/octue-sdk-python`.
 - Follow the rest of the process for internal developers above.
 - Once checks have passed, test coverage of the new code is 100%, documentation is updated, and the review has passed,
   we'll merge and release your changes.
 
-
 ## Pre-Commit
+
 You need to install pre-commit to get the hooks working. Run:
+
 ```
 pip install pre-commit
 pre-commit install && pre-commit install -t commit-msg
@@ -74,16 +79,18 @@ Upon failure, the commit will halt. **Re-running the commit will automatically f
 - Commit messages - the error messages should explain how to fix these too
 
 You can run pre-commit hooks without making a commit, too, like:
+
 ```
 pre-commit run black --all-files
 ```
+
 or
+
 ```
 # -v gives verbose output, useful for figuring out why docs won't build
 pre-commit run build-docs -v
 ```
 
-
 ## Documentation
 
 ### Building documents automatically
@@ -93,19 +100,20 @@ The documentation will build automatically in a pre-configured environment when
 In fact, the way `pre-commit` works, you won't be allowed to make the commit unless the documentation builds. This way
 we avoid getting broken documentation pushed to the main repository on any commit so we can rely on builds working.
 
-
 ### Building documents manually
 
 **If you did need to build the documentation**
 
 Install `doxygen`. On a mac, that's `brew install doxygen`; other systems may differ.
 
 Install sphinx and other requirements for building the docs:
+
 ```
 pip install -r docs/requirements.txt
 ```
 
 Run the build process:
+
 ```
 sphinx-build -b html docs/source docs/html
 ```

poetry.lock

@@ -48,7 +48,6 @@ octue = "octue.cli:octue_cli"
 # Testing
 gcp-storage-emulator = "2022.06.11"
 pytest = "^7"
-tox = "^3.23"
 # Code quality
 pre-commit = "^2.17"
 coverage = "^5"