Developer Guide
Each library is built as a standalone library, allowing you use them individually. The sub libraries must use pywrapid libraries where wrappers already exist and should be compatible with pywrapid config.
Functions deemed useful for other users of pywrapid should go to utils.
Keep in mind: - Do not mix other fixes or features into your feature branch, keep it canonical - Rebase if you fall behind - Make sure you tests cover your changes and tox reports all green before you send a pull request - Force push is not allowed, by anyone
To build a wheel:
pip install tox
tox
or
pip install build
python -m build
Linting and tests
Tests should be created for all new functionality
Feature branch must pass linting and tests before pull request is made
Builds will run tox, and so should you
Linters used:
pylint
flake8
mypy
black
isort
bandit
Test suite:
pytest
CI/CD Pipeline
The project uses a streamlined CI/CD pipeline based on GitHub Actions to ensure code quality and simplify the release process.
Validation Workflow
We use a centralized validation workflow that intelligently orchestrates various checks:
Linting: Code style and quality checks
Testing: Unit and integration tests
Documentation: Validates documentation builds correctly
Security: Vulnerability scanning
The key workflow files are:
validate-changes.yml: Orchestrates which checks to run based on changed filestest.yml,lint.yml,docs.yml,security.yml: Specialized workflows
The validation workflow runs automatically on:
Pull requests
Direct pushes to main branches
You can also manually trigger validation checks through GitHub Actions.
Release and Publishing Process
Pywrapid uses GitHub-integrated release process that leverages GitHub Actions along with automatic release notes generation.
Version Management
The project uses setuptools_scm for version management, which means:
Version numbers are automatically derived from Git tags
No manual version number updates needed in code
Git tags determine the package version
Creating a New Release
To create a new release:
Go to the GitHub repository page
Click on “Releases” in the right sidebar
Click “Draft a new release”
Create a new tag following semantic versioning (e.g.,
v1.2.3)Add a release title (optional)
GitHub will auto-generate release notes based on merged PRs
Click “Publish release”
The publish workflow will automatically:
Run all validation checks
Build the package
Publish the package to PyPI
Attach build artifacts to the GitHub release
Automatic Release Notes
Release notes are automatically generated based on merged pull requests since the last release. To ensure your changes are properly categorized:
Add labels to your PRs:
featureorenhancement: For new featuresbugorfix: For bug fixesdocs: For documentation changesmaintenanceorrefactor: For code maintenancedependenciesordeps: For dependency updates
Use descriptive PR titles: These become part of the release notes
Testing the Release Process
You can test different parts of the release process without actually publishing:
Go to the GitHub Actions tab
Select the “Publish” workflow
Click “Run workflow”
Select one of the following options:
validate-only: Just runs the validation checksbuild-only: Builds the package without publishingdraft-release-notes: Generates a draft release with notes
Project structure
pywrapid and its sub libraries use the following folder structure:
pywrapid
├───src
│ ├───pywrapid
│ │ ├───sublibrary1
│ │ │ ├───exceptions.py
│ │ │ ├───library_code_1.py
│ │ │ ├───library_code_n.py
│ │ │ └───requirements.txt
│ │ ├───sublibrary2
│ │ │ ├───exceptions.py
│ │ │ ├───library_code_1.py
│ │ │ ├───library_code_n.py
│ │ │ └───requirements.txt
│ │ ├───sublibraryN
│ │ │ ├───exceptions.py
│ │ │ ├───library_code_1.py
│ │ │ ├───library_code_n.py
│ │ │ └───requirements.txt
├───docs
│ ├───src
│ │ ├───documentation-file1.rst
│ │ ├───documentation-fileN.rst
│ │ └───conf.py
├───tests
│ ├───test_pywrapid_modulename_filename1.py
│ ├───test_pywrapid_modulename_filenameN.py
│ ├───test_integration_testgroup1.py
│ ├───test_integration_testgroupN.py
│ ├───test_user_testgroup1.py
│ └───test_user_testgroupN.py
├───tox.ini
├───requirements.txt
└───pyproject.toml