Update dev container with latest reference#246
Update dev container with latest reference#246sveinse merged 4 commits intocustom-components:masterfrom
Conversation
* Update pacakge setup (missing field) * Setup automatic GitHub Actions for validation * Change to ruff and set defaults
steinmn
left a comment
steinmn
left a comment
There was a problem hiding this comment.
Do you have a Pt1.5 ready with all the fixes required to pass linting? I tried running scripts/lint, and I got 14 changed files and "Found 481 errors."
requirements.txt
Outdated
| ruff==0.12.1 | ||
| bleak==0.22.3 # bleak 1.0.0 breaks habluetooth as of 2025.06.29, remove once https://github.com/Bluetooth-Devices/habluetooth/issues/248 is resolved | ||
| homeassistant==2025.7.3 | ||
| pip>=21.31.1 |
There was a problem hiding this comment.
Why such an old version of pip? My container ended up with 25.1.1 anyway, but is there a specific reason to do this (and remove the <25.2 part)?
There was a problem hiding this comment.
This was a copy from the hacs blueprint. In the rule that was removed it said "pip>=25.0,<25.2". Why the upper limit on version "<25.2"? Why not pick the latest? I'm happy to use "pip>=25.0" here.
There was a problem hiding this comment.
Usually it's to avoid getting a new version that drops some deprecated feature you haven't had time to remove from your code yet. But I haven't seen any deprecation messages or obvious deprecations in the changelog that we should worry about, and since it's just a dev-container, we can just add the <25.2 back in if it turns out it causes problem when 25.2 is released.
.devcontainer.json
Outdated
| }, | ||
| "editor.formatOnPaste": false, | ||
| "editor.formatOnSave": false, | ||
| "editor.formatOnSave": true, |
There was a problem hiding this comment.
Is this a HA-standard we need to comply with? As previously mentioned, I'm really not a fan of the formatOnSave behaviour, and the validate-workflows should still keep format errors from being merged into master, right?
There was a problem hiding this comment.
We don't have to comply, but it seems to be the norm. But if its very provocative, we can disable it.
I chose not to install the lint GHA workflow yet, so there is nothing stopping us from pushing "wrong" formatted code as of now. It's only this. With the format on save disabled, one must be mindful of the formatting .e.g. by running it manually from time to time. This is how I have been doing it until now.
The most important part is to change to ruff, as it does things somewhat different than black, so its consistent with HA.
There was a problem hiding this comment.
I think we should at least ensure all files are fully formatted before turning on formatOnSave, otherwise we get unrelated changes automatically added when editing a file.
|
|
||
| cd "$(dirname "$0")/.." | ||
|
|
||
| ruff format . |
There was a problem hiding this comment.
Do you have a Pt1.5 ready with all the fixes required to pass linting? I tried running
scripts/lint, and I got 14 changed files and "Found 481 errors."
No, I do not have any immediate plans to fix the currrent linting errors. In the hacs blueprint there is a lint GHA as well that would fail the merge if we implemented it right now. I have plans to add it, but we need to work through all these 483 errors manually. I won't prioritize this now, so we'll have to live without that part for now.
Do you think having ruff format . is a little too ambitious right now with the state of the source?
There was a problem hiding this comment.
I tested running scripts/lint without the ruff check --fix line now, and it wasn't nearly as bad as I'd feared with only 4 files changed (and mostly minor changes). If we are going to keep formatOnSave, then I think those 4 files should be fixed in this or the next separate PR, so that the changes aren't added to some random unrelated PR modifying those files.
There was a problem hiding this comment.
I just found out that, is that the ruff format setting in our dev container and in HA core is different. That is very annoying if they compete for the layout. I need to figure out what HA does that this configuration doesn't
|
I've been running zaptec for a long time under a more complicated setup, and this has been a great opportunity to clean up the dev-container setup so we have a good working setup for all. I just wanted to show you what that's like: My setup:
For debugging and running
This is a lot of moving parts, so if we get the dev-container properly working with zaptec, I hope to shave all that down. -- That said, the good thing about having HA core available, is that often when needing to figure out to do things in zaptec, I need to look at the other components/integrations in core. |
Well, all the other components in core are available in the zaptec-dev-container under |
|
OK, I think its is ready to go now. I've added an option to get git working in the dev containter too (but the user must opt in). I've looked at the current formatting and import order errors we got, and I don't think its going to be too hard to make a follow-up PR to fix them. The whole list of |
2 participants
This is an overhaul of the dev-container setup. It updates the development environment for this integration, putting us closer to the HA standard. It takes inspiration from https://github.com/ludeeus/integration_blueprint and from https://github.com/home-assistant/core. This is pt1 of #185. Pt2 is the actual documentation which I'm working on.
This has been tested on a fresh machine. HA starts fine with not that many errors, and intellisense lookup of the HA classes now work in the dev container. It changes linter to ruff, which is the standard in HA now.