#Threema Integration

1 messages · Page 1 of 1 (latest)

lusty thistle
#

Is this lib already included in the docker image? Or will it need a change there too?

#

Threema Integration

steady parrot
#

I believe that just works, like the CI also finishes

#

the thing I am more scared of is the dev env

lusty thistle
#

As long as you don't load the integration, it shouldn't be an issue, no?

steady parrot
#

yes, but that means I can't run those tests locally

#

I am not aware if there are other integrations that have this as well

#

and I am not sure if it's just me

steady parrot
lusty thistle
#

Fair, but since we only support installation by container (which will run just fine) and HASSOS (which should too) I don't think it should be a blocker. We shouldn't block things just because there is one developer which uses an unsupported dev env.

I just tried to run this in the dev container and its fine. You should also be able to run the tests there.

#

You mention PyNaCl. Does that not rely on the same binary?

steady parrot
#

no clue

steady parrot
lusty thistle
#

I do, but my dev env is special. So I would switch to the docker dev env in cases like these.

#

I probably only need to specify the lib in my devenv.nix

#

and it would work

steady parrot
#

I mean, in a way I am running a supported dev env, if we say that the ones listed in the docs are supported

#

I would be kinda annoyed if tests don't work at all for an integration, especially if we require tests to be ran before committing

lusty thistle
#

Hm, I don't think there are 'unsupported dev envs' - that was bad wording on my part. But we have supported installations methods. If the dev env you are using is not representative of the supported installation methods (which basically means - you don't develop inside the provided HA container) that's on you.
You and I are basically using the 'Core' installation method right now to setup our dev env. And that has been unsupported for a while now.

steady parrot
#

I mean more like

#

I would argue that these are supported dev envs, if something changes in our requirements, we should update this accordingly

#

If you come with an issue that something doesn't work on NixOS, I can't help you and I wouldn't consider that supported

#

If you run a dev env and you compiled python3 ffmpeg and such from scrach and you encounter issues, I also can't really help you

lusty thistle
#

yea, you're right. I guess the problem is that we try to give developers options to choose the right dev env but fail to mention downsides of each dev env. I think for most people a 'core style' dev env will be good enough and many might prefer that - so it would be weird not to list it and force everyone to the docker container.

Many integrations do make use of binaries and it's kind of a given that not all will work on all operating systems. But I don't think they should need to if we don't support that OS (otherwise this can spiral out of control).

#

It's also hard to update the dependencies needed in the docs for the core sytle dev env. Package names can change, integrations get added/removed.

steady parrot
#

We also don't run this every week so it's also a best effort I guess

#

But if we agree that if you buy a brand new mac, follow the instructions, setup the dev env, which should give you a working Home Assistant. Do we expect a broken single integration an issue

#

because this means you can't run the threema tests and you can't install the integration at all

#

(He has reached out to the vendor btw, but that might work, it might not)

#

Also an interesting one

# 
ImportError while loading conftest '/Users/joostlek/PycharmProjects/core/tests/components/threema/conftest.py'.
tests/components/threema/conftest.py:10: in <module>
    from homeassistant.components.threema.const import (
homeassistant/components/threema/__init__.py:12: in <module>
    from .client import ThreemaAPIClient, ThreemaAuthError, ThreemaConnectionError
homeassistant/components/threema/client.py:7: in <module>
    from threema.gateway import Connection, GatewayError, key
venv/lib/python3.14/site-packages/threema/gateway/__init__.py:26: in <module>
    from . import _gateway
venv/lib/python3.14/site-packages/threema/gateway/_gateway.py:5: in <module>
    import libnacl.encode
venv/lib/python3.14/site-packages/libnacl/__init__.py:87: in <module>
    nacl = _get_nacl()
           ^^^^^^^^^^^
venv/lib/python3.14/site-packages/libnacl/__init__.py:49: in _get_nacl
    raise OSError(msg)
E   OSError: Could not locate nacl lib, searched for libsodium
# 
Warning: libsodium 1.0.22 is already installed and up-to-date.
To reinstall 1.0.22, run:
  brew reinstall libsodium
lusty thistle
#

The people affected by this are realistically only maintainers (which should know why an error occurs and find ways around it - running tests in the docker container in this case) and the very few people having very bad luck who try to enhance an existing integration which uses a binary unsupported for their OS. Yes it sucks for those.

steady parrot
#

Yes, but it will suck big time

#

we sometimes have updates where we need to regenerate snapshots for all integrations (like recently when aliases changed in the entity), I think today I can run the full test suite. If this'd be merged, I can't run the full test suite

#

Haven't ran it in ages, but as far as I am aware this isn't common

#

(like if we already have 5% of integrations for which we can't run tests, then that'd be different, but I believe this is the first)

lusty thistle
#

Let's see if someone else has an opinion about this