Closed ndarilek closed 4 years ago
while the start script only enters it when in Docker
Minor correction: the start script does not enter the virtualenv when run in docker.
Doesn't change the conclusion though: dev_setup.sh
(as run during docker build
) sets up a venv, and start-mycroft.sh
(as run during docker run
) does not use a venv. This completely breaks running mycroft via docker. Because mycroft doesn't release versioned docker images, I can't roll back either :(
My workaround has been to run docker run bash -c 'rm /.dockerenv; exec /opt/mycroft/startup.sh'
(or rather the equivalent on k8s)
I'm moving this over to the Docker repo.
The main issue here, that the Docker build is failing, has been fixed in b18034cf85931d0d70c51e02a7b7d785b2cc5305. Waiting for the Mycroft team to push a new build to Docker Hub.
I made a fix for part of this in the Docker repository, but it looks like the ultimate fix is a bit more complex, and I wanted to ask for a quick sanity check before completing it. From dev_setup.sh:
From start-mycroft.sh:
So it looks like dev_setup.sh, which is run from Docker, indiscriminately creates the virtualenv, while the start script only enters it when in Docker.
Is that analysis correct? If so, which solution is the right one? Should we always create a virtualenv, or should we selectively not create/enter one when in Docker? I'd opt for no Docker-specific tweaks in the main repo unless absolutely necessary, so removing the Docker check from
source-venv
or maybe evensource-venv
entirely and just runningsource
. But maybe there's a reason for that?In any case, Docker for development environments is nice, so I'd like to get this working again. :) The official build on Docker Hub is several months out-of-date, and it looks like it's automated, so I assume if we fix this then the process will start again and we'll have updated builds without effort on your part. Thanks!