# jupyterlabdemo build failed on d.2018.07.10

XMLWordPrintable

#### Details

• Type: Bug
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
None
• Story Points:
1.5
• Team:
SQuaRE

#### Description

Last night's nightly build of jupyterlabdemo failed.

 /opt/lsst/software/stack/python/current/bin/python3: No module named ipykernel   The command '/bin/bash -lc /opt/lsst/software/stack/python/current/bin/python3 -m ipykernel install --name 'LSST'' returned a non-zero code: 1   Docker build failed. 

The timing is suspicious with the miniconda installer upgrade yesterday under DM-14011, which also switched newinstall.sh to installing scipipe deps into a named conda env instead of the default "base" env.

#### Activity

Hide

Is the right answer to switch my build stuff to use the named conda env, or to install packages explicitly into base in order to get the needed notebook extensions and stuff going?

Show
Adam Thornton added a comment - Is the right answer to switch my build stuff to use the named conda env, or to install packages explicitly into base in order to get the needed notebook extensions and stuff going?
Hide
Joshua Hoblitt added a comment - - edited

Well, I think it depends on what caused the failure. The console output looks like its not related to the scipipe conda install, so its possible it was unrelated. loadLSST.bash does the right thing auto-magically so the only way things could be going wrong [with the conda env] is if the scipipe conda install is being used without soucing loadLSST.bash.

Show
Joshua Hoblitt added a comment - - edited Well, I think it depends on what caused the failure. The console output looks like its not related to the scipipe conda install, so its possible it was unrelated. loadLSST.bash does the right thing auto-magically so the only way things could be going wrong [with the conda env] is if the scipipe conda install is being used without soucing loadLSST.bash .
Hide

In fact there were a number of places where I was just using the python binary from the stack without sourcing the whole environment. I fixed that and trimmed places where I was incorrectly/unnecessarily installing Jupyter components into the stack Python (which I don't need to do as Jupyter always runs in the external SCL Python).

I rebuilt and ran through a couple notebooks; it seems to be OK now.

Show
Adam Thornton added a comment - In fact there were a number of places where I was just using the python binary from the stack without sourcing the whole environment. I fixed that and trimmed places where I was incorrectly/unnecessarily installing Jupyter components into the stack Python (which I don't need to do as Jupyter always runs in the external SCL Python). I rebuilt and ran through a couple notebooks; it seems to be OK now.

#### People

Assignee:
Reporter:
Joshua Hoblitt
Watchers: