Publish two docker images - one with TigerVNC, and one with TurboVNC? about jupyter-remote-desktop-proxy HOT 7 CLOSED

The 2.0 change log points to:
https://quay.io/repository/jupyterhub/jupyter-remote-desktop-proxy?tab=tags
But I cannot access this -- requires a signin.
Are these images intended to be not-public?
It would be useful to be able to test-drive the project or use them as a base image for a custom solution.

from jupyter-remote-desktop-proxy.

They were intented to be public, and that was the mistake - they were private! They are now public though, thanks for pinging about this @psobolewskiPhD!

from jupyter-remote-desktop-proxy.

Thanks @consideRatio !
I was able to pull it down (using apptainer actually) and run my app on HPC via TigerVNC! More performant than I expected!

from jupyter-remote-desktop-proxy.

@yuvipanda wrote in #87 (comment):

If #88 is enough for you to consider #68 resolved I'm very happy for the approach described in #88 to go forward.

@manics what do you think?

from jupyter-remote-desktop-proxy.

Sounds fine to me!

I think it's worth deciding what the purpose of the images is though as this may affect how the Dockerfiles are designed. Are they production quality images that people should build on, or are they just examples for testing and development.

For example, in #77 (comment) there was a discussion about whether this should be an editable pip install or not (currently it is to optimise for development).

If it's not a production image, and therefore size isn't a concern, is it possible to install both vnc-servers and switch between them by changing the PATH or some other runtime argument? This also makes local testing easier.

from jupyter-remote-desktop-proxy.

@manics I primarily think of the image as we have it as purely for development, as actual end users want applications in their containers.

from jupyter-remote-desktop-proxy.

I think the image could reasonably serve a purpose of:

• development
• example/demo
• base-image for desktop application images

I see some benefit and downside of installing both in the same image, and currently lean towards providing two separate builds. I figure with two builds we avoid developing some logic to switch between vnc server binaries, and avoid bloating the tigervnc image with turbovnc or the other way around, and that any application installed on top should pick a specific VNC server suitable for the applications installed, where I think for example OpenGL related applications may want TurboVNC rather than TigerVNC.

from jupyter-remote-desktop-proxy.