%mamba magic not working for xeus-cpp-lite (deployed on top of main)

[anutosh491]

Haven't explored this a lot (also not very well educated with the solution for implementing this just yet) .... but Sylvain and I were expecting this to work right off the bat.

We have 2 links (both present in the readme)

1. Built on top of xeus-cpp's main
   https://compiler-research.org/xeus-cpp/lab/index.html

2. Built using xeus-cpp from emscripten-forge (using template repo). Also link provided in the blog
   https://compiler-research.org/xeus-cpp-wasm/lab/index.html

[anutosh491]

The first one fails

The second one works succesfully

[anutosh491]

Do y'all know what might be going wrong here

cc @martinRenou @AnastasiaSliusar

Though the link provided in the blog works, would be good if we could fetch stuff on top of latest xeus-cpp (the deployment built through CI) to try out stuff like widgets etc

[AnastasiaSliusar]

Hello @anutosh491, thank you for opening the issue!

This error is raised by the rattler solver because it is impossible to solve with mount_0.tar.gz package by using default channels https://github.com/emscripten-forge/mambajs/blob/98d55cb51bbfb76995d8088c5df88dde3c69efc9/packages/mambajs/src/solver.ts#L10.

I believe the issue is related to the fact that we pass all installed packages (specs with their dependencies, where specs are packages from an env file or the current environment) to this solver and it cannot resolve them. mount_0.tar.gz * seems to come from empack_env_meta.json file, which includes all of environment packages. I will debug this issue to confirm. If it is related to what I mentioned above, then the fix is here jupyterlite/xeus#254 where we will pass only specs without dependencies to the rattler solver.

By the way, I could install eigen here https://compiler-research.org/xeus-cpp-wasm/lab/index.html

but I could not do this here https://compiler-research.org/xeus-cpp/lab/index.html

@anutosh491 what is difference between these links? I guess there is difference of initial packages in their empack_env_meta.json

[martinRenou]

Lol, I knew this would hit us some day. This is due to jupyterlite/xeus#237.

We should fix jupyterlite/xeus to not list the mount points as packages (today they are wrongfully listed as conda packages in the lock file).

[martinRenou]

We should close the issue here

[anutosh491]

what is difference between these links? I guess there is difference of initial packages in their empack_env_meta.json

The only difference here is

1. Link which works : Is built on top of the template library (https://github.com/jupyterlite/xeus-lite-demo) and fetched latest xeus-cpp 0.7.1 from emscripten-forge

2. Link which doesn't work : is basically using everything from emscripten-forge but building xeus-cpp on main and using it

So I guess yes its only xeus-cpp that's different here (empack_env_meta.json)

[anutosh491]

We should close the issue here

Ohh nice, so we have a solution already ? I see a linked PR

Shall close this if can give me the green light here (probably a thumbs up haha)

[martinRenou]

I mean it's not an issue with what xeus-cpp does, it's a bug in jupyterlite-xeus that's already tracked by the issue jupyterlite/xeus#237, so you can close it here.

[anutosh491]

Perfect. Thank you. Feel free to let me know if I can try it out on my end once the bug on jupyterlite/xeus has been addressed.