robotkernel binder build is broken about robotkernel HOT 8 CLOSED

Well, binder didn't work at all for a couple months there, due to cloud compute credits. Gotta love Other People's Computers, but hey, they're free!

from robotkernel.

Yeah, that's a new one.

We should see if we can get to a more minimal reproducer on e.g. a gist, as that might reveal at exactly which layer the issue is occurring, which might help find an upstream to lodge an issue. Also seeing a lot of really old pins in there: on the one side, hooray reproducibility, but on the other, it's can become somewhat impractical given the number of EOL things its pulling, as they might no longer have eyes on their compatibility windows and migrations: specifically looking at NodeJS, as it can impact the binary compatibility situation in negative ways.

One way to work around some of the is to do an off-line solve with e.g. conda-lock, and then initialize that in postBuild, which might allow more control at the expense of a fatter container layer (as environment.yml won't be cached separately).

from robotkernel.

@bollwyvl Thanks for help! I agree, it might be best to just use the latest known good versions before wasting time to fix issue nobody else has. Would you be able to help, or have a simple example for me to re-use?

I still don't do binder stuff daily, and therefore only upgrade versions when really necessary.

from robotkernel.

just wheel doesn't trigger the condition...

from robotkernel.

Digging into it further, it appears Something Special Happens in repo2docker when python is pinned... perhaps try with that pin commented out?

from robotkernel.

Or, if a pinned python is desirable, apparently specifying something that matches the upstream regex to force Something Special To Happen, e.g.

- python =3.9

However: one will then observe some pip errors with requests and urllib3... while of course it is possible to use pip: dependencies in environment.yml, some of these will do strange things in the presence of an existing not-quite-pip-install. Of those listed deps, only robotframework-faker is not present, which should soon be remedied.

At any rate: here's my WIP branch where i did some of this stuff (there was a fair amount of force pushed):

https://github.com/robots-from-jupyter/robotkernel/compare/master...bollwyvl:gh-145-binder?expand=1

One the up side: it finishes the build fairly quickly, and works on ovh.

On the downside:

• pulling seems to fail on ovh

2023-07-23T19:54:45Z [Normal] Pulling image "2lmrrh8f.gra7.container-registry.ovh.net/mybinder-builds/r2d-g5b5b759bollwyvl-2drobotkernel-df6a1b:e6aa31cd165d0b90b45a4325d1b0df08b99ad53c"
2023-07-23T19:55:05Z [Warning] Failed to pull image "2lmrrh8f.gra7.container-registry.ovh.net/mybinder-builds/r2d-g5b5b759bollwyvl-2drobotkernel-df6a1b:e6aa31cd165d0b90b45a4325d1b0df08b99ad53c": rpc error: code = Unknown desc = failed to pull and unpack image "2lmrrh8f.gra7.container-registry.ovh.net/mybinder-builds/r2d-g5b5b759bollwyvl-2drobotkernel-df6a1b:e6aa31cd165d0b90b45a4325d1b0df08b99ad53c": failed to copy: write /var/lib/containerd/io.containerd.content.v1.content/ingest/0c5a2137e3d74fbf4b9e7632a6f24fd50cf7d9ecf5c64d105f4e69086192dfd5/data: no space left on device

• pushing seems to fail on gesis:

 ---> eeff3ac1a354
{"aux": {"ID": "sha256:eeff3ac1a354aa6d90b9895a77a50ffd69523ad546653c5dae0e5ff11c594ba2"}}Successfully built eeff3ac1a354
Successfully tagged gesiscss/binder-r2d-g5b5b759-bollwyvl-2drobotkernel-df6a1b:e6aa31cd165d0b90b45a4325d1b0df08b99ad53c
Error during build: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out.

Some of the above issues have pushed me to try to do more lite demos... but kind of in a holding pattern until lite supports JupyterLab 4 to throw a lot of time at the ecosystem.

from robotkernel.

Wow. Thanks again. It looks like I should be able to continue from here.

And next I should go and look into JupyterLab changelog to learn about Lab4…

from robotkernel.

look into JupyterLab changelog to learn about Lab4…

With any luck at all, the kernel itself should be mostly shielded from the changes, many of which revolve around deprecation of the old, home-grown evented document model for things based on yjs.

Of more interest is that the dependency between notebook and jupyterlab is now flipped: Notebook 7 is built of JupyterLab components, with nary a jQuery to be found. This means jupyterlab_robotmode will have to upgrade to CodeMirror 6. There, it should be possible to port the "simple" mode state machine grammar, which is good, but it's still a bunch of work.

Rounding out the experience, jupyterlab-lsp is being updated to work with L4/N7. Included in that are some changes that will allow for jupyter-lsp to work in lite, though I've yet to get even a simple one working, much less a WASM-backed language server. But all very possible, given time!

from robotkernel.