Open MichaelX99 opened 4 years ago
Summoning @groodt for his thoughts.
I always assumed that the *.dev Dockerfile was designed to work in coordination with a dev loop on the host machine.
I think this probably happened after the refactor to move to a top-level src
structure in https://github.com/nteract/commuter/pull/296
@MichaelX99 The Github workflow is to fork it and then PR.
Hi I am starting to poke around at Notebook based workflows and discovered this very cool tool, thank you for developing it! I tried running both Dockerized routes and could not get either to work. When running the exact commands as they appear in the README for the development Dockerfile I got the following error:
Please excuse me if I use the wrong terminology, I don't use Javascript and am not familiar with its tools but the reason why this is failing is because the current working directory is being mounted on top of the /app directory in the container. Unless you run yarn && yarn dev before you enter into the container then there will not be a lib subdirectory when you mount your current directory into the container. I believe this breaks a Dockerized workflow since it places added dependencies on your system besides just Docker (for example I am a Python developer and did not have yarn/node/npm on my local but I do have Docker).
The solution that I propose is to copy in the src directory along with some of the other files like package.json and then run
yarn && yarn predev
inside the Dockerfile so that the lib directory exists inside the image. Then when we run the container, we do not mount the entire $(pwd) but mount specific subdirectories so /app/lib is not overwritten by the blank directory on our hosts. I have a working branch ready for reviewal on my local but do not have the permissions to push to start the review.