Discussing inline documentation/inspect request for lite

[anutosh491]

I just came across this today

Scenario 1 :

We use the recommended method from jupyterlite-xeus to build xeus-cpp-lite (https://jupyterlite-xeus.readthedocs.io/en/latest/#usage)

As can be seen in path/to/jupyterlite-xeus/biuld/_output/xeus/kernel_packages we would have

anutosh491@Anutoshs-MacBook-Air kernel_packages % ls
cppinterop-1.6.0-h0246c62_2.tar.gz              emscripten-abi-3.1.73-h267e887_10.tar.gz        nlohmann_json-3.12.0-h2072262_0.tar.gz          xeus-cpp-0.6.0-h2072262_5.tar.gz

anutosh491@Anutoshs-MacBook-Air kernel_packages % tar -tzf xeus-cpp-0.6.0-*.tar.gz
etc/xeus-cpp/tags.d/stl.json
lib/cmake/xeus-cpp/xeus-cppConfig.cmake
lib/cmake/xeus-cpp/xeus-cppConfigVersion.cmake
share/jupyter/kernels/xcpp20/kernel.json
share/jupyter/kernels/xcpp20/logo-32x32.png
share/jupyter/kernels/xcpp20/logo-64x64.png
share/jupyter/kernels/xcpp20/logo-svg.svg
share/xeus-cpp/tagfiles/cppreference-doxygen-web.tag
conda-meta/xeus-cpp-0.6.0-h2072262_5.json

This makes sure the tagfiles are not being filtered out by empack.

Scenario 2 :

If we do a local build using xeus-cpp's docs, somewhere here path/to/xeus-cpp/build/_output/xeus/kernel_packages, we would only have tarballs for packages we use.

(xeus-lite-host) anutosh491@Anutoshs-MacBook-Air kernel_packages % ls
boost-cpp-1.87.0-h7a4561d_1.tar.gz              emscripten-abi-3.1.73-h267e887_10.tar.gz        python_abi-3.13.1-0_cp313.tar.gz                xtensor-0.26.0-h2072262_2.tar.gz
bzip2-1.0.8-h7223423_8.tar.gz                   llvm-20.1.4-h7b9d542_0.tar.gz                   symengine-0.14.0-h07d2894_3.tar.gz              xtl-0.8.0-h2072262_0.tar.gz
cpp-argparse-3.2-hc1ca833_1.tar.gz              nlohmann_json-3.12.0-h2072262_0.tar.gz          xeus-5.2.2-h2072262_0.tar.gz
cppinterop-1.6.0-h0246c62_2.tar.gz              openblas-0.3.26-he2bab3c_13.tar.gz              xeus-lite-3.2.0-h2072262_0.tar.gz
doctest-2.4.12-h2072262_0.tar.gz                pugixml-1.15-hc1ca833_0.tar.gz                  xsimd-13.2.0-py313h1913ddd_1.tar.gz

This means we won't have access to conda-meta/xeus-cpp-0.6.0-h2072262_5.json which empacks needs to understand what to pack.

This is the reason we have been preloading the tagfiles in our cmakelists.txt

xeus-cpp/CMakeLists.txt

Lines 442 to 443 in 98585e8

	PUBLIC "SHELL: --preload-file ${XEUS_CPP_DATA_DIR}@/share/xeus-cpp"
	PUBLIC "SHELL: --preload-file ${XEUS_CPP_CONF_DIR}@/etc/xeus-cpp"

This introduces inconsistency in the builds

1. xeus-cpp through emscripten-forge would use empack based mechanism for the inspect request
2. building locally would end up adding the tagfiles to xcpp.data which is loaded at runtime for making the tagfiles accessible.

[anutosh491]

If we want to stick to a single design everywhere

1. The build and install step would add the tagfile to the prefix (prefix/share and prefix/etc)
2. After which at all instances we use the empack based mechanism for accessing these files

i) This is already being done in the jupyterlite-xeus recommended builds
ii) But for the local builds, we stop preloading (and preloading kills the meaning of these files being in the prefix) and use the addition mounts feature that goes through empack https://jupyterlite-xeus.readthedocs.io/en/latest/files.html#extra-mount-points

[anutosh491]

Hence for 3rd party libs there are 2 ways to proceed

1. If library X provides the tagfiles, so that when we install them they end up in the prefix .... well and good
2. But if not, a user would

i) have to add the tagfiles to the prefix
ii) Mount them during the build (step 1 won't be enough)
iii) and only then they can be put to use

So hopefully if we're interested in xtensor's docs to work by default. They should provide the tagfiles during the build, so that getting xtensor in our prefix, gets the tagfiles too and empack would capture them.

[anutosh491]

once we talk through this, we can get the below PR in

Simple pr to get the docs started for inline docs (#303)

[anutosh491]

ccing @martinRenou with whom I discussed this to figure out what's going wrong !