Add devcontainer environment for vscode #4674
Conversation
Problem: it is hard to develop flux-core locally. This addition will allow VSCode users to quickly run (and work in) a development container, defined under .devcontainer in the root, which contains a devcontainer.json file and a Dockerfile that uses the fluxrm/testenv:focal base to quickly pull and spin up the container. We need the Dockerfile to support a post start command to fix a git security issue, and also add developer tools like formatters, linters, etc. This is a vanilla install, meaning it just will allow for build of the core flux, and as other developers try this out we can easily add other extensions that make the development experience better! Signed-off-by: vsoch <vsoch@users.noreply.github.com>
There was a problem hiding this comment.
This seems good to me. I'm not a VScode user so can't really comment on implementation.
The new vscode doc in the README is pretty vscode+developer specific, so I thought maybe it should be in a collapsible section, but then again there isn't much in there so it doesn't really matter at this point.
|
@grondo we probably need a strategy for having explicitly developer documentation - I think for Python (my pre-commit PR) it worked well to put under docs/python, but for this I wasn't sure where it would best go, because most of the content here is maaaaaaan pages! 🦇 👨 |
|
Yeah, works for me! My only suggestion was maybe to put in a collapsible field, but it certainly isn't critical at this point. Feel free to set MWP unless someone else has objections? (I'm not sure if there are any other developers that work on flux-core and use vscode to test this out) |
|
@trws I thought you mentioned you might? I would argue to not put it in a collapsible section because:
And do you mean like this? Hello this is details!echo raining meatballs!I guess I've never thought to use that in a readme - didn't think it would work! Definitely need to try now! |
|
I only know about collapsible sections because we already use it in the README. Like I said I'm fine without it. |
Codecov Report
@@ Coverage Diff @@
## master #4674 +/- ##
==========================================
- Coverage 84.25% 83.38% -0.87%
==========================================
Files 410 413 +3
Lines 61367 69423 +8056
==========================================
+ Hits 51706 57891 +6185
- Misses 9661 11532 +1871
|
I am probably good either way - if someone else wants to chime in for a third vote I'll be happy to just do that! |
|
I do sometimes, and can test. I’m good with MWP honestly if you are, then I can test and come back with some config files to get automatic intellisense setup for c and python. It’s a little fragile, and very slow, because of autotools but it works pretty well. |
Problem: it is hard to develop flux-core locally.
Solution: This addition will allow VSCode users to quickly run (and work in) a development container, defined under .devcontainer in the root, which contains a devcontainer.json file and a Dockerfile that uses the fluxrm/testenv:focal base to quickly pull and
spin up the container. We need the Dockerfile to support a post start command to fix a git security issue, and also add developer tools like formatters, linters, etc. This is a vanilla install, meaning it just will allow for build of the core flux, and as other developers try this out we can easily add other extensions that make the development experience better!
The one sticky bit was with git permissions - if you sign you can't commit from inside the container (no keys) and then when you go outside the container, having commit inside the container, you get a permissions issue (that can be fixed with a chown). Likely the best solution is just not to write to git (commit) from inside the container for now, and people can play around and see if there is a better way to go about it. I don't personally mind bringing up another terminal.
My thinking is that we can get a vanilla version in first, and then those that try it with VSCode that have preferences for extensions can propose adding them separately.
Signed-off-by: vsoch vsoch@users.noreply.github.com