#Config/deps

1 messages · Page 1 of 1 (latest)

left whale
#

There's an issue open where deps are being included in a backup, I'm curious what their system looks like

mint acorn
#

Yes, that's exactly the background for my question

#

They opened a PR to exclude deps, which we closed because deps is not used in any supported installation method

left whale
#

Ah check

#

Did you ask how they were using it?

grizzled oyster
#

When using the devcontainer Home Assistant runs in a virtual environment.

(ha-venv) vscode ➜ /workspaces/core (dev) $ ls  /home/vscode/.local/ha-venv/lib/python3.14/site-packages/tibber 
const.py  data_api.py  exceptions.py  gql_queries.py  home.py  __init__.py  py.typed  realtime.py  response_handler.py  websocket_transport.py
(ha-venv) vscode ➜ /workspaces/core (dev) $ ls  /home/vscode/.local/ha-venv                                    
bin  cache  CACHEDIR.TAG  lib  lib64  LICENSE  pyvenv.cfg  requirements.txt  share
(ha-venv) vscode ➜ /workspaces/core (dev) $ which python
/home/vscode/.local/ha-venv/bin/python
#

I think we can work to remove deps. Can we assume the existing repair issue for core installations is enough or do we need to deprecate this separately?

mint acorn
#

I think the existing repair is enough

#

The repair about unsupported installation method says:

This system is using the {installation_type} installation type, which has been deprecated and will become unsupported following the release of Home Assistant 2025.12. While you can continue using your current setup after that point, we strongly recommend migrating to a supported installation method.

#

What's the meaning of:

you can continue using your current setup after that point

#

Does it mean it's OK to upgrade to, for example, HA Core 2026.4, but we advise against it, or does it mean 2025.12 is the last version where it was possible to run the unsupported method?

#

If it's still OK to upgrade to new version, I guess we need a new repair

#

I was going to simply add a check in main() which exits if core is not running in a venv or a container since we no longer support core as ain installation method. But I guess that's not possible then? Instead there would have to be a log + repair saying running outside a venv or container will stop working in 6 months?

grizzled oyster
#

I think we should just remove the first part of the last sentence in the repair issue unless we have promised something like that in the architecture discussion. It just gives a false sense of support.

#

If it would mean that they could continue upgrading without consequences we would still need to support the deprecated methods, which doesn't make sense.

mint acorn
#

@viscid nova do you remember why you wrote it like that?

#

But still, do you think it's OK to just exit early from main() if not running in a venv or container, or should we warn for 6 months?

viscid nova
#

I just implemented the json sort and for that reason you see me in git blame

viscid nova
mint acorn
mint acorn
#

But yeah, it seems weird

mint acorn
mint acorn
#

Do we still need the the repairs for unsupported architectures? The repairs say we would stop providing builds in December 2025, if we did that we no longer need the repairs?

mint acorn
mint acorn
#

One more thing, we create the repair stating the core installation method is unsupported also in development environments. Should we amend the repair text to say it's OK to use for development?