Thank you for your interest in contributing! This document provides guidelines and instructions for development.
git clone https://github.com/JoaoPedroBelo/bmw-wallbox-ha.git
cd bmw-wallbox-ha# Create virtual environment
python3 -m venv venv
source venv/bin/activate # On Windows: venv\Scripts\activate
# Install dependencies
pip install -r requirements-dev.txtpre-commit installThis will automatically run linters on every commit.
We provide a Makefile with common development tasks:
make help # Show all available commands
make install # Install development dependencies
make lint # Run all linters
make format # Auto-format code
make test # Run tests
make coverage # Run tests with coverage
make check # Run lint + tests
make clean # Remove generated filesIf you prefer running commands directly:
# Linting
ruff check custom_components/ tests/ # Check for issues
ruff check custom_components/ tests/ --fix # Fix issues automatically
ruff format custom_components/ tests/ --check # Check formatting
ruff format custom_components/ tests/ # Format code
mypy custom_components/bmw_wallbox # Type checking
# Testing
pytest tests/ -v # Run tests
pytest tests/ --cov=custom_components.bmw_wallbox # With coverage
# Pre-commit (run all hooks)
pre-commit run --all-filesThis project follows Home Assistant's code quality standards:
We use Ruff - a fast Python linter that replaces multiple tools:
- flake8 - Code quality checks
- isort - Import sorting
- pyupgrade - Python version upgrades
- black - Code formatting
Configuration is in pyproject.toml.
We use MyPy for static type checking:
- All functions should have type hints
- Configuration is in
pyproject.toml
- 100% test coverage goal - All new code should have tests
- Use
pytestfor testing - Use
pytest-asynciofor async tests - Mock external dependencies
- Follow PEP 8 - Python style guide
- Type hints required - All functions should have type annotations
- Docstrings required - All public functions should have docstrings
- Keep it simple - Prefer readability over cleverness
- Test everything - Write tests for new features
- Use Home Assistant patterns - Follow HA integration patterns
- Async/await - Use async functions for I/O operations
- Coordinators - Use DataUpdateCoordinator for data fetching
- Entity naming - Follow HA entity naming conventions
- Config flow - Use config flow for user configuration
Imports should be organized in this order (handled by Ruff):
# Standard library
import asyncio
from datetime import datetime
# Third-party
import websockets
from ocpp.v201 import ChargePoint
# Home Assistant
from homeassistant.core import HomeAssistant
from homeassistant.helpers.update_coordinator import DataUpdateCoordinator
# Local
from .const import DOMAIN"""Example module demonstrating coding standards."""
from __future__ import annotations
from typing import Any
from homeassistant.core import HomeAssistant
async def example_function(
hass: HomeAssistant,
param1: str,
param2: int | None = None,
) -> dict[str, Any]:
"""Do something useful.
Args:
hass: Home Assistant instance
param1: Description of parameter 1
param2: Optional parameter 2
Returns:
Dictionary with results
"""
result: dict[str, Any] = {
"param1": param1,
"param2": param2 or 0,
}
return result- Test file naming:
test_<module>.py - Test function naming:
test_<functionality> - Use fixtures: Define reusable fixtures in
conftest.py - Mock external calls: Don't make real network calls
- Test edge cases: Not just happy paths
"""Test example functionality."""
import pytest
from homeassistant.core import HomeAssistant
from custom_components.bmw_wallbox.sensor import BMWWallboxSensor
async def test_sensor_state(hass: HomeAssistant, mock_coordinator):
"""Test sensor returns correct state."""
sensor = BMWWallboxSensor(mock_coordinator, mock_entry)
assert sensor.native_value == "expected_value"
assert sensor.available is True- Run linters:
make lintorpre-commit run --all-files - Run tests:
make test - Check coverage:
make coverage - Update docs: Update relevant documentation
- Update CHANGELOG: Add entry to
CHANGELOG.md
- Clear title: Describe what the PR does
- Description: Explain why the change is needed
- Link issues: Reference related issues
- Small PRs: Keep changes focused and reviewable
- Tests included: Add tests for new features
- No merge conflicts: Rebase on latest main
## Summary
Brief description of what this PR does.
## Changes
- Change 1
- Change 2
## Related Issues
Fixes #123
## Testing
- [ ] All tests pass
- [ ] New tests added
- [ ] Linting passes
- [ ] Tested manuallyWhen adding features, update:
- README.md - User-facing documentation
- CHANGELOG.md - Version history
- docs/ - Technical documentation
- Docstrings - Code documentation
- Use clear, concise language
- Include code examples
- Add screenshots for UI features
- Link to related documentation
See custom_components/bmw_wallbox/docs/RELEASES.md for the release process.
We follow Semantic Versioning:
- MAJOR (1.x.x): Breaking changes
- MINOR (x.1.x): New features (backwards compatible)
- PATCH (x.x.1): Bug fixes (backwards compatible)
- Issues: GitHub Issues
- Discussions: GitHub Discussions
- Documentation: Check
custom_components/bmw_wallbox/docs/
- Be respectful and constructive
- Welcome newcomers
- Focus on what's best for the community
- Show empathy towards others
By contributing, you agree that your contributions will be licensed under the MIT License.
Feel free to open a discussion or issue if you have questions!