Closed DrewDevereux closed 4 years ago
Thanks for the VScode addition, @DrewDevereux. Improving the docs is always welcome.
It would have been nice if
python setup.py build
could have been added to the container config as apostCreateCommand
, but unfortunately that has proven problematic (when run as apostCreateCommand
, it gets stuck in thebuild-ext
stage atsubprocess.Popen
.)
Yes, it would be nice if the extension was compiled in the container the first time. The compilation does take around 10 minutes, so was it really stuck, or just churning away in the background?
If we're just changing the Python files, then this would work well. However, if any of the extension C++ code is changed as part of our development, we need to remember to rebuild the extension. I typically have the pytango source on my host, but mounted inside the container. Then the result of a python setup.py build
persists when the container is relaunched. At least that's what is happening with PyCharm. I imagine it would be similar with VScode.
I shouldn't have said it "gets stuck": it fails when it reaches that Popen. Yes, that's how VScode works: the source is on the host, and VScode mounts it, writable, in the container.
This pull request adds VScode remote container support.
There's not much to it: just a basic
devcontainer.json
configuration file, and a couple of paragraphs of documentation.I also markdownlinted the
README.md
while I was editing it, I hope that's okay.It would have been nice if
python setup.py build
could have been added to the container config as apostCreateCommand
, but unfortunately that has proven problematic (when run as apostCreateCommand
, it gets stuck in thebuild-ext
stage atsubprocess.Popen
.)