Jupyter lab failed to build #9698
Comments
|
Thanks for the comprehensive error report. Are you sure all of the source extensions are updated for jlab 3? |
|
Can you uninstall the source extensions, then install them one at a time to see which one might be causing issues (or is there still an error if you build with no source extensions)? |
Extension list from jupyterlab:
I will uninstall source extensions now and try |
|
It seems JupyterLab automatically executes |
|
Now that all source extensions are uninstalled (please check to make sure with |
Okay.
|
|
This is indeed puzzling, then. And just to check, |
|
FYI, here is the place in the webpack code that seems to be throwing the error: https://github.com/webpack/webpack/blob/89fcc43bdaa956efc2fa1b0dfed596386a8aeba9/lib/javascript/JavascriptModulesPlugin.js#L120 |
Executing
Thanks for the link. |
I also found that installing Node.js through official website also installs npm (which I have but |
No, not really in this case. yarn uses npm packages. |
|
Maybe this has to do with windows? Do you get this error with a clean fresh environment and install of just basic jupyterlab with no extensions (source or prebuilt)? |
Today I reinstalled python from zero, and every package was installed using pip ( I also pip-installed algorithmx, ipyturtle2 and pythreejs before doing lab build, but not their jupyterlab extensions. |
|
The same error here with a totally new virtual environment. Environment
Steps to reproducepython -m venv jupyterlab_test
jupyterlab_test\Scripts\activate.bat
python -m pip install --upgrade pip
pip install jupyterlab
jupyter lab buildError logAdditional informationThe result of The result of The result of The result of |
Yes, see #9698 (comment) |
|
This issue has been mentioned on Jupyter Community Forum. There might be relevant details there: https://discourse.jupyter.org/t/jupyterlab-html-webpack-plugin-type-error/7695/2 |
|
For what it's worth, I can build JupyterLab 3.0.6 in a clean conda environment on Windows 10, installed with miniconda and conda-forge packages Is it the windows pip package, for some reason? |
|
I just tried creating a fresh conda environment on Windows 10 with just Weird that it worked with the conda-forge package, but not with the pip package. |
Same experiment on macOS (conda install environment, pip install jupyterlab), and compiling worked, so it seems specific to windows... |
|
More experiments (I remove the application staging directory between experiments)
|
|
From the experiments, my current hypothesis is that there is a path or working directory issue going on, where creating the MiniCssExtractPlugin.loader from a directory outside the staging directory is somehow creating something using a different copy of the webpack compilation object.
|
|
As a test, @spindensity (or others) - can you try doing a cd into the jupyterlab application directory, staging subdirectory, then running |
Yes, it works, running |
Running
I hope it works for everyone with the webpack Compilation problem. |
|
I spent a lot of time over the last 24 hours diving into this, discussed this with various people about it, etc. I'm still really puzzled by it:
The current hypothesis is that somehow node/webpack is importing the same copy of some file twice (perhaps not caching the import?), and that is causing the mismatch (i.e., the compilation object created from one import is not an instanceof the compilation object in the second copy). It's not clear how this could be happening, though. To address the directory issue, we've tried making sure the build had the correct current working directory, but that did not seem to help. |
|
I found the problem: it is the case sensitivity of the filesystem and the case of the files. Node's require() caches modules based on their filename, case sensitive. In my case, I'm seeing two different imports of webpack: one is So it looks like the main program loads eventually |
|
Interesting, I have little to null experience in software development but reading through your comments makes me understand the situation at least in a basic level. Thanks for the clarification. |
|
Diving more into this, I'm looking at the case of the drive letter on Windows. I'm seeing that It seems that core Some experiments with subprocess suggest that launching an application with an uppercase drive letter should give an uppercase |
This fixes `jupyter lab build` on Windows when using pip. The underlying problem is in pip (from its dependency distlib) and how it normalizes paths to lowercase when it creates executables for Windows entry points (see https://bitbucket.org/pypa/distlib/issues/143/do-not-normcase-executable-path-when and pypa/pip#6582 (comment)). Basically, when we set the current working directory to a lower-case version of the path, node starts using the lower-case version for its module cache when building JupyterLab. However, the mini-css-extract plugin in JLab asks node to resolve a path for its loader, which uses the canonical case for the path. This leads to Node having two copies of the same modules in its cache (differentiated by the path case), which leads to problems when doing instanceof checks. See the exploration at jupyterlab#9698 for more details. Until the issue is fixed in distlib/pip, we can work around it by using realpath, which seems to give back a canonical name (including case) for a path. It’s possible that we should use realpath many more places in the code, but it seems that this change is minimal enough to at least get the windows build working, and I want to be conservative here. You can see the effect of this change by installing jupyterlab with (current) pip on Windows and running `jupyter lab path`. You’ll notice that the application directory is lowercase before this commit, but normal case after (e.g., the drive letter is uppercase, etc.).
Fixes jupyterlab#9698 This fixes `jupyter lab build` on Windows when using pip. The underlying problem is in pip (from its dependency distlib) and how it normalizes paths to lowercase when it creates executables for Windows entry points (see https://bitbucket.org/pypa/distlib/issues/143/do-not-normcase-executable-path-when and pypa/pip#6582 (comment)). Basically, when we set the current working directory to a lower-case version of the path, node starts using the lower-case version for its module cache when building JupyterLab. However, the mini-css-extract plugin in JLab asks node to resolve a path for its loader, which uses the canonical case for the path. This leads to Node having two copies of the same modules in its cache (differentiated by the path case), which leads to problems when doing instanceof checks. See the exploration at jupyterlab#9698 for more details. Until the issue is fixed in distlib/pip, we can work around it by using realpath, which seems to give back a canonical name (including case) for a path. It’s possible that we should use realpath many more places in the code, but it seems that this change is minimal enough to at least get the windows build working, and I want to be conservative here. You can see the effect of this change by installing jupyterlab with (current) pip on Windows and running `jupyter lab path`. You’ll notice that the application directory is lowercase before this commit, but normal case after (e.g., the drive letter is uppercase, etc.).
|
I think I found a workaround for the pip issue in #9709. |
Fixes jupyterlab#9698 This fixes `jupyter lab build` on Windows when using pip. The underlying problem is in pip (from its dependency distlib) and how it normalizes paths to lowercase when it creates executables for Windows entry points (see https://bitbucket.org/pypa/distlib/issues/143/do-not-normcase-executable-path-when and pypa/pip#6582 (comment)). Basically, when we set the current working directory to a lower-case version of the path, node starts using the lower-case version for its module cache when building JupyterLab. However, the mini-css-extract plugin in JLab asks node to resolve a path for its loader, which uses the canonical case for the path. This leads to Node having two copies of the same modules in its cache (differentiated by the path case), which leads to problems when doing instanceof checks. See the exploration at jupyterlab#9698 for more details. Until the issue is fixed in distlib/pip, we can work around it by using Path.resolve(), which seems to give back a canonical name (including case) for a path. It’s possible that we should use this many more places in the code, but it seems that this change is minimal enough to at least get the windows build working, and I want to be conservative here. We initially tried using os.path.realpath, and while that works on python 3.9, it does not correct case on python 3.6. You can see the effect of this change by installing jupyterlab with (current) pip on Windows and running `jupyter lab path`. You’ll notice that the application directory is lowercase before this commit, but normal case after (e.g., the drive letter is uppercase, etc.).
|
I can confirm that the fix in #9709 fixes the same error in the now-running Windows CI test. |
|
@jasongrout I tried everything mentioned in this thread, but I still get build fail. |
|
@callmesukhi, welcome to this issue! The first thing to determine is if you are having the problem that this issue is about (and if not, please open a new issue). Can you give us the information requested in the bug report issue template, like info about your version of JupyterLab, OS, etc., and why you think your issue is exactly the same as the issue we are discussing here? Then please tell us exactly what you've tried from this thread that doesn't seem to be working. Also, it might help to go through the troubleshooting/diagnosis guide in the documentation at https://jupyterlab.readthedocs.io/en/stable/getting_started/issue.html to try to narrow down the problem. |
|
Summarizing workarounds until JupyterLab 3.0.7 is published soon. Do one of the following:
|
|
Thank you @jasongrout for a workaround! Had a study participant try to install my JupyterLab extension on a windows machine last night and ran into this issue, completely halting the study 😢 . Came here from #9649 Running steps 1 and 2 above on a windows machine worked! |
|
Awesome, good to hear from you, Mary Beth! Glad it worked, and hopefully 3.0.7 will be out today or tomorrow to work around the pip/distlib bug and make things work. |
|
https://pypi.org/project/jupyterlab/3.0.7/ is now available |
|
And to follow-up on the pypi issue: the distlib fix for the underlying issue was made, and pypi put the fix in the queue for their 21.1 release, targeted for April 2021. The workaround in JLab 3.0.7 should make it just work right now, though. |
|
I tried steps 1 and 2 above on a windows, but I still fail to build. jupyter core : 4.7.0 (base) C:\Users\lenovo\miniconda3\share\jupyter\lab\staging>jlpm why webpack
(base) C:\Users\lenovo\miniconda3\share\jupyter\lab\staging>jlpm why webpack
Build failed. If you are building via the jupyter lab build --dev-build=False --minimize=False You can also disable these options for all JupyterLab builds by adding these c.LabBuildApp.minimize = False If you don't already have a jupyter --paths Explanation:
An error occured. [LabBuildApp] Building in C:\Users\lenovo\miniconda3\share\jupyter\lab [LabBuildApp] Yarn configuration loaded. [LabBuildApp] > node C:\Users\lenovo\miniconda3\lib\site-packages\jupyterlab\staging\yarn.js install --non-interactive [LabBuildApp] > node C:\Users\lenovo\miniconda3\lib\site-packages\jupyterlab\staging\yarn.js yarn-deduplicate -s fewer --fail [LabBuildApp] > node C:\Users\lenovo\miniconda3\lib\site-packages\jupyterlab\staging\yarn.js run build:prod:minimize [LabBuildApp] JupyterLab failed to build [LabBuildApp] File "C:\Users\lenovo\miniconda3\lib\site-packages\jupyterlab\debuglog.py", line 47, in debug_logging [LabBuildApp] File "C:\Users\lenovo\miniconda3\lib\site-packages\jupyterlab\labapp.py", line 166, in start [LabBuildApp] File "C:\Users\lenovo\miniconda3\lib\site-packages\jupyterlab\labapp.py", line 162, in start [LabBuildApp] File "C:\Users\lenovo\miniconda3\lib\site-packages\jupyterlab\commands.py", line 469, in build [LabBuildApp] File "C:\Users\lenovo\miniconda3\lib\site-packages\jupyterlab\commands.py", line 678, in build [LabBuildApp] RuntimeError: JupyterLab failed to build [LabBuildApp] Exiting application: JupyterLab |
|
@allenhutao please try upgrading JupyterLab to at least 3.0.7 to pick up the fix. |
i upgrade jupyterlab to 3.0.9,but it is still |
hi,i tried above,but it still |
|
3.0.7 is now published with the workaround, so it or a later JupyterLab should not show this bug. |
|
Seeing the comments, I have the same issues, but I don't seem to understand which close up solution. I'm working on jupyter 3.0.16 but I cannot even update jupyter lab and it doesn't even start properly. |
|
I have the same problem on JupyterLab 3.1.4. |
|
@gonzalezhomar @dsaad68 - this particular issue was fixed in JupyterLab 3.0.7. You may also have a build failure, but from a different underlying issue. Can you open a new issue with a report of what is failing for you? I suggest using the reporting guidelines to try to narrow down the problem first before opening an issue. |
Hey! Since I didn't understand the issue, I solved it by completely uninstalling anaconda distribution and reinstalling it. I believe it was a pip package and it's requirements the things that generate a different issue. |
github-actions
bot
added
the
status:resolved-locked
Description
Jupyter lab failed to build
Reproduce
When I open jupyter-lab, it asks for build:
Then I ran
jupyter lab buildand got:Content of log file:
Webpack-related problem
@jasongrout suggested the use of
jlpm why webpackto track the origin of the problem, hence, I ran that command inside thestagingsubdirectory of jupyterlab and obtained this:Expected behavior
A successful build was expected since webpack problem was corrected for jupyterlab 3.0.6 (#9651)
Context
Note
I am able to use JupyterLab prebuilt extensions normally. But since
jupyter lab buildfails, I cannot use the source extensions for JupyterLab.The text was updated successfully, but these errors were encountered: