Feature/adds development container

[jasonwashburn]

This PR adds config and scripts for a devcontainer running on the rust/bullseye variant. The WASI-SDK and Spin versions used at build time, can be modified by changing args passed to Dockerfile in devcontainer.json.

Compilation of cPython and spin-python-sdk are performed in a post creation command script since they rely on the repository being available (not the case during build time when using on GitHub codespaces)

I've tested it successfully as is on both GitHub Codespaces, and on an x86 linux host, but it could probably use a little more testing in other configs, ie: on windows, or maybe with different versions of wasi-sdk / spin version, though I don't know the currently compatibility story there, so maybe not relevant.

Known issues:

• Doesn't currently work on newer (m1, m2) MacOS hosts due to glibc2 issues with spin installer on aarch64 bullseye. (believe related to spin/168 and similar to bartholomew/150
• Based on previous experience locally, I also expect to have trouble with compiling cPython on newer MacOS hosts as well once past the spin installer

Opening up draft PR to facilitate discussion and collect feedback on experience, or thoughts on improvements to the config, extensions, included python tooling etc.

[jasonwashburn]

It seems there's an issue with trying to switch the variant to buster. When you do so, the spin install script fails for a missing version of glibc (See output below). Looks to be related to fermyon/spin#168 and fermyon/bartholomew#150 as well, not necessarily an issue with the python sdk or the devcontainer, other than maybe don't use buster.

Confirmed same error when using spin versions 0.9.0 thru canary, which can be changed by passing into the command below as a build arg --build-arg SPIN_VERSION=v0.9.0

reproducible by building the devcontainer manually:
docker build --build-arg VARIANT=buster .devcontainer/.

Step 10/10 : RUN cd /tmp     && curl -fsSL https://developer.fermyon.com/downloads/install.sh | bash -s -- -v $SPIN_VERSION     && sudo mv spin /usr/local/bin/     && cd -
 ---> Running in 54c0fee46bb9
Step 1: Downloading: https://github.com/fermyon/spin/releases/download/canary/spin-canary-linux-amd64.tar.gz
Done...

Step 2: Decompressing: spin-canary-linux-amd64.tar.gz
crt.pem
spin.sig
README.md
LICENSE
spin
./spin: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./spin)
./spin: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.29' not found (required by ./spin)
The command '/bin/sh -c cd /tmp     && curl -fsSL https://developer.fermyon.com/downloads/install.sh | bash -s -- -v $SPIN_VERSION     && sudo mv spin /usr/local/bin/     && cd -' returned a non-zero code: 1

[mikkelhegn]

Does installing the build dependencies, like described here: https://developer.fermyon.com/spin/install#building-spin-from-source help?

[jasonwashburn]

I hadn't tried it, but I suspect it probably would since it should link against the correct glibc. Wasn't sure of the best way to go on it. Since it's being used for development, my initial thought was to just duplicate the environment that the main spin repo is build in, to keep things the same. Though, it wouldn't be linked, so there's just a much a chance of getting out of sync, so maybe building from scratch based on the selected variant and spin version. 🤔

easy enough to try out either way, I'll see if I can knock that out in the next day or so

[jasonwashburn]

hmm...I thought I had responded to the previous question already but apparently I did not...Long story short, switching to building spin from source didn't fix the issue, I started running into the same glibc error messages from the wasi sdk as well.

After taking another look at my original goal for building a devcontainer, to get a dev environment with dependencies up and running quickly and reproducibly, I've decided to limit the devcontainer install/build to just the prerequisite installed dependencies listed in the README to get a user right up to the point where they can run the build scripts (build-python.sh and make), following the instructions in the README, rather than automating the full build during container startup. I think this will work better with future changes that require changes to the build system, cpython versions etc.

[jasonwashburn]

Alright, I think I have it in a good place. Tested it on Ubuntu, Ubuntu in WSL , and on Github Codespaces by pulling the repo from scratch, building the devcontainer in vscode and then following the instructions in the readme to build the plugin, then test it with the example hello world app. I made an update to the readme about needing to do a git submodule update before trying to run the build-python.sh.

[mikkelhegn]

Could this and the CPython build be part of the container creation?

[jasonwashburn]

We could actually do a couple of things here. I flipped back and forth a couple of times on it previously. It all comes down to the usual workflow...if there is rarely a need to rebuild cpython or make changes to the branch etc, then it probably makes sense to move it into the dockerfile and take advantage of image caching...the build is already long enough to be a "walk away for a bit" build the first time, so I'm not adverse to just including the python compile as well.

Ultimately I made the decision to leave it this way after looking at how the development steps are listed in the README...ie: install these dependencies (stuff I put in dockerfile) and then steps begin with "run this script" which I left up to the user.

I'll defer to you guys at Fermyon though as far as which way would be a better developer experience given the normal workflow and tasks that are often performed?

[jasonwashburn]

As discussed on discord, I switch the devcontainer to use an artifact compiled version of wasi cpython, so running these commands is no longer necessary when using it. Added notes to the affected steps in the README.

[mikkelhegn]

LGTM

[mikkelhegn]

Thanks @jasonwashburn. One last thing is to to make sure your commits are signed before we can merge them.

[jasonwashburn]

I'm sure you guys are busy, just checking back to make sure there's not something additional you'd like to me to do with this?

[itowlson]

Sorry about that @jasonwashburn, I'm not sure what happened there! I've merged it now - thanks for putting this together!