Add JupyterLab as a feature

[bratsche]

If Python is not installed, error out and tell the user that it's missing for now. The intent here is to improve this to auto-install Python later, but this seems like a good first step.

[Chuxel]

Wouldn't it make sense to check to see if it's already there before installing? I'd also recommend checking this with the python-3 and python-3-anaconda definitions since I gartunee people will use it with that.

You should probably also deal with cached wheels, etc here. Not doing that will leave a lot of unneeded content in the image (making it even bigger). Adding --no-cache-dir at a minimum to the pip install would make sense.

@dynamicwebpaige Does it make sense to do this as a straight pip install (verses pipx)? I kind of assume so, but thought I'd ask.

[Chuxel]

A few other thoughts here in thinking about it.

Features are installed using the "root" user. The problem here is that you could end up inadvertently end up doing one of two things:

1. Locking up the pip cache and management files that can only be edited by root. My hope would be --no-cache-dir would avoid this, but I'd double check.
2. Installing in the user's pip folder, which in this case would be "root" and therefore not accessible by a non-root user like codespace / vscode / node, etc.

I'd verify what happens on disk after this is installed to be sure nothing major breaks. You also may want to set umask 0002 so that any group access is retained... or detect the non-root user and fire pip there instead to add.

Also - for codespaces-linux, be sure to verify the scenario where a version of python is dynamically acquired by Oryx. If you use "pipx" you'd be abstracted from those kinds of changes. But I'm not sure what would happen if you install when the default version of python in the image using pip and then a different one ends up getting used to. I'd be worried it would just totally break or, failing that, it wouldn't be in the virtual environment that was created.

e.g., add a runtime.txt file with python-3.6.9 in it in the repo - that would case this to happen.

This one is very specific to that image... you wouldn't see it in a normal python / anaconda one. Unlike something like node, there's a lot of version specific magic tied to native compilation in pip packages.

[joshspicer]

If it's helpful, @Rabadash8820 's PR adding in the aws-cli is a great example of contributing a new feature #1326

[bratsche]

Wouldn't it make sense to check to see if it's already there before installing?

Thanks, I added a check for this.

I'd also recommend checking this with the python-3 and python-3-anaconda definitions since I gartunee people will use it with that.

Works fine with python-3. I made a small change to python-3-anaconda to copy .devcontainer/library-scripts/*.sh instead of just node-debian.sh and that got it working there.

You should probably also deal with cached wheels, etc here. Not doing that will leave a lot of unneeded content in the image (making it even bigger). Adding --no-cache-dir at a minimum to the pip install would make sense.

Added --no-cache-dir to the installation.

[bratsche]

Thanks for your comments @Chuxel!

A few other thoughts here in thinking about it.

Features are installed using the "root" user. The problem here is that you could end up inadvertently end up doing one of two things:

1. Locking up the pip cache and management files that can only be edited by root. My hope would be --no-cache-dir would avoid this, but I'd double check.
2. Installing in the user's pip folder, which in this case would be "root" and therefore not accessible by a non-root user like codespace / vscode / node, etc.

I'd verify what happens on disk after this is installed to be sure nothing major breaks. You also may want to set umask 0002 so that any group access is retained... or detect the non-root user and fire pip there instead to add.

I updated it to install to the non-root user if there is one. This installs jupyter-lab to ~/.local/bin/jupyter-lab

Also - for codespaces-linux, be sure to verify the scenario where a version of python is dynamically acquired by Oryx. If you use "pipx" you'd be abstracted from those kinds of changes. But I'm not sure what would happen if you install when the default version of python in the image using pip and then a different one ends up getting used to. I'd be worried it would just totally break or, failing that, it wouldn't be in the virtual environment that was created.

e.g., add a runtime.txt file with python-3.6.9 in it in the repo - that would case this to happen.

This one is very specific to that image... you wouldn't see it in a normal python / anaconda one. Unlike something like node, there's a lot of version specific magic tied to native compilation in pip packages.

I added the runtime.txt with python-3.6.9 as you suggested. In the logs I'm seeing the following:

Downloading and extracting 'python' version '3.6.9' to '/opt/python/3.6.9'...
Downloaded in 1 sec(s).
Verifying checksum...
Extracting contents...
performing sha512 checksum for: python...
Done in 2 sec(s).

image detector file exists, platform is python..
/tmp/BuildScriptGenerator/0840f23b71354aec894853987bbe8595/build.sh: line 131: /etc/ld.so.conf.d/python.conf: Permission denied
Could not auto-build. Skipping.

And when I I run python --version it's showing me 3.8.12.

I'm testing it outside of my branch to try to figure out if this is something that broke in my branch somehow.

[bratsche]

That issue I'm having with runtime.txt seems to be happening outside my branch, fwiw.

[bratsche]

Hacking the Dockerfiles to add touch /etc/ld.so.conf.d/python.conf && chown codespace:codespace /etc/ld.so.conf.d/python.conf fixes (well, works around) the issue above, but then I get another permission denied error after that: /sbin/ldconfig.real: Can't create temporary cache file /etc/ld.so.cache~: Permission denied. It seems like a kitchen sink bug with Oryx.

[bratsche]

Possibly related to the runtime.txt issue: microsoft/Oryx#1206

[bratsche]

I worked around the issues with runtime.txt and confirmed that JupyterLab was working just fine with an Oryx-installed version of Python.

[joshspicer]

Great - @bratsche and I chatted and now with additions to the PATH, smoke test passes