You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on #11, #23 & #24 i've noticed that there are a lot of edge cases for our deployment script. We rely on people running a recent version of macOS and having a reasonably standard setup. I've had to switch back to zsh to develop the script as my usual shell is fish - which isn't POSIX compliant.
Using docker would allow us to rely on a fixed environment across development and possibly production - for example the hub server could run in a cluster with other apps needed for home.
Docker would solve our dependency problems as once one container works, we can almost guarantee anyone else who uses the same docker-compose.yml would be able to run exactly the same setup as us, which can help debugging.
Formalising the configuration and networking requirements into a Dockerfile wouldn't do any harm either, and this would help us iron out any bugs across our networking stack, especially with using websockets over SSL.
Using docker-compose we would be able to maintain a cross-platform "single-command" development tool, and rely on the hard work of others in the form of the Elixir container to keep our environment up to date.
Downsides are of course adding an extra dependency to our stack:
As for using Docker, unless we are deploying using docker (and don't have any other choice),
I would prefer to avoid it because it's another thing to have to maintain/update.
and it's yet more work on the development process for smart home.
Docker for mac is also HUGE so if people aren't already using it as part of other stacks, it is a large expectation for them to download and install it
The text was updated successfully, but these errors were encountered:
@th0mas Yeah, the Python script you've been working on is almost there.
Our objective is to have it running on a very narrow set of hardware/OS.
This project is Open Source because that's our ethos, but we really don't expect anyone else to run/use it ... 💭
(at least not in the short term...)
While working on #11, #23 & #24 i've noticed that there are a lot of edge cases for our deployment script. We rely on people running a recent version of macOS and having a reasonably standard setup. I've had to switch back to
zsh
to develop the script as my usual shell isfish
- which isn'tPOSIX
compliant.Using docker would allow us to rely on a fixed environment across development and possibly production - for example the hub server could run in a cluster with other apps needed for
home
.Docker would solve our dependency problems as once one container works, we can almost guarantee anyone else who uses the same
docker-compose.yml
would be able to run exactly the same setup as us, which can help debugging.Formalising the configuration and networking requirements into a
Dockerfile
wouldn't do any harm either, and this would help us iron out any bugs across our networking stack, especially with using websockets over SSL.Using
docker-compose
we would be able to maintain a cross-platform "single-command" development tool, and rely on the hard work of others in the form of the Elixir container to keep our environment up to date.Downsides are of course adding an extra dependency to our stack:
-- Mentioned in #11
and it's yet more work on the development process for smart home.
Docker for mac is also HUGE so if people aren't already using it as part of other stacks, it is a large expectation for them to download and install it
The text was updated successfully, but these errors were encountered: