Missing vendor file node_modules/backbone.paginator/lib/backbone.paginator.js

[rgraber]

NOTE: The documentation of the workaround has been moved to #1088. This ticket is now just for the technical resolution of the issue.

make dev.provision results in "Missing vendor file node_modules/backbone.paginator/lib/backbone.paginator.js"

[ashultz0]

I think @rijuma saw this several times provisioning mid week but it eventually worked after nuking volumes and running again so it may not be an always error 😱

[jmbowman]

This has definitely surfaced in the past, but usually with an unsatisfying resolution:

• https://openedx.slack.com/archives/C12M8M5AR/p1667996792545799
• https://openedx.slack.com/archives/C02SNA1U4/p1602785109116800
• https://openedx.slack.com/archives/C08B4LZEZ/p1598623124019600

[rijuma]

I can't say if this was exactly the same case as mine mentioned by @ashultz0. On my case pyenv was not correctly setup to run the correct version by default (v3.8.16), and running the provisioning corrupted some container setups.

In order to fix my issue, I had to add eval "$(pyenv init -)" before the virtualenvwrapper.sh script. My final .bashrc had these lines:

# ~/.bashrc

eval "$(pyenv init -)"
source /usr/local/bin/virtualenvwrapper.sh

After that, I double checked that the proper python version was the default on pyenv on a fresh terminal start:

➜  ~ python -V
Python 3.8.16

Then removed all related containers and volumes from docker so the provisioning would start from scratch.
After that, provision went smoothly.

[dianakhuang]

Seems like this is possibly also a manifestation of M1/Silicon issues.

Edit: we have also received word that this is happening on hosted devstack as well.

[dianakhuang]

On hosted devstack, we managed to fix this issue with an npm ci and then a run of paver update_assets inside the container's shell. This may or may not work for folks on Apple Silicon machines.

This might be something that we want/could be run when folks run into this. Maybe provisioning fails? https://github.com/openedx/devstack/blob/master/provision-lms.sh#L80-L81

[jmbowman]

Some suggestions for diagnosing:

• Does this happen if the user doesn't update their docker CPU/RAM/disk image setting as recommended in https://edx.readthedocs.io/projects/open-edx-devstack/en/latest/getting_started.html#prerequisites ? People often fail to notice that step, and an NPM failure due to insufficient RAM might leave devstack in a bad state even if they later find that section and update their settings.
• It feels like the most likely underlying causes of this are either "NPM didn't successfully complete" or "copying installed NPM packages to the vendored JS directory failed". Can we put better error handling in these steps to catch the root cause when it happens rather than blowing up downstream in the provisioning process like this?
• backbone.paginator hasn't been updated in 5 years. Should we just vendor it in for real, and see if that shifts the error message in any useful way?

[robrap]

Not sure if this is a separate issue, but it may be that that the hash caching that we use to avoid doing npm related install can get into a bad state? Provisioning seems to clear it: https://github.com/openedx/devstack/blob/master/provision-lms.sh#L80-L81, but paver install_prereqs may not update when it should.

[nsprenkle]

I have been able to work around this in the past by manually installing backbone.paginator, backbone, and a few others. Not a good developer experience, but I have been able to get around it before.

Am on an M1 Mac running Devstack.