Python 3.13 support

[markusressel]

Is there an existing feature request for this?

• [x] I have searched the existing issues

Your feature request

Python 3.13 is already released since October 2024, and major distros use it as the default python interpreter. This makes it difficult to create a local venv based on the older python 3.12 version, which is needed for the appdaemon packages 4.5.0 - 4.5.2. This in turn makes it difficult to get IDE support for included methods of AppDaemon, since the IDE cannot inspect the AppDaemon code if its not installed locally.

Whats holding back support for python 3.13? Maybe it can already be included without issues?

[jsl12]

Persistent namespaces are what's broken in 3.13. Python seems to shift around what they're doing with DbfilenameShelf on the backend, and it's also different across platforms.

In the meantime, I'd suggest using uv if you aren't already. It's extremely easy to manage python versions, create venvs, install dependencies, etc

[markusressel]

It took a while to get uv rolling with PyCharm, but it works now, thx. Still would like to see 3.13 support at some point, so I will leave this issue open.

[jsl12]

I'm actually really glad you bring this up because I think I'm the first contributor in quite some time to really take a look under the hood in this project.

Getting off the ground really was not easy, and took some considerable effort. One of the first things I did was fix/add type annotations so that things like "goto definition" or "find usages" actually works in IDEs. That alone revealed all kinds of stuff like slightly different implementations of the same logic in multiple places. The type annotations aren't complete yet, but at least potential contributors have something that kinda works.

I actually use NixOS as a daily driver, and totally agree that that's the direction to go. I've been developing on my side using a devenv shell that itself uses uv. @acockburn has worked with devbox a bit, which is also based on Nix shells, so I think we're going to move to that for development very very soon when the dust settles from the 4.5.x releases. That should smooth out a lot of stuff for the developer experience.

Beyond that, I also agree that having tests is really important. It's just that the startup is a little hairy at the moment, and I need to clean that up some to make it more suitable for use in test fixtures. I have an almost working situation for that on a local branch that I intend to finish and push soonish, but only after the rest of the project tooling.

Enabling more people to contribute is one of my kinda meta goals with even getting involved in this project to begin with, and it is something I actively think about when working. Hopefully that's at least somewhat encouraging. Keep an eye on the "internal documentation" section of the docs for progress

Edit: Forgot to mention above, but I am aware of the nixpkg for AppDaemon, and intend to work through making a "real" version of that at some point, but it's currently pretty low on the long list of upcoming work

[markusressel]

I think the proposal by @hacscred sounds very interesting, should be a separate Issue to be worked on at some point IMHO. Would be interested in a basic writeup of what would be possible using nix shells. I understand correctly that you do not need to run Nix OS to use this, right?

[jsl12]

That's correct. Unfortunately the term "nix" refers to a many different things. One of them is a package manager that you can install on other distros. This can install packages from nixpkgs, which is a huge repo with wrappers around existing software that are written in the nix language. Nix shells provide like a customized subshell/environment you can enter where everything is set up exactly right, down to every minute detail.

The whole idea behind the nix ecosystem is determinism, which turns out is extremely non-trivial in the case of modern software. It's very difficult to get byte-for-byte builds across time and platforms, even in controlled build environments, and the nix ecosystem is a serious attempt resolving that. That means that every little flag of every compiler for every dependency all the way down the entire tree is exactly specified somewhere. Projects that are really professional include nix flakes (another nix concept), which makes it easy to get into a nix shell with the project or makes it importable from another flake.

See Vimjoyer's channel for more information about nix and nix shells