python-poetry
poetry commands suddenly stopped working (probably because of global python update)
Description
Hi! I have a global python 3.13 installation that I installed through a software installation and updates tool provided by the IT department of my workplace. The virtual environments I have created using Poetry were based on that python installation. Navigating to one of my python projects (either in cmd or powershell, I've tested both), I could until very recently run any Poetry command without error. Today, any command except poetry about fails with
Command ['C:\\Users\\<my_user>\\AppData\\Local\\pypoetry\\Cache\\virtualenvs\\<my-project-name>-<some-poetry-generated-string>-py3.13\\Scripts\\python.exe', '-I', '-W', 'ignore', '-c', 'import sys\n\nif hasattr(sys, "real_prefix"):\n print(sys.real_prefix)\nelif hasattr(sys, "base_prefix"):\n print(sys.base_prefix)\nelse:\n print(sys.prefix)\n'] errored with the following return code 1
Error output:
Traceback (most recent call last):
File "C:\Program Files\Python313\Lib\linecache.py", line 228, in _register_code
for const in code.co_consts:
^^^^^^^^^^^^^^
AttributeError: 'str' object has no attribute 'co_consts'
I think what changed since yesterday is that there was an automatic update of my global python installation from 3.13.2 to 3.13.3. This seems in line with the selected interpreter name shown in my editor (VS Code) in the bottom right corner, which shows
3.13.2 ('<my-project-name>-<some-poetry-generated-string>-py3.13')
and the output I get from running python in a terminal:
Python 3.13.3 (tags/v3.13.3:6280bb5, Apr 8 2025, 14:47:33) [MSC v.1943 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information.
Poetry documentation states that
[...] you can use the env use command to tell Poetry which Python version to use for the current project.
so I tried to use that command to reset the base python path, but also that command fails with the above error. Trying to use poetry to delete the virtual environment also failed with the same error.
I sorted it out by simply navigating to the poetry virtualenvs folder and deleting the whole virtual environment folder (without using Poetry -- I just used the file explorer), and then I could use poetry install to (re)create the environment.
If Poetry is designed to handle such changes to a base installation, I believe this is indeed a bug report. In any case I think a more explanatory error message would be helpful for anyone else running into this, so if this shouldn't be a bug report, maybe it could be a feature request.
PS: I used Poetry 2.1.1 when I encountered the issue. Since then I've tried updating to 2.1.2, but the issue is still present.
Workarounds
Not letting anyone make changes to your python base installation(s) would prevent the issue.
Poetry Installation Method
Windows Powershell: (Invoke-WebRequest -Uri https://install.python-poetry.org -UseBasicParsing).Content | py -
Operating System
Windows 10
Poetry Version
Poetry (version 2.1.2)
Poetry Configuration
cache-dir = "C:\\Users\\<my-user>\\AppData\\Local\\pypoetry\\Cache"
data-dir = "C:\\Users\\<my-user>\\AppData\\Roaming\\pypoetry"
installer.max-workers = null
installer.no-binary = null
installer.only-binary = null
installer.parallel = true
installer.re-resolve = true
keyring.enabled = true
python.installation-dir = "{data-dir}\\python" # C:\Users\<my-user>\AppData\Roaming\pypoetry\python
requests.max-retries = 0
solver.lazy-wheel = true
system-git-client = false
virtualenvs.create = true
virtualenvs.in-project = null
virtualenvs.options.always-copy = false
virtualenvs.options.no-pip = false
virtualenvs.options.system-site-packages = false
virtualenvs.path = "{cache-dir}\\virtualenvs" # C:\Users\<my-user>\AppData\Local\pypoetry\Cache\virtualenvs
virtualenvs.prompt = "{project_name}-py{python_version}"
virtualenvs.use-poetry-python = false
Python Sysconfig
sysconfig.log
Platform: "win-amd64"
Python version: "3.13"
Current installation scheme: "nt"
Paths:
data = "C:\Program Files\Python313"
include = "C:\Program Files\Python313\Include"
platinclude = "C:\Program Files\Python313\Include"
platlib = "C:\Program Files\Python313\Lib\site-packages"
platstdlib = "C:\Program Files\Python313\Lib"
purelib = "C:\Program Files\Python313\Lib\site-packages"
scripts = "C:\Program Files\Python313\Scripts"
stdlib = "C:\Program Files\Python313\Lib"
Variables:
BINDIR = "C:\Program Files\Python313"
BINLIBDEST = "C:\Program Files\Python313\Lib"
EXE = ".exe"
EXT_SUFFIX = ".cp313-win_amd64.pyd"
INCLUDEPY = "C:\Program Files\Python313\Include"
LDLIBRARY = "python313.dll"
LIBDEST = "C:\Program Files\Python313\Lib"
LIBDIR = "C:\Program Files\Python313\libs"
LIBRARY = "python313.dll"
Py_GIL_DISABLED = "0"
SOABI = "cp313-win_amd64"
TZPATH = ""
VERSION = "313"
VPATH = "..\.."
abi_thread = ""
abiflags = ""
base = "C:\Program Files\Python313"
exec_prefix = "C:\Program Files\Python313"
implementation = "Python"
implementation_lower = "python"
installed_base = "C:\Program Files\Python313"
installed_platbase = "C:\Program Files\Python313"
platbase = "C:\Program Files\Python313"
platlibdir = "DLLs"
prefix = "C:\Program Files\Python313"
projectbase = "C:\Program Files\Python313"
py_version = "3.13.3"
py_version_nodot = "313"
py_version_nodot_plat = "313"
py_version_short = "3.13"
srcdir = "C:\Program Files\Python313"
userbase = "C:\Users\<my-user>\AppData\Roaming\Python"
Example pyproject.toml
Poetry Runtime Logs
poetry-runtime.log
PS C:\Users\<my-user>\Documents\<my-project>> poetry -vvv env info
Loading configuration file C:\Users\<my-user>\AppData\Roaming\pypoetry\config.toml
Stack trace:
2 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\utils\env\base_env.py:430 in _run
428│ else:
429│ encoding = "locale" if sys.version_info >= (3, 10) else None
→ 430│ output = subprocess.check_output(
431│ cmd, stderr=stderr, env=env, text=True, encoding=encoding, **kwargs
432│ )
1 C:\Program Files\Python313\Lib\subprocess.py:472 in check_output
470│ kwargs['input'] = empty
471│
→ 472│ return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
473│ **kwargs).stdout
474│
CalledProcessError
Command '['C:\\Users\\<my-user>\\AppData\\Local\\pypoetry\\Cache\\virtualenvs\\<my-project>-<some-poetry-generated-string>-py3.13\\Scripts\\python.exe', '-I', '-W', 'ignore', '-c', 'import sys\n\nif hasattr(sys, "real_prefix"):\n print(sys.real_prefix)\nelif hasattr(sys, "base_prefix"):\n print(sys.base_prefix)\nelse:\n print(sys.prefix)\n']' returned non-zero exit status 1.
at C:\Program Files\Python313\Lib\subprocess.py:577 in run
573│ # We don't call process.wait() as .__exit__ does that for us.
574│ raise
575│ retcode = process.poll()
576│ if check and retcode:
→ 577│ raise CalledProcessError(retcode, process.args,
578│ output=stdout, stderr=stderr)
579│ return CompletedProcess(process.args, retcode, stdout, stderr)
580│
581│
The following error occurred when trying to handle this error:
Stack trace:
13 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\cleo\application.py:327 in run
325│
326│ try:
→ 327│ exit_code = self._run(io)
328│ except BrokenPipeError:
329│ # If we are piped to another process, it may close early and send a
12 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\console\application.py:260 in _run
258│ with directory(self._working_directory):
259│ try:
→ 260│ exit_code = super()._run(io)
261│ except PoetryRuntimeError as e:
262│ io.write_error_line("")
11 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\cleo\application.py:431 in _run
429│ io.input.interactive(interactive)
430│
→ 431│ exit_code = self._run_command(command, io)
432│ self._running_command = None
433│
10 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\cleo\application.py:473 in _run_command
471│
472│ if error is not None:
→ 473│ raise error
474│
475│ return terminate_event.exit_code
9 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\cleo\application.py:457 in _run_command
455│
456│ if command_event.command_should_run():
→ 457│ exit_code = command.run(io)
458│ else:
459│ exit_code = ConsoleCommandEvent.RETURN_CODE_DISABLED
8 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\cleo\commands\base_command.py:117 in run
115│ io.input.validate()
116│
→ 117│ return self.execute(io) or 0
118│
119│ def merge_application_definition(self, merge_args: bool = True) -> None:
7 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\cleo\commands\command.py:61 in execute
59│
60│ try:
→ 61│ return self.handle()
62│ except KeyboardInterrupt:
63│ return 1
6 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\console\commands\env\info.py:31 in handle
29│ from poetry.utils.env import EnvManager
30│
→ 31│ env = EnvManager(self.poetry).get()
32│
33│ if self.option("path"):
5 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\utils\env\env_manager.py:249 in get
247│ return self.get_system_env()
248│
→ 249│ return VirtualEnv(venv)
250│
251│ if env_prefix is not None:
4 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\utils\env\virtual_env.py:40 in __init__
38│ # from inside the virtualenv.
39│ if base is None:
→ 40│ output = self.run_python_script(GET_BASE_PREFIX)
41│ self._base = Path(output.strip())
42│
3 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\utils\env\base_env.py:404 in run_python_script
402│ # This is useful to prevent user site being disabled over zealously.
403│
→ 404│ return self.run(
405│ self._executable,
406│ "-I",
2 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\utils\env\base_env.py:389 in run
387│ def run(self, bin: str, *args: str, **kwargs: Any) -> str:
388│ cmd = self.get_command_from_bin(bin) + list(args)
→ 389│ return self._run(cmd, **kwargs)
390│
391│ def run_pip(self, *args: str, **kwargs: Any) -> str:
1 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\utils\env\virtual_env.py:90 in _run
88│ def _run(self, cmd: list[str], **kwargs: Any) -> str:
89│ kwargs["env"] = self.get_temp_environ(environ=kwargs.get("env"))
→ 90│ return super()._run(cmd, **kwargs)
91│
92│ def get_temp_environ(
EnvCommandError
Command ['C:\\Users\\<my-user>\\AppData\\Local\\pypoetry\\Cache\\virtualenvs\\<my-project>-<some-poetry-generated-string>-py3.13\\Scripts\\python.exe', '-I', '-W', 'ignore', '-c', 'import sys\n\nif hasattr(sys, "real_prefix"):\n print(sys.real_prefix)\nelif hasattr(sys, "base_prefix"):\n print(sys.base_prefix)\nelse:\n print(sys.prefix)\n'] errored with the following return code 1
Error output:
Traceback (most recent call last):
File "C:\Program Files\Python313\Lib\linecache.py", line 228, in _register_code
for const in code.co_consts:
^^^^^^^^^^^^^^
AttributeError: 'str' object has no attribute 'co_consts'
at ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\utils\env\base_env.py:434 in _run
430│ output = subprocess.check_output(
431│ cmd, stderr=stderr, env=env, text=True, encoding=encoding, **kwargs
432│ )
433│ except CalledProcessError as e:
→ 434│ raise EnvCommandError(e)
435│
436│ return output
437│
438│ def execute(self, bin: str, *args: str, **kwargs: Any) -> int:
Btw., in some of my projects, the virtual environment is located within the project folder in a ".venv" folder. I do not experience this issue in those projects.
I am not a Poetry dev, but looking at the error I think -
The error suggests linecache.py is trying to process something that should be a code object (like compiled Python bytecode), but it's actually a string — which doesn't have .co_consts.
This is probably a bug in Python 3.13 — likely in how linecache.py interacts with the interpreter when running code inline via -c. It may also reflect a mismatch in how the virtualenv or Poetry's cache interacts with the interpreter internals in 3.13.
Thanks for your input, @swills1! Note that the Poetry environments I created with Poetry (using the 3.13.2 Python base) worked just fine until the Python base installation was updated to 3.13.3. When creating a new Poetry virtual environment using the 3.13.3 base, everything works as expected. As both Python 3.13.2 and 3.13.3 work just fine in the normal cases where the base used during environment creation still exists, I doubt the issue is with Python 3.13, but rather with how Poetry handles not finding the base installation.
After reading your latest comment and rer-eading the original post, I am leaning toward this beng a system issue. Not Python or Poetry.
Python should have installed side-by-side. Meaning, you would still have the ability to use 3.13.2 and its path / location would not have changed.
But it sounds like however IT upgraded Python — invalidated 3.13.2.
I think this may have happened after re-reviewing.
- You originally had Python 3.13.2 installed globally.
- Poetry created virtualenvs using that specific binary (e.g., python.exe from Python3132 path).
- IT auto-updated you to Python 3.13.3.
- That likely deleted or invalidated the 3.13.2 binary location or broke some cached .pyc files.
- As a result, the old virtualenvs still point to the now-broken interpreter and fail to launch, leading to the odd AttributeError: 'str' object has no attribute 'co_consts'.
Do you see anything at either of these locations?
- C:\Users<YourUsername>\AppData\Local\Programs\Python\Python3132\
- C:\Program Files\Python3132\
What I wrote above would explain why you were able to delete, re create, and it work. I bet if you did this for an existing project it works as well.
poetry env remove <project-name>
poetry env use 3.13
poetry install
Do you have any insight on how Python was upgraded / what steps your IT took to upgrade Python?
I don't have the locations you mention, but I do have "C:\Program Files\Python313", which is close to your second example. Note that this is the 3.13.3 installation: there is no sign of the 3.13.2 installation.
I already tried the poetry env remove <project_name> command, but this fails with
[WinError 2] The system cannot find the file specified Running
poetry env remove <project_name> -vvv, I see that
[WinError 2] The system cannot find the file specified
at C:\Program Files\Python313\Lib\subprocess.py:1551 in _execute_child
1547│ sys.audit("subprocess.Popen", executable, args, cwd, env)
1548│
1549│ # Start the process
1550│ try:
→ 1551│ hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
1552│ # no special security
1553│ None, None,
1554│ int(not close_fds),
1555│ creationflags,
I don't know how to debug this (iot. to inspect the executable argument), but I guess executable holds a str which is the old (and now vanished) 3.13.2 path.
As poetry env remove <project_name> didn't work, I just manually deleted the folder containing the virtual environment as described in the post above. After that, I did run poetry install which successfully created the environment, automatically using the 3.13.3 installation as the base python.
I'm already on track with IT to hear their thoughts on the Python update procedure they use.
From your last reply, I understand you don't think my post should be a Poetry bug report. What about a feature request then, to have Poetry give an error message that the base python could not be found? That would have saved me a bit of time, so maybe it'd be helpful for others as well.
I just encountered the same issue after upgrading to Python 3.13.5 (from 3.13.1, I think? I'm not sure) using winget.
You're right that different Python versions are installed side-by-side, but this only applies to minor versions, NOT to patch versions. I.e., Python 3.13 is installed next to Python 3.12, but Python 3.13.5 replaces any previous version of Python 3.13. Generally these are entirely compatible; Python 3.13.3 seems to be a rare exception to this rule!
On my system, the Python 3.13.5 executable is at %LOCALAPPDATA%\Programs\Python\Python313\python.exe, which is where the previous version of Python 3.13 also lived.
Here's my guess as to what's going on here:
The error message (both the one above and the one on my system) show:
- A
python.exein%LOCALAPPDATA%\pypoetry\Cache\... - A
linecache.pyin Python's installation directory
If I'm not mistaken, poetry, on Windows, copies python.exe and python313.dll to the environment directory. Meanwhile it does not copy the standard library. This means that we were running the Python 3.13.3+ standard library with 3.13.1/3.13.2. Which does not work.
This would be an obscure issue because
- it only happens when you copy
python.exe/python3??.dll– i.e., it only affects poetry on Windows - it's unusual for Windows users to keep Python up-to-date with the latest patch version
- patch versions of Python generally don't contain this kind of breaking change (3.13.3 may be unique)
This seems to be linked to this commit: https://github.com/python/cpython/commit/c7022230d25f7eea85072e375126d0b207579800
Possible fixes:
- Do not copy
python.exe/python3??.dll. (e.g.venvplaces a different 255KB exe and no DLL in the environment directory) - Copy the standard library (wasteful)
I too faced this issue today when I upgraded my python from 3.13.2 to 3.13.5 via homebrew on my Mac.
I agree with @tjol's explanation regarding Python installations, which states that minor version upgrades replace the existing installation because they can cause conflicts.
I had to reinstall poetry to get the issue fixed.
I encountered the same issue when running Poetry commands in my virtual environment. I was able to fix it by moving the virtual environment folder and the envs file to a backup folder (in case something went wrong). After that, I created a new virtual environment, and the commands started working again.
