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
pythoninstead 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-projectvariation 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
python3which 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/bininstead of abindir, 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.pkgdistribution 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
bindir, but rather ausrwith alocalwith abindir (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
.pkgfile version of Python 3.11, uninstalled it usingpkgutilandrm, 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.10I then created a test directory and ran
poetry initinside, creating a simple pyproject.toml. Followed that withpoetry updateand 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.10poetry config virtualenvs.in-project truepoetry updateAnd 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
mlocatetrace 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):