Fatal Python error: init_fs_encoding. Fresh Install, Win11, no venv

Python Help
1

I am running on Windows 11 with no virtual environment and a fresh installation, but no matter what I do, I’ve been plagued with this error.

Could not find platform independent libraries <prefix>
Python path configuration:
  PYTHONHOME = (not set)
  PYTHONPATH = (not set)
  program name = 'python'
  isolated = 0
  environment = 1
  user site = 1
  safe_path = 0
  import site = 1
  is in build tree = 0
  stdlib dir = 'C:\Users\jsgrazzutti\Lib'
  sys._base_executable = 'C:\\Users\\jsgrazzutti\\AppData\\Local\\Programs\\Python\\Python312\\python.exe'
  sys.base_prefix = 'C:\\Users\\jsgrazzutti'
  sys.base_exec_prefix = 'C:\\Users\\jsgrazzutti'
  sys.platlibdir = 'DLLs'
  sys.executable = 'C:\\Users\\jsgrazzutti\\AppData\\Local\\Programs\\Python\\Python312\\python.exe'
  sys.prefix = 'C:\\Users\\jsgrazzutti'
  sys.exec_prefix = 'C:\\Users\\jsgrazzutti'
  sys.path = [
    'C:\\Users\\jsgrazzutti\\AppData\\Local\\Programs\\Python\\Python312\\python312.zip',
    'C:\\Users\\jsgrazzutti',
    'C:\\Users\\jsgrazzutti\\Lib',
    'C:\\Users\\jsgrazzutti\\AppData\\Local\\Programs\\Python\\Python312',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x0000558c (most recent call first):
  <no Python frame>

Any help would be greatly appreciated, thanks in advance!

2

Your installation’s config is in a severely broken state. How did you install this python? Did you try removing (potentially manually) and reinstalling?

4

I installed through windows store, installed via the download on the website, read that’s a problem, uninstalled both, and reinstalled the website version.

Do I need to do something other than uninstall?

5

That should be enough, but clearly isn’t. I don’t know where python tries to get it’s config values from, someone else might be able to help you better there.

Although, one more question: How are you running python?

6

It is intended to run code, but it also isn’t working whenever I try to run “python” or “py” in either powershell or command line, it doesn’t work

7

Hm, I don’t really know how to help you here. I would suggest you open up an issue on the proper bug tracker which as much information as possible. There is this issue which encounters the same error message, however that is quite a different situation since it isn’t using the normal installers.

8

Okay, I still appreciate your insight. I was able to get a previous version of python working, but yeah the problem is persistent on the newest version of python

9

This error seems to come up quite often (well - rare compared to the total number of installations, but often enough to create traffic here and on Stack Overflow), but I’ve yet to see a reproducible example, or an analysis of exactly how such installations (are | become) broken.

10

All other examples I have seen from a quick search either involve PYTHONHOME being set to something (not the case here as can be seen from the posted output) or a manually build python (which isn’t the case unless we assume OP is lying), and OP says that a reinstall didn’t solve anything - Do you have further suggestions for what to purge? I don’t exactly want to suggest messing around in the registry, especially because I am not aware of any keys there that could lead to this.

11

I’m afraid not. But if OP’s described sequence of events consistently reproduces the problem - for reference:

  • install some Windows Store version of Python (which one?)
  • install an official python.org version (which one? maybe this is specific to certain combinations; or happens if they’re the same version; or happens if they’re different versions; or…)
  • uninstall both (in which order? does it matter?)
  • reinstall the same python.org version and attempt to use it

…and nothing else is needed, that seems like a major clue (and a reason for the dev team to talk to Microsoft again).

For what it’s worth, this seems to be the relevant documentation:

And to highlight the important parts from OP’s error dump:

Python needs to import the encodings standard library module at startup to bootstrap itself, but it doesn’t appear to be found in any of those paths in sys.path. I think this set of paths looks subtly wrong, but I don’t have easy access to Windows to check what it would normally default to.

12

Karl, I’m going to try to replicate this. The crux of the problem is that the startup initialization is mistakenly setting sys.prefix to “C:\Users\jsgrazzutti”. Off the top of my head, I don’t know why that would happen since PYTHONHOME isn’t set.

1 Like
13

My first attempt didn’t reproduce the problem. Starting fresh with no 3.12 installation on disk or in the registry, or any remnant of a past installation, I installed the store version of 3.12, followed by a current-user installation of 64-bit 3.12. I then removed them both and reinstalled 3.12 for the current user. There was no issue, other than the fact that uninstalling isn’t as clean as I’d like. (It leaves behind the installation directory and some registry entries, but nothing that should be a problem.)

14

I was able to reproduce this partly by renaming the standard library landmark “Lib\os.py” to “Lib\os.bak”, which emulates that the landmark file is missing. This causes the warning to be printed “Could not find platform independent libraries <prefix>”. In this case, sys.prefix gets set to the current working directory, which happens to be %USERPROFILE% in the given case. However, there should still be a default sys.path stored in the registry key “HKCU\Software\Python\PythonCore\3.12\PythonPath”. If for some reason that’s not available, then a hard-coded default sys.path is used, which is resolved relative to the incorrect sys.prefix, and recreates the issue exactly.

I suggest the following steps:

  1. Uninstall Python 3.12.
  2. Manually delete the installation directory “%LocalAppData%\Programs\Python\Python312”, if it exists.
  3. Manually delete the registry key “HKCU\Software\Python\PythonCore\3.12”, if it exists.
  4. Install Python 3.12 for the current user.
  5. Verify the existence of the file “%LocalAppData%\Programs\Python\Python312\Lib\os.py”.
  6. Verify the existence of the registry key “HKCU\Software\Python\PythonCore\3.12\PythonPath”.
2 Likes
15

As an update, I managed to reproduce the problem accidentally, by a completely different route:

  • Have an old venv lying around which uses the system Python as a base, but uses copies of the Python executable rather than symlinks (in my case, an old Poetry install script created this, even on Linux)
  • Update the OS, replacing the system Python with a newer version
  • Use the venv’s Python

In my case, this resulted in a sys.path which included '/usr/lib/python38.zip' , '/usr/lib/python3.8', and '/usr/lib/lib-dynload' - but none of those actually exist, since the system Python is now 3.10. (The zip file isn’t there normally, with this distro at least, but the point is that the folder is renamed as suits the new system Python installation.) So there was nothing left on sys.path that could have actually contained the standard library (and therefore the encodings module).

Also notable, sys.prefix was /usr, but sys.executable was the venv’s copied Python. (Maybe that’s normal when copies are used?)

(I ended up manually uninstalling Poetry, taking the entire venv with it - there was no clear path to uninstall something installed by a deprecated installation method, anyway.)

On the base Python, as well as on a fixed venv, sys.path contains '/usr/lib/python3.10/lib-dynload', so I suspect the '/usr/lib/lib-dynload' entry is just wrong - and the fact that it was created seems like an important clue. In OP’s case, I similarly see 'C:\\Users\\jsgrazzutti' and 'C:\\Users\\jsgrazzutti\\Lib' which both look quite wrong.