Providing the required node version in a conda environment doesn't work

[jorisvandenbossche]

Somewhat related to #6: I tried out the workflow of using a conda environment, and installing the exact required version of node in that environment (in the idea that the conda-provided node would be detected as matching "system" node, and thus used by sphinx-theme-builder / nodeenv). But it seems this is not fully working.

docs-theme2 is a conda env in which I installed the exact node version that is required (+ all dependencies to build the demo docs + sphinx-theme-builder):

(docs-theme2) ~/pydata-sphinx-theme$ stb serve docs/
[stb] Invoking sphinx-autobuild to run.
[sphinx-autobuild] pre-build
[sphinx-autobuild] > /home/joris/miniconda3/envs/docs-theme2/bin/python3.9 -m sphinx_theme_builder compile
[stb] # nodeenv does not exist.
[stb] # Generating new nodeenv with NodeJS 14.17.4!
[stb] # Will use system nodeJS, since version matches.
[stb] $ python -m nodeenv --node=system /home/joris/scipy/repos/pydata-sphinx-theme/.nodeenv
[stb] (nodeenv) $ node --version
v10.19.0
error: nodeenv-version-mismatch

× The `nodeenv` for this project is unhealthy.
╰─> There is a mismatch between what is present in the environment (v10.19.0) and the expected version of NodeJS (v14.17.4).

hint: Deleting the .nodeenv directory and trying again may work.

Link: https://sphinx-theme-builder.rtfd.io/errors/#nodeenv-version-mismatch
Command exited with exit code: 3

So it detects that the conda installed node version is matching the required version, but then nodeenv links to the actual system provided one (apparently I have a system wide node with version 10.19.0), and not the conda provided node. Resulting in a "broken" workflow. This might also be an issue to open with nodeenv.

Note: I am not sure how useful it is to actually try this (I am personally happy with the workflow to let nodeenv manage the node installation), but it would be good to know if this could work or will never work, to ensure we can document this for people using conda (and potentially having node installed in their environment)
(note: I personally don't want to use this workflow myself (I am happy with the node that nodeenv installs), but some users might want to

[pradyunsg]

@jorisvandenbossche What OS are you on? I'm guessing this is a Linux environment?

@kapooramit I'll respond over on pradyunsg/furo#330.

[jorisvandenbossche]

Yes, Linux (Ubuntu 20.04)

[pradyunsg]

I've made a bunch of changes to how the nodeenv handling works in https://github.com/pradyunsg/sphinx-theme-builder/compare/818d231c406ce98f02952025ea1c03ba80d6fa24..32377e2ad7179b430b8fb3ae65950d962cf8d21a

1. Windows does not support system nodeenv (that's a nodeenv limitation)
2. This will now use a dedicated isolated nodeenv, unless a specific environment variable is set.
3. Explicitly mention that we're using the "prebuilt" binaries.

That should make this less painful (it won't try + fail to use the conda node) but does not solve the underlying issue here; which I haven't been able to figure out.

[pradyunsg]

Released the above changes in 0.2.0a13!

[bollwyvl]

yeah, to package pydata/pydata-sphinx-theme#562 we'll need to figure out how to build this package for conda-forge and not have it randomly install an extra version of node. other downstreams that can provide node will have similar challenges.

another option would be to emulate flit and continue to pragmatically support building legacy-compatible sdist packages that contain the built JS/CSS and a generated setup.py/setup.cfg, and put off having to package this until it's ready to go (#11).

[pradyunsg]

You can set STB_USE_SYSTEM_NODE=true in the environment, and it'll use the system node install. It does require that the exact node version be available.

[pradyunsg]

Given that Furo is in the conda-forge feedstock, I think things work just fine with STB_USE_SYSTEM_NODE.