Add a script to install tigervnc and remove tigervnc binaries from package

[cmd-ntrf]

After reading jupyterhub/traefik-proxy code, I got inspired and decided to try to tackle #27 and #56. So I copied the traefik install script from jupyterhub/traefik-proxy, and made a few adjustments to download from Sourceforge.

I am marking this as draft as it not completed, but it works on my machine.

Also note, that I found out that starting with tigervnc 1.11.0, the vncserver script has been moved from bin to libexec.

[github-actions]

👈 Launch a binder notebook on this branch for commit e792a05

I will automatically update this comment whenever this PR is modified

👈 Launch a binder notebook on this branch for commit f56655c

👈 Launch a binder notebook on this branch for commit ec5043b

👈 Launch a binder notebook on this branch for commit be8ec8e

👈 Launch a binder notebook on this branch for commit 6135bbe

👈 Launch a binder notebook on this branch for commit 04dff5d

👈 Launch a binder notebook on this branch for commit 315348d

[manics]

Can you add some docs to the README?

[manics]

Does the current version 1.13.0 work?

[cmd-ntrf]

I have yet tested with 1.13.0. Starting at 1.11.0, tigervnc has moved vncserver from bin to libexec.

I have updated the PR to add the ability for jupyter-remote-desktop-proxy to find vncserver in either bin, libexec or if in user's PATH.

[cmd-ntrf]

So far, I have been unable to start a desktop with tigervnc > 1.10.0. vncserver was not only moved from bin to libexec but also deeply modified to the point where in tigervnc 1.13.0 it only accepts a display number.

But there might be hope. The vncserver perl script only purpose is to craft an Xvnc command-line with arguments and call it. Therefore, I think it might be possible to skip calling vncserver and call Xvnc instead since we already in the "command-line crafting business" with jupyter-remote-desktop-proxy. This assumes that Xvnc arguments were pretty much the same between tigervnc 1.10.0 and 1.13.0, which might be a strong hypothesis.

[manics]

That's a pain, thanks for investigating. If it's easier then leave it as is, and we can come back to it in a future PR.

[cmd-ntrf]

I have added a list of valid choices for --tigervnc-version to avoid issue with users selecting anything above 1.10.1.

[cmd-ntrf]

Can you add some docs to the README?

I will gladly add some docs to the README, but I wanted to make sure first it was something we were interested in adding to jupyter-remote-desktop-proxy.

[manics]

I'm strongly in favour of having this. Bundling the binary VNCserver has several problems:

• the licence of this package doesn't match (we can't fully resolve Repository license is incorrect #27 with this PR because https://github.com/jupyterhub/jupyter-remote-desktop-proxy/blob/v1.2.1/jupyter_remote_desktop_proxy/share/web/noVNC-1.2.0/LICENSE.txt is MPL 2 so we should somehow indicate this, but it solves the main problem)
• the pypi wheel is noarch, but it bundles the Linux x64_64 VNC server

[yuvipanda]

YESSS 1000% THIS IS AWESOME. I also would be ok with just ripping out the bundle anyway and requiring users to install it themselves via apt. The reason the traefik proxy has the install script was at that time traefik wasn't really available from any repositories...

[consideRatio]

I also would be ok with just ripping out the bundle anyway and requiring users to install it themselves via apt.

I feel comfortable with removing special treatment for TigerVNC, but I'm hesitant to provide an install script because of the maintenance complexity long term without a deliberate decision to do so after evaluating pro/con for end users and long term maintenance. My understanding currently is that turbovnc is preferred, so why should we commit to helping install tigervnc specifically?

[manics]

@yuvipanda Earlier you said "I also would be ok with just ripping out the bundle anyway and requiring users to install it themselves via apt."

Is this still the case? If so I think this would be good to sort out before the next (major?) release so we can resolve all licensing issues. This PR conflicts with your recent PRs so if we're just deleting share/tigervnc and updating the README to state a VNCserver must be installed it'll be easier to do that in a new PR rather than rebasing this one.

[yuvipanda]

@manics yes, I think we should just rip it all out and just provide instructions for getting it from apt. We don't bundle xfce, we shouldn't bundle the vnc server either. I think we earlier did because the version from apt was too old, but I think that's not the case anymore.

[yuvipanda]

@manics just to keep things going, I suggest we:

• Merge Add a "Hub Control Panel" menu item if running inside a JupyterHub #79 and make a major bump release, so folks can test it out
• After that, remove tigervnc binaries in a different major version and make that release.

I know this makes it slower to resolve all the licensing issues, but I don't want to wait too long to get a release out and want to use the limited overall time we have more useful.

[cmd-ntrf]

I am going to close this PR. Thank you everyone for the productive discussion.

[yuvipanda]

Thank you very much for your work, @cmd-ntrf!