Kernel is dead message when starting Spyder

dalthviz commented 3 months ago

Description

What steps will reproduce the problem?

Error triggered while testing macOS installer build as part of the Spyder 6 beta2 release (rc0). The error shows up after Spyder starts when the installation process finishes

Traceback

Traceback (most recent call last):
  File "/Users/daniel/Library/spyder-6/envs/spyder-runtime/lib/python3.11/site-packages/spyder/plugins/ipythonconsole/widgets/status.py", line 106, in <lambda>
    lambda sw=shellwidget: self.on_kernel_start(sw)
                           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/daniel/Library/spyder-6/envs/spyder-runtime/lib/python3.11/site-packages/spyder/plugins/ipythonconsole/widgets/status.py", line 136, in on_kernel_start
    mpl_backend = shellwidget.get_matplotlib_backend()
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/daniel/Library/spyder-6/envs/spyder-runtime/lib/python3.11/site-packages/spyder/plugins/ipythonconsole/widgets/shell.py", line 734, in get_matplotlib_backend
    blocking=True).get_matplotlib_backend()
                   ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/daniel/Library/spyder-6/envs/spyder-runtime/lib/python3.11/site-packages/spyder_kernels/comms/commbase.py", line 610, in __call__
    self._comms_wrapper._send_call(call_dict, self._comm_id, buffers)
  File "/Users/daniel/Library/spyder-6/envs/spyder-runtime/lib/python3.11/site-packages/spyder/plugins/ipythonconsole/comms/kernelcomm.py", line 146, in _send_call
    raise RuntimeError("Kernel is dead")
RuntimeError: Kernel is dead

Versions

Spyder version: 6.0.0b2.dev174 (standalone)
Python version: 3.11.9 64-bit
Qt version: 5.15.8
PyQt5 version: 5.15.9
Operating System: macOS-11.6.8-x86_64-i386-64bit

Dependencies

# Mandatory:
aiohttp >=3.9.3                   :  3.9.5 (OK)
asyncssh >=2.0.0,<3.0.0           :  2.14.1 (OK)
atomicwrites >=1.2.0              :  1.4.1 (OK)
chardet >=2.0.0                   :  5.2.0 (OK)
cloudpickle >=0.5.0               :  3.0.0 (OK)
cookiecutter >=1.6.0              :  2.6.0 (OK)
diff_match_patch >=20181111       :  20230430 (OK)
github >=2.3.0                    :  2.3.0 (OK)
intervaltree >=3.0.2              :  3.1.0 (OK)
IPython >=8.13.0,<9.0.0,!=8.17.1  :  8.25.0 (OK)
jedi >=0.17.2,<0.20.0             :  0.19.1 (OK)
jellyfish >=0.7                   :  1.0.4 (OK)
jsonschema >=3.2.0                :  4.22.0 (OK)
keyring >=17.0.0                  :  25.2.1 (OK)
nbconvert >=4.0                   :  7.16.4 (OK)
numpydoc >=0.6.0                  :  1.7.0 (OK)
parso >=0.7.0,<0.9.0              :  0.8.4 (OK)
pexpect >=4.4.0                   :  4.9.0 (OK)
pickleshare >=0.4                 :  0.7.5 (OK)
psutil >=5.3                      :  5.9.8 (OK)
pygments >=2.0                    :  2.18.0 (OK)
pylint >=3.1,<4                   :  3.2.3 (OK)
pylint_venv >=3.0.2               :  3.0.3 (OK)
pyls_spyder >=0.4.0               :  0.4.0 (OK)
pylsp >=1.11.0,<1.12.0            :  1.11.0 (OK)
pylsp_black >=2.0.0,<3.0.0        :  2.0.0 (OK)
pyuca >=1.2                       :  1.2 (OK)
qdarkstyle >=3.2.0,<3.3.0         :  3.2.3 (OK)
qstylizer >=0.2.2                 :  0.2.3 (OK)
qtawesome >=1.3.1,<1.4.0          :  1.3.1 (OK)
qtconsole >=5.5.1,<5.6.0          :  5.5.2 (OK)
qtpy >=2.4.0                      :  2.4.1 (OK)
rtree >=0.9.7                     :  1.2.0 (OK)
setuptools >=49.6.0               :  70.0.0 (OK)
sphinx >=0.6.6                    :  7.3.7 (OK)
spyder_kernels >=3.0.0b7,<3.0.0b8 :  3.0.0b7 (OK)
superqt >=0.6.2,<1.0.0            :  0.6.7 (OK)
textdistance >=4.2.0              :  4.6.2 (OK)
three_merge >=0.1.1               :  0.1.1 (OK)
watchdog >=0.10.3                 :  4.0.1 (OK)
yarl >=1.9.4                      :  1.9.4 (OK)
zmq >=24.0.0                      :  26.0.3 (OK)

# Optional:
cython >=0.21                     :  3.0.10 (OK)
matplotlib >=3.0.0                :  3.8.4 (OK)
numpy >=1.7                       :  2.0.0 (OK)
pandas >=1.1.1                    :  2.2.2 (OK)
scipy >=0.17.0                    :  1.13.1 (OK)
sympy >=0.7.3                     :  1.12.1 (OK)

ccordoba12 commented 3 months ago

Operating System: macOS-11.6.8-x86_64-i386-64bit

I see that you're using Mac 11, but the installers require Mac 12 or newer now. So, this could be the cause of the error.

Let me check on my VM (which has Mac 14) to see what I find.

dalthviz commented 3 months ago

Could it be worthy to somehow validate the OS version and prevent installing from the installer if it is not supported?

ccordoba12 commented 3 months ago

Could it be worthy to somehow validate the OS version and prevent installing from the installer if it is not supported?

Good idea but I don't know if that's possible. @mrclary, what do you think?

mrclary commented 3 months ago

I think this is possible. Either using our pre-install.sh script which is run by constructor at install time, or using __osx>=12 virtual package in the base environment specs. I'll test them to see what happens.

mrclary commented 3 months ago

Hmm... Well, __osx>=12 in the base environment specs did not seem to do anything. Using pre-install.sh to check macOS version successfully aborts the install process.

@jaimergp, do you know if there is a more elegant way for constructor to verify os version at the beginning of the install process?

mrclary commented 3 months ago

Two issues with using pre-install.sh:

The script does not raise the error until after packages are already unzipped, i.e. there is some install time (and cleanup) before the user is made aware of any error. Ideally, the os version should be checked at the same time that the install location is checked, avoiding unnecessary install actions.
The user is alerted to an error but not the reason for the error. The reason can only be determined by inspecting the install.log.

jaimergp commented 3 months ago

Well, __osx>=12 in the base environment specs did not seem to do anything.

That's because the solver runs on the build machine, not the target installation machine.

That said we should detect that and add it as a check at installation time, but right now we don't have that logic.

Also, I think the PKG installers have a way to check this natively, so maybe you can hack something together while we come up with something on the constructor side.

jaimergp commented 3 months ago

Giving it a try at https://github.com/conda/constructor/pull/809

jaimergp commented 1 month ago

Just reporting that as of constructor 3.9.3 and conda-standalone 24.7.1 this feature is supported via virtual_specs. See https://github.com/conda-forge/miniforge/pull/626 for inspiration.

spyder-ide / spyder