poetry: getting error while running poetry show
I have installed poetry 1.4.0 version. I am getting the following error while running poetry show
:
Command ['python', '-I', '-W', 'ignore', '-'] errored with the following return code 2
Error output:
Unknown option: -I
usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.
Input:
import sys
if hasattr(sys, "real_prefix"):
print(sys.real_prefix)
elif hasattr(sys, "base_prefix"):
print(sys.base_prefix)
else:
print(sys.prefix)
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 19 (5 by maintainers)
I guess this is a duplicate of #7957, just revealing itself in a different way. In both cases the result is that poetry is calling
python
instead of calling a particular python in a particular virtual environmentso it is fixed by the same fix
Edit: or anyway that’s probably true for the
virtualenvs.in-project
variation per previous comment, I guess it can’t be the case though for pre-1.5.0 examplesFor what it’s worth, I have the same issue, on a MacOS where default system python is 2.7 but I installed poetry using
python3
which is version 3.10. The installation of poetry should ensure it sticks with the same python3?Just did a bit of poking around because I hate feeling like I’m bonkers, it seems that I’m not the first person to end up with virtual environments that have a
usr/local/bin
instead of abin
dir, including one in a Poetry issue. I’m going to conclude that something was fishy in my Python installation and that something in the course of installing the official Python.pkg
distribution over my brew install, then cleaning up, then re-installing the brew version got everything facing in the proper direction.If you anyone else ends up here, these might be useful:
Ok, this is now a non-problem, though I don’t know why.
I took @dimbleby’s suggestion, set a break point, walked into the code, and found the really weird result that the virtual environment didn’t have a
bin
dir, but rather ausr
with alocal
with abin
dir (see below). Fortunately I cut/paste the bits included below, so I’m not crazy, but… I cleaned up (rm -rf /Users/georgehartzell/Library/Caches/pypoetry/
) and tried to recreate it and…Now everything works (starting from an uninstall and install of poetry v 1.5.0) and I can not get it to fail. While working along this today I installed the official Python
.pkg
file version of Python 3.11, uninstalled it usingpkgutil
andrm
, and reinstalled via homebrew. Perhaps that changed something? Also had been playing with older versions of poetry, but can’t recreate it that way either.There are enough screen copies in this and the #8012 thread that I don’t think I was hallucinating, but I can no longer recreate this.
If it happens again or I figure out what I changed, I’ll pick the thread back up.
@dimbleby – thank you for the pointers!
For posterity’s sake, here’s what I saw the first time I walked into the code.
Well, weird.
but
and
Just discovered a new clue. I created a test user from scratch, and as that user repeated the installation above.
curl -sSL https://install.python-poetry.org | python3.10
I then created a test directory and ran
poetry init
inside, creating a simple pyproject.toml. Followed that withpoetry update
and it worked – it created the virtualenv and lock file.However, I had forgotten that Poetry defaults to creating virtualenvs under ~/.cache, and I vastly prefer them in-project. So I clean up and try again:
poetry env remove 3.10
poetry config virtualenvs.in-project true
poetry update
And now it fails, with ‘Unknown option: -I’.
So what ended up working for me is erasing every trace of poetry from my system. First through the usual channels:
Then using
mlocate
trace what was left of poetry in the system:What I ended up removing was:
Then I could reinstall poetry. This time I opted for installing poetry using pip and python 3.9, which is more stable in my system (the collections.abc renaming is pulling my leg time and again):