Improve the Gitpod setup

[jtpio]

Opening a new issue to track follow-up improvements to the Gitpod setup.

Previous iterations:

• Add support for Gitpod editor #9883
• Edit Gitpod configuration to be able to work on the documentation #12697
• Update the Gitpod setup to use micromamba to bootstrap the dev environment #13030

@trallard originally posted in #13030:

• Add to the developer documentation

Also - while there is this work being done to add Gitpod (and it would reduce the friction for Jupyterlab dev and contributions), I would like to suggest adding docs to the developer docs such as https://numpy.org/devdocs/dev/development_gitpod.html
I can confirm that adding Gitpod + documentation has been a game-changer for contributions, sprints and even maintainers workflows for NumPy and SciPy, so worth a shot.

• Re-add comments to document prebuilds

#13030 (comment)

jupyterlab/.gitpod.yml

Lines 2 to 10 in 5ea1bc7

	prebuilds:
	master: true
	branches: true
	pullRequests: true
	pullRequestsFromForks: true
	addCheck: false
	addComment: false
	addBadge: false
	addLabel: false

• Use a custom Dockerfile

Since all these extras to use mamba are being added, I would highly recommend specifying a custom Dockerfile (see https://www.gitpod.io/docs/config-docker#configure-a-custom-dockerfile) this would help keep this config file cleaner and also removes the need to add later the echo "source /workspace/bin/activate-env.sh" >> ~/.bashrc command in line 40.
Plus, we can ensure that the corresponding environment is always activated by default and reduce the need to have all the gp sync related commands.
This is the approach currently used in NumPy and SciPy. This setup and leveraging prebuilds ensures that the Gitpod instance is pretty much ready to use once someone starts a new workspace.

• Add a couple more extensions

I'd also suggest adding a couple of extensions (i.e. Python language support, prettier) - as it also helps with developer experience (see https://github.com/numpy/numpy/blob/main/.gitpod.yml for a number of extensions added during the prebuild)

[trallard]

I can take a stab at this. From the previous conversation:

Just checked the config on the numpy repo:
https://github.com/numpy/numpy/blob/main/.gitpod.yml, and it looks very clean.

This seems to require building and pushing a custom Docker image in https://github.com/numpy/numpy/blob/main/.github/workflows/gitpod.yml. Probably this could also be made compatible with GitHub Codespaces then.

We decided on this due to the mix of compiled and runtime dependencies - for JLab we could get away with not rebuilding and pushing but specifying the gitpod.Dockerfile instead.

As for codespaces - I do not think this will be compatible 1:1 but I can try something out.

[firai]

I'm not sure if this belongs here or in a separate issue, but is there a reason why JupyterLab isn't started in the Gitpod setup with the --collaborative flag by default? This would allow RTC features to be tested once the port is made public, and it would at least show the RTC side panel by default. As a point of comparison, the Binder setup seems to enable RTC by default. It's possible to kill the default instance and refire it with the flag, but that's more work.

I can file this as a separate issue if needed, and I can add a PR for this as well if it's just an omission.

As a side note, Gitpod seems to compile for me much more reliably than Binder, so it's been quite useful.

[jtpio]

Thanks @firai.

Adding the --collaborative flag by default sounds good. Folks can still Ctrl-C in the terminal and remove it if needed to test without RTC.

I can add a PR for this as well if it's just an omission

That would be great thanks!

Maybe @trallard already has some work-in-progress on the setup refactor, but we can definitely add that new flag before as well.

As a side note, Gitpod seems to compile for me much more reliably than Binder, so it's been quite useful.

They are pretty generous with the specs of the machines (for now at least), so that could explain why it's faster there.

[firai]

@jtpio I created a PR at #13239 to add the --collaborative flag.

They are pretty generous with the specs of the machines (for now at least), so that could explain why it's faster there.

It isn't just that the build is faster (which is nice as well); the build process seems to be more reliable from what I've seen. Binder builds are sometimes flaky for me and fail for no apparent reason. Perhaps this could be related to the resources that are available as well.

[jtpio]

As for codespaces - I do not think this will be compatible 1:1 but I can try something out.

With the end of the codespaces beta having a JupyterLab dev setup compatible with codespaces sounds more interesting now: https://github.blog/changelog/2022-11-09-codespaces-for-free-and-pro-accounts/