feat: enhance devcontainer with venv management and configurable HA installation - #297
feat: enhance devcontainer with venv management and configurable HA installation#297jpawlowski wants to merge 27 commits into
Conversation
…omments in validation
… use of Ruff for linting
…ptions, add version inputs
…t and error handling details
…n keys; enhance error handling and add reconfiguration support in config flow
…res, development scripts, and next steps
…anslations for clarity
…sary constructor parameters; streamline entity initialization
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR comprehensively modernizes the integration blueprint's development environment with enhanced scripts, improved DevContainer configuration, and updated integration code to follow current Home Assistant best practices. The changes introduce the "Scripts to Rule Them All" pattern, add support for the uv package manager, and enhance developer tooling with comprehensive pre-commit hooks, linting, and type checking support.
Key changes:
- Enhanced development scripts following standardized patterns with unified output formatting
- Updated Home Assistant compatibility to 2025.7+ with synchronized dependency management
- Modernized integration code with translation keys, diagnostics support, and improved error handling
Reviewed changes
Copilot reviewed 46 out of 53 changed files in this pull request and generated 19 comments.
Show a summary per file
| File | Description |
|---|---|
scripts/* |
New development scripts (bootstrap, setup, develop, clean, lint, test, etc.) with standardized output |
scripts/.lib/output.sh |
Shared library for consistent colored output across all scripts |
scripts/setup/* |
Setup utilities (bootstrap, reset, sync-hacs) for environment management |
schemas/json/* |
JSON schemas for manifest and translation validation |
requirements.txt |
Updated to remove Home Assistant core (now managed via bootstrap) |
pyproject.toml |
New project configuration with Ruff, pytest, and metadata |
hacs.json |
Updated Home Assistant version requirement to 2025.9.4 |
config/configuration.yaml |
Enhanced development-friendly configuration with reduced logging noise |
custom_components/integration_blueprint/*.py |
Modernized integration code with translation keys, diagnostics, and error handling |
README.md |
Updated documentation explaining new scripts and features |
.devcontainer/* |
Modular DevContainer configuration with Git setup automation |
.editorconfig, .prettierrc.yml, etc. |
New editor and formatter configurations |
.pre-commit-config.yaml |
Pre-commit hooks for automatic code quality checks |
.github/workflows/* |
Updated CI workflows to use new scripts and uv |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
A quick glance. |
|
Quite many of it belongs together, most don't make sense by themselves 🤷♂️ |
…nstallation Changes to development environment setup: **devcontainer.json:** - Add containerEnv with HA_VERSION (default: 2025.11.3) for flexible HA core versioning - Add Python environment variables (PYTHONASYNCIODEBUG, PYTHONUNBUFFERED, PYTHONDONTWRITEBYTECODE, PYTHONUTF8) - Configure Python interpreter path to use workspace .venv - Add Pylance analysis settings with workspace-scoped diagnostics - Configure analysis include/exclude paths for better IDE performance - Add extraPaths to resolve dependencies in .venv site-packages **bootstrap script:** - Create and manage Python virtual environment in $HOME/.venv with workspace symlink - Auto-activate venv in bash/zsh shell configurations for persistent sessions - Remove --system flag from uv pip install to use venv instead of system Python - Install Home Assistant core with configurable HA_VERSION environment variable - Download and install requirements_all.txt for full integration dependency support - Download and install requirements_test.txt + requirements_test_pre_commit.txt for testing - Add cleanup of temporary requirement files after installation **requirements.txt:** - Remove homeassistant package (now installed via bootstrap with version control) - Clarify file purpose: project/dev tooling only **.pre-commit-config.yaml:** - Update ruff hooks to activate venv before execution for consistent tool versions This provides an isolated, reproducible development environment with proper dependency management and IDE integration for custom Home Assistant integration development.
d9d149a to
356d785
Compare
|
@ludeeus i stripped down the patch to what I think is essential. However, using venv comes with some other implications that leave room for improvement. |
| pipx install uv | ||
| fi | ||
|
|
||
| echo "==> Checking for Python virtual environment..." |
There was a problem hiding this comment.
Why is a venv needed inside a devcontainer?
There was a problem hiding this comment.
The reason is that we would need to use sudo permissions to install in system context:
# uv pip install --system homeassistant==2025.12.0
Using Python 3.13.9 environment at: /usr/local
Resolved 127 packages in 388ms
Prepared 16 packages in 5.26s
error: Failed to install: click-8.3.1-py3-none-any.whl (click==8.3.1)
Caused by: failed to create directory `/usr/local/lib/python3.13/site-packages/click`: Permission denied (os error 13)We are installing uv in user context already and it is not available in system context.
In the end, we are following the HA Core setup here which I think is where we want to be as closely aligned as possible.
There was a problem hiding this comment.
in HA core devcontainer is a secondary option.
Having a virtual environment (venv) in a container is isolation within isolation?
There was a problem hiding this comment.
The reason here is not isolation but simplicity. Following the rule not to use sudo is never a bad idea...
There was a problem hiding this comment.
It is inside a container, why does it matter?
There was a problem hiding this comment.
People will not like to have to add --system and use sudo every time they install something manually. It just feels more natural to do everything in user context, despite the container. I wouldn't overcomplicate things.
But hey, you do you. You can change the code to whatever you feel is right for your blueprint.
…F-8 setting since it is default for Python 3.13
|
Any update? 😄 |
|
When it comes to me, I've created my own template in the meantime. |
| - id: ruff-format | ||
| name: ruff format | ||
| entry: ruff format | ||
| entry: bash -c 'source $HOME/.venv/bin/activate && ruff format "$@"' -- |
There was a problem hiding this comment.
This will not work out of the container (it's not always in $HOME)
| fi | ||
|
|
||
| echo "==> Checking for Python virtual environment..." | ||
| if [ ! -d "$HOME/.venv" ]; then |
There was a problem hiding this comment.
What if this script is run not in devcontainer, and the user has $HOME/.venv for completely unrelated reason?
|
If choose to place This way .venv stays at the conventional project root location, so 2 issues Shulyaka raised can be easily solve, scripts doesn't need to care whether it's running inside a devcontainer or not. |
Changes to development environment setup:
devcontainer.json:
bootstrap script:
requirements.txt:
.pre-commit-config.yaml:
This provides an isolated, reproducible development environment with proper dependency
management and IDE integration for custom Home Assistant integration development.