Repository navigation
spyder settings location #1995
Description
I just installed the brand new WinPython64-3.14.3.0slim.exe alongside my older, WinPython64-3.13.7.0slim, and I can't for the life of me get the new version to read spyder's settings from the same location that the old version wrote them to, namely %USERPROFILE%\.spyder-py3.
I had made the old version registered and fixed (i.e. I ran wppm --register and wppm --fix), I undid that now (ran wppm --unregister and wppm --movable) and made the new one registered and fixed, and the registering worked, but the settings are still read from the local WPy64-3.14.3.0\settings directory. The two winpython.ini files under \settings\ are identical except for the new PYTHONIOENCODING line, and I changed nothing in them from the default. Running the new spyder.exe immediately creates the local settings files and such.
I tried changing winpython.ini, both by changing [inactive_environment_common] to [active_environment_common] and by just uncommenting USERPROFILE = %HOME% in the env.bat section (I did not run any batch files manually by the way), both result in Spyder starting as before with the local/portable settings but the iPython console within now throws an error:
Traceback (most recent call last):
File "C:\Users\redacted\Documents\Work\Progs\WPy64‑3.14.3.0\python\Lib\site‑packages\spyder\plugins\ipythonconsole\widgets\main_widget.py", line 1464, in _connect_new_client_to_kernel
kernel_spec.env = future.result()
^^^^^^^^^^^^^^^
File "C:\Users\redacted\Documents\Work\Progs\WPy64‑3.14.3.0\python\Lib\site‑packages\spyder\plugins\ipythonconsole\utils\kernelspec.py", line 275, in env
env_vars["tmp"] = GetShortPathName(env_vars["tmp"])
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
pywintypes.error: (2, 'GetShortPathNameW', 'The system cannot find the file specified.')
Changing SPYDER_CONFDIR = %HOME%\settings\.spyder-py3 to SPYDER_CONFDIR = %USERPROFILE%\.spyder-py3 did the trick, but why did the older version not require this change?
Speaking of winpython.ini, is this line correct?
## <?> changing this segment to [inactive_environment_common] makes this segment of lines active
Inactive (which is what it is by default) is active?
And while we're on the subject, I don't even understand the USERPROFILE = %HOME% line to begin with, %HOME% does not exist as an environment variable, so what is USERPROFILE being set to?
Activity
stonebig commentedon Apr 11, 2026
Having an issue with mssql-python is a bit of a shame...
... but Spyder Ipython console is particulary sensitive to any subtle detail of installation since the begining of times
This is typically where Anthropic "Mythos" not-free may be usefull find the root cause
stonebig commentedon Apr 11, 2026
Given this and the person other issue raised @spyder-ide/spyder/issues/25847, do you forsee the problem ?
Copilot finished thinking
Copilot said: I'll check both issues to understand the
I'll check both issues to understand the context and see if there's a connection.Yes, I can foresee the problem based on these two issues.
Both issues were raised by the same user (@RedAero) and they appear to be related to WinPython environment configuration interacting with Spyder's iPython console.
The issues reveal a pattern:
Issue #1995 (WinPython): The user upgraded to WinPython 3.14.3.0 and Spyder started reading settings from a local portable directory instead of %USERPROFILE%.spyder-py3. When they tried to fix it by modifying winpython.ini, the iPython console crashed with:
Code
pywintypes.error: (2, 'GetShortPathNameW', 'The system cannot find the file specified.')
This error occurs when trying to get the short path name of a temporary directory that doesn't exist.
Issue #25847 (Spyder): The user reported that importing mssql_python causes the iPython console to hang and crash in Spyder 6.1.3 with Python 3.14.3.0, while the same import works fine in IDLE, Jupyter, and raw iPython.
The likely connection: Both issues point to a problem with how the iPython kernel is being configured with environment variables (particularly temp directory paths) in WinPython's setup. The GetShortPathName error suggests that the kernel's environment is pointing to a non-existent or incorrectly configured temporary directory path. When certain packages like mssql_python are imported, they may trigger operations that depend on valid temporary directory paths, causing the kernel to crash.
The root cause likely lies in how WinPython configures the environment for the iPython kernel, particularly regarding the tmp environment variable and the overall SPYDER_CONFDIR settings.
stonebig commentedon Apr 12, 2026
also : https://stackoverflow.com/questions/79610838/pywin32-getshortpathname-cannot-find-a-path-which-certainly-exists
you shall print in file what is in env_vars["tmp"] , maybe it's more than 250 characters ?
as you're playing on a server, it can be also some tricky "rights"... only you can inquire from the error message.
I'm not sure WinPython is the problem, but in doubt, switch to anaconda, or a standard python
stonebig commentedon Apr 12, 2026
(gemini)
This error is a classic case of a script (likely Python using pywin32) trying to access a directory that doesn't actually exist on the file system, even though the environment variable pointing to it does.
On Windows Server 2019, here is why GetShortPathName is failing with "The system cannot find the file specified":
The most common cause is that the %TMP% or %TEMP% environment variable is pointing to a folder that was deleted or never created.
The Scenario: If you are running this via a Scheduled Task, WinRM, or a Service, Windows often looks for a user-specific temp folder (e.g., C:\Users\Username\AppData\Local\Temp\2).
The Fix: Manually verify if the path stored in env_vars["tmp"] actually exists. If it doesn't, the API call will fail because there is no file/folder to generate a short name for.
Windows Server 2019 often uses Session-specific temp folders.
When you log in via RDP, Windows might create a temporary folder labeled with your session ID (e.g., ...\Temp\1).
If a process persists after you log out, or if it tries to access a session-specific path that has been cleaned up by the system, you will get this error.
The Fix: Check the Registry setting: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server. If PerSessionTempDir is set to 1, Windows creates these "numbered" folders.
GetShortPathName relies on 8.3 filename creation (the old PROGRA~1 style).
On many modern Windows Server deployments, 8.3 name creation is disabled by default on data volumes to improve performance.
While this usually returns the long path instead of failing, if the underlying directory is missing and the volume doesn't support short names, the API can behave unpredictably.
The Fix: Check your settings using:
fsutil 8dot3name query C:
If the account running the script (e.g., LocalService or NetworkService) does not have List Folder / Read permissions for the parent directory of the temp folder, it may report "File Not Found" because it isn't allowed to "see" that the path exists.
Quick Debugging Steps
Print the path: Before the failing line, add print(env_vars["tmp"]).
Verify Existence: Run os.path.exists(env_vars["tmp"]) in your script.
The "Safety" Workaround: If you don't strictly need the short path (which was mostly used to avoid spaces in paths for older CLI tools), you can wrap it in a try-except block:
Python
import os
import win32api
tmp_path = env_vars["tmp"]
try:
short_path = win32api.GetShortPathName(tmp_path)
except pywintypes.error:
# If it fails, ensure the directory exists first
if not os.path.exists(tmp_path):
os.makedirs(tmp_path)
short_path = tmp_path # Fallback to long path
stonebig commentedon Apr 12, 2026
your working WinPythonslim-64bit-3.13.7.0 is using Spyder-6.0.7, and the new one is using Spyder-6.0.3.
there were some changes: (gemini)
was there any possible link with the fact the user has a SPyder-6.0.4 workingversion and the non working one is Spyder 6.1.3 ?
Yes, there is a very high probability that the jump from Spyder 6.0.4 to 6.1.3 is the direct cause of this error.
The error pywintypes.error: (2, 'GetShortPathNameW', 'The system cannot find the file specified.') usually occurs during the initialization of the IPython Console or the LSP (Language Server Protocol).
Here is why the version change likely triggered this on your Windows Server 2019:
Spyder 6.1.x introduced updates to spyder-kernels (v3.1.3+) and qtconsole. Between 6.0.4 and 6.1.3, there were specific code changes in how Spyder handles environment variables and working directories.
The Change: 6.1.3 includes more aggressive "normalization" of paths to ensure compatibility with various Python environments.
The Failure: It calls GetShortPathNameW to handle spaces in Windows paths (like C:\Program Files...). If the temporary directory defined in your server's environment variables (%TEMP%) does not physically exist, 6.0.4 might have ignored it or used a fallback, whereas 6.1.3 strictly expects the path to be valid to perform the conversion.
A known issue specifically tracked for the Spyder 6.1.x cycle involves Windows usernames that contain spaces.
If your Windows Server user is "Admin User" or "Service Account", Spyder 6.1.3 tries to generate a short path (e.g., ADMINI~1) to avoid shell execution errors.
If the system cannot resolve this path (often due to 8.3 naming being disabled on Server 2019 volumes), the GetShortPathNameW call crashes the kernel startup.
On Windows Server 2019, remote sessions (RDP) often use Session IDs in the temp path (e.g., Temp\2).
Spyder 6.0.4: Likely cached a static path or had a more lenient check.
Spyder 6.1.3: If it tries to validate or "shorten" a session-based temp path that was purged or is currently locked by another process, it throws the (2, 'The system cannot find the file specified') error.
How to Fix It (The "Spyder 6.1.3" Way)
Force Create the Temp Dir:
Open a PowerShell window on the server and run:
PowerShell
if (!(Test-Path $env:TEMP)) { New-Item -ItemType Directory -Path $env:TEMP }
Even if it looks like it exists, sometimes the internal variable points to a numbered subfolder that doesn't.
Update spyder-kernels:
Ensure the environment you are trying to run has the exact version required for 6.1.3. In your terminal/Anaconda prompt:
Bash
conda install spyder-kernels=3.1.3
OR if using pip
pip install spyder-kernels==3.1.3
Reset Spyder Settings:
Since you upgraded versions, old configuration files might be passing an invalid wdir (working directory) to the new API. Run this in a command prompt:
Bash
spyder --reset
Check 8.3 Support:
If your server has "Short Names" disabled, Spyder's attempt to call that Windows function will fail. You can check this by running fsutil 8dot3name query C: in an Admin command prompt. If it's disabled (1), Spyder 6.1.3 may struggle more than 6.0.4 did.
stonebig commentedon Apr 12, 2026
This are the interesting part:
and
and in remedies, there is
stonebig commentedon Apr 12, 2026
there are bugs resolved in spyder-kernels-3.1.4, when you have spyder-kernels-3.1.3