during the last days i discovered that spyder doesn't work in my python 3.8 environment.
i set up a new python 3.8.2 env. in anaconda und then just installed spyder - spyder does start until a white screen, then hangs...
spyder works fine in py 3.7 envs at my system, but no spyder version works in py 3.8 envs (doesn't matter if i set up a new env. or upgrade from a working 3.7 env to 3.8).
this issue was already discussed at stackoverflow.com:
https://stackoverflow.com/questions/58557238/spyder-ide-fails-to-start-on-windows-10-with-python-3-8
that workaround didn't work for me.
is this issue know?
during the last days i discovered that spyder doesn't work in my python 3.8 environment.
Right, it doesn't work but it's not our fault but from our dependencies. If you want it working please use Anaconda or keep using 3.7 until all issues are fixed in the different packages we depend on.
ok.
what does that mean "If you want it working please use Anaconda"? i'm using Anaconda.
Sorry I though you were using pip. Supposedly Anaconda patched the problematic packages and Spyder should be working on Python 3.8 on Windows, but I haven't tested that, sorry.
i also thought it worked... (i already had py 3.8 env. with spyder for 4 month or so).
but within the last days (with that spyder 4.1.0 problem - you know there were some threads here) i set up some new py 3.8 env. and spyder never again worked. the only thing i get is a white screen after spyder starts (like described at the stackoverflow thread). i also did a complete new installation of anaconda (newest version from their website).
I can reproduce the issue using miniconda and the anaconda defaults channel:
Step to reproduce:
conda create -n spyder spyder
conda activate spyder
spyder
and spyder hang with a white screen.
conda list
# packages in environment at C:\ProgramData\Miniconda3\envs\spyder:
#
# Name Version Build Channel
alabaster 0.7.12 py_0
argh 0.26.2 py38_0
asn1crypto 1.3.0 py38_0
astroid 2.3.3 py38_0
atomicwrites 1.3.0 py_0
attrs 19.3.0 py_0
autopep8 1.4.4 py_0
babel 2.8.0 py_0
backcall 0.1.0 py38_0
bcrypt 3.1.7 py38he774522_0
bleach 3.1.0 py_0
ca-certificates 2020.1.1 0
certifi 2019.11.28 py38_1
cffi 1.14.0 py38h7a1dbc1_0
chardet 3.0.4 py38_1003
cloudpickle 1.3.0 py_0
colorama 0.4.3 py_0
cryptography 2.8 py38h7a1dbc1_0
decorator 4.4.2 py_0
defusedxml 0.6.0 py_0
diff-match-patch 20181111 py_0
docutils 0.16 py38_0
entrypoints 0.3 py38_0
flake8 3.7.9 py38_0
future 0.18.2 py38_0
icu 58.2 ha66f8fd_1
idna 2.9 py_1
imagesize 1.2.0 py_0
importlib_metadata 1.5.0 py38_0
intervaltree 3.0.2 py_0
ipykernel 5.1.4 py38h39e3cac_0
ipython 7.13.0 py38h5ca1d4c_0
ipython_genutils 0.2.0 py38_0
isort 4.3.21 py38_0
jedi 0.15.2 py38_0
jinja2 2.11.1 py_0
jpeg 9b hb83a4c4_2
jsonschema 3.2.0 py38_0
jupyter_client 6.1.0 py_0
jupyter_core 4.6.1 py38_0
keyring 21.1.0 py38_0
lazy-object-proxy 1.4.3 py38he774522_0
libpng 1.6.37 h2a8f88b_0
libsodium 1.0.16 h9d3ae62_0
libspatialindex 1.9.3 h33f27b4_0
markupsafe 1.1.1 py38he774522_0
mccabe 0.6.1 py38_1
mistune 0.8.4 py38he774522_1000
nbconvert 5.6.1 py38_0
nbformat 5.0.4 py_0
numpydoc 0.9.2 py_0
openssl 1.1.1e he774522_0
packaging 20.3 py_0
pandoc 2.2.3.2 0
pandocfilters 1.4.2 py38_1
paramiko 2.7.1 py_0
parso 0.5.2 py_0
pathtools 0.1.2 py_1
pexpect 4.8.0 py38_0
pickleshare 0.7.5 py38_1000
pip 20.0.2 py38_1
pluggy 0.13.1 py38_0
prompt-toolkit 3.0.4 py_0
prompt_toolkit 3.0.4 0
psutil 5.7.0 py38he774522_0
pycodestyle 2.5.0 py38_0
pycparser 2.20 py_0
pydocstyle 4.0.1 py_0
pyflakes 2.1.1 py38_0
pygments 2.6.1 py_0
pylint 2.4.4 py38_0
pynacl 1.3.0 py38h62dcd97_0
pyopenssl 19.1.0 py38_0
pyparsing 2.4.6 py_0
pyqt 5.9.2 py38ha925a31_4
pyrsistent 0.15.7 py38he774522_0
pysocks 1.7.1 py38_0
python 3.8.2 h5fd99cc_0
python-dateutil 2.8.1 py_0
python-jsonrpc-server 0.3.4 py_0
python-language-server 0.31.9 py38_0
pytz 2019.3 py_0
pywin32 227 py38he774522_1
pywin32-ctypes 0.2.0 py38_1000
pyyaml 5.3.1 py38he774522_0
pyzmq 18.1.1 py38ha925a31_0
qdarkstyle 2.8 py_0
qt 5.9.7 vc14h73c81de_0
qtawesome 0.7.0 py_0
qtconsole 4.7.2 py_0
qtpy 1.9.0 py_0
requests 2.23.0 py38_0
rope 0.16.0 py_0
rtree 0.9.3 py38h21ff451_0
setuptools 46.1.1 py38_0
sip 4.19.13 py38ha925a31_0
six 1.14.0 py38_0
snowballstemmer 2.0.0 py_0
sortedcontainers 2.1.0 py38_0
sphinx 2.4.4 py_0
sphinxcontrib-applehelp 1.0.2 py_0
sphinxcontrib-devhelp 1.0.2 py_0
sphinxcontrib-htmlhelp 1.0.3 py_0
sphinxcontrib-jsmath 1.0.1 py_0
sphinxcontrib-qthelp 1.0.3 py_0
sphinxcontrib-serializinghtml 1.1.4 py_0
spyder 4.1.1 py38_1
spyder-kernels 1.9.0 py38_0
sqlite 3.31.1 he774522_0
testpath 0.4.4 py_0
tornado 6.0.4 py38he774522_1
traitlets 4.3.3 py38_0
ujson 1.35 py38he774522_0
urllib3 1.25.8 py38_0
vc 14.1 h0510ff6_4
vs2015_runtime 14.16.27012 hf0eaf9b_1
watchdog 0.10.2 py38_0
wcwidth 0.1.8 py_0
webencodings 0.5.1 py38_1
wheel 0.34.2 py38_0
win_inet_pton 1.1.0 py38_0
wincertstore 0.2 py38_0
wrapt 1.12.1 py38he774522_1
yaml 0.1.7 hc54c509_2
yapf 0.28.0 py_0
zeromq 4.3.1 h33f27b4_3
zipp 2.2.0 py_0
zlib 1.2.11 h62dcd97_3
thanks, i thought this problem is not so common, since i didn't found much about it in the internet...
unfortunately this thread is already closed.
sooner or later a lot of people will switch to python 3.8 and will use spyder, so the problem has to be solved i hope :-)
I have been waiting for a fix for a few weeks now.
I use miniconda., and I did 'conda installed spyder'. Spyder hangs due to asyncio error reported on OP's linked stackoverflow page
If anaconda patched the problematic packages, the patch hasn't been pushed out.
Please report this error here:
https://github.com/ContinuumIO/anaconda-issues/issues/
We can't do anything about it.
Hi @ccordoba12. I spent a few minutes looking into this just now. I think this problem is nothing to do with the conda ecosystem (indeed, the initial reports from SO are based around non-conda Python versions).
I tested the change proposed in https://stackoverflow.com/a/58682830 for Tornado and it fixes this issue. For now it's back in your hands as to how this should be handled as I don't know enough about it to be honest!
Here are some references that may prove useful for that:
The actual issue: https://github.com/tornadoweb/tornado/issues/2608
The change to Python: https://bugs.python.org/issue37373
As it stands, no-one using any Python 3.8 on Windows can run Spyder, so it cannot be a conda ecosystem issue.
Cheers!
Oh I must say, when looking at this, that kite thing looks pretty fancy (I tried it on Linux), but I am somewhat concerned about it installing files in, for example, systemd
system directories. My distro (or me, explicitly) is the only thing that should ever do that IMHO.
.. reason being, it will cause the system package manager difficulty if it tries to also install kite.
As it stands, no-one using any Python 3.8 on Windows can run Spyder, so it cannot be a conda ecosystem issue.
Ok, thanks a lot Ray for taking the time to take a look at this! I thought you were already applying that patch and something else was failing.
I think we need to apply that patch in qtconsole because we don't use asyncio directly here. But we'll take a look at it in the next couple of weeks.
Oh I must say, when looking at this, that kite thing looks pretty fancy (I tried it on Linux)
Glad you like it!! We worked very hard with the Kite team to implement that for Spyder 4.
but I am somewhat concerned about it installing files in, for example, systemd system directories. My distro (or me, explicitly) is the only thing that should ever do that IMHO.
That's probably done to autostart Kite at the beginning. @metalogical, could you give us some details about why Kite needs to register as a service with systemd?
Hi @mingwandroid, Kite uses systemd
to auto update itself. We ship releases at least once a week so it's important to keep the Kite application up to date.
That said, you can always remove this service:
systemctl disable --user --now kite-updater.timer
If you want to manually update Kite, you can use the command:
~/.local/share/kite/current/kite-update update
Thanks for input @its-dhung!
We ship releases at least once a week so it's important to keep the Kite application up to date.
Is it not possible to install something for the user instead of system-wide? Or make the app contact Kite servers and then run kite-update update
at the user level?
Is it not possible to install something for the user instead of system-wide? Or make the app contact Kite servers and then run
kite-update update
at the user level?
This is actually what we do: we install a user systemd service (which is why you can disable it via systemd disable --user
).
The Kite app could call home itself, but this is less robust in the scenario that the app crashes or doesn't start at all, which is always a (small) risk that comes with very rapid iteration.
This is actually what we do: we install a user systemd service (which is why you can disable it via systemd disable --user).
Ok, I see. Then it's fine for me.
The Kite app could call home itself, but this is less robust in the scenario that the app crashes or doesn't start at all, which is always a (small) risk that comes with very rapid iteration.
Ok, I understand better your decision to use systemd now. Thanks @metalogical!
@dalthviz, please see if something like this PR https://github.com/jupyter/qtconsole/pull/406/files will help us to fix this problem.
That PR is not the right solution for us because we don't use qtconsoleapp.py
here. So the patching that that PR is doing needs to be applied in another place in the qtconsole codebase.
great, spyder 4.1.3 now works with python 3.8 on windows. thanks!
Thanks for the confirmation @manfred2020!
Most helpful comment
great, spyder 4.1.3 now works with python 3.8 on windows. thanks!