I'd like to hide:
Python 3.5 will no longer be supported in the next feature release of Poetry (1.2).
You should consider updating your Python version to a supported one.
Note that you will still be able to manage Python 3.5 projects by using the env command.
See https://python-poetry.org/docs/managing-environments/ for more information.
I was about to ask this :) Please I also need help. I get this:
Python 2.7 will no longer be supported in the next feature release of Poetry (1.2).
You should consider updating your Python version to a supported one.Note that you will still be able to manage Python 2.7 projects by using the env command.
See https://python-poetry.org/docs/managing-environments/ for more information.
If I get this warning, obviously I haven't set something up right and all I use these days is python 3.8
It doesn't seem to matter whether I install it with python3:
curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python3 -
@rarenatoe the official installer based installer is designed to run on the currently active interpretor. If you inspect the poetry bin file the header might be pointing to python instead of python3. You can fix that manually. The installer tries to choose correctly, but might not work as expected in all environment configurations.
Alternatively you can also consider installing via python3 -m pip or pipx specifying python3.
Is there any chance of getting get-poetry.py to use python3 when it exists, in preference to python, especially now that python 2 support will be deprecated? Maybe at least if get-poetry.py is itself run under python3? This has been an issue for _ages_ (#1042, #1257, #1494, #1878, #2106, #2222, #2352, #2547, among others); it was even briefly fixed in master until reverted by #2544. There was some more recent discussion about it in https://github.com/python-poetry/poetry/pull/2547#discussion_r449025727 too.
Specifically,
@rarenatoe the official installer based installer is designed to run on the currently active interpretor.
I don't think that's what actually happens in this case -- it uses the first executable it finds that works, so even if the active interpreter for get-poetry.py is python3, if there's a python installed it uses it instead, causing this issue.
On all the Ubuntu 18.04 and 20.04 systems I run, python is 2.7, python3 is 3.x, and Poetry won't use python3 unless there's no python available at all, no matter what the installer is run with. Consequently I still have to leave a note in my installation instructions to tell people to modify the shebang in .poetry/bin/poetry to use python3 which I'd really like to avoid. It's not a great first experience of using Poetry!
@adamgreig
That's why I've been using pip3 install poetry ;)
I'm having the same problem on Linux Mint. I have set my personal (.bashrc) to python 3 when using python as a command.
I have installed poetry using the get-poetry command using Python 3, but the installed poetry executable keeps referring to Python 2.7.
It also leads to errors when using PyCharm with the poetry plugin. The warning confuses the PyCharm plugin, and poetry integration doesn't work at all.
I've found a workaround in editing the shebang in ~/.poetry/bin/poetry.
Change the first line to match the path to your global Python 3 interpreter.
In my case I needed to change line 1 to #!/usr/bin/python3
Poetry will now use Python 3 by default and the warning doesn't appear anymore.
Some info on the shebang command and what it does is here: https://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my
Is there any chance of getting get-poetry.py to use python3 when it exists, in preference to python, especially now that python 2 support will be deprecated?
Why do you want to do this? poetry can run with python2 and python3. Once we drop support for python2, the shebang will change to python3 only.
Is there any chance of getting get-poetry.py to use python3 when it exists, in preference to python, especially now that python 2 support will be deprecated?
Why do you want to do this?
poetrycan run with python2 and python3. Once we drop support for python2, the shebang will change to python3 only.
Poetry returns a warning. This warning messes with some integrations like the PyCharm plugin. I imagine some other automated tools using poetry will break on this as well. There is another issue IIRC that asks for a way to suppress this warning for this reason.
I agree with both issues here. If available, poetry should run with python3 or at least the python version used to call get-poetry.py. Otherwise it defaults to python2 and you get two warnings, one about it being deprecated and another one about some functionality not supported on python2.
About disabling the warnings for python 3.5 and 2, they are not only annoying, they also break this functionality listed on the main page:
Alternatively, to avoid creating a new shell, you can manually activate the virtual environment by running source
{path_to_venv}/bin/activate (source {path_to_venv}\Scripts\activate.bat on Windows). To get the path to your virtual environment
run poetry env info --path. You can also combine these into a nice one-liner, source $(poetry env info --path)/bin/activate
Since poetry env info --path returns a wall of text instead of the path to the environment.
About disabling the warnings for python 3.5 and 2, they are not only annoying, they also break this functionality listed on the main page:
This should be fixed now by https://github.com/python-poetry/poetry/issues/2754
I originally posted this as a comment in #3184 (closed).
I would also expect that if running _get-poetry.py_ with python3, python3 would be used for the shebang line. Even when I explicitly use python3 to install Poetry, I still get bothered by a big warning that Python 2 support is about to be dropped.
Sure, it's easy enough to adjust the shebang line manually, but not when installing Poetry in an automated way.
How about simply changing the following line in _get-poetry.py_
allowed_executables = ["python", "python3"]
to
allowed_executables = ["python3", "python"]
This first tries Python 3, which doesn't spit out a big warning message. In fact, this is how it is done for Windows:
allowed_executables += ["py.exe -3", "py.exe -2"]
Is there any reason why this would need to be different in Windows and Linux/MacOS?
@brechtm (and others) This issue is about hiding/disabling the warning messages. What you are asking for is related, but still a different thing. Maybe open a new ticket if there is not one yet, so that things are easier to track by reading the ticket titles.
@sinoroc It's all related, if they can just fix the issue then there won't be any need to hide warnings.
if they can just fix the issue then there won't be any need to hide warnings.
There are 2 distinct but related things that I can identify in this discussion:
Feature request to knowingly disable / hide the legitimate "Python EOL" warning when Poetry is running under Python that has reached its end of life (_EOL_). There is nothing to "_fix_" here, there is no bug. But maybe a new CLI flag poetry --disable-warnings=eol ... could help improve the UX.
Confusion about what Python interpreter version is used when running poetry that was installed with get-poetry.py (that coincidentally might lead to unexpected, but still legitimate, _EOL warning_ messages), and no user friendly way to control which Python is used to run poetry.
The first one is the original reason for this ticket and can be discussed and handled within this ticket.
The second one is also very much worth a discussion (and probably worth changes in the code base and/or documentation), but I believe it should happen in a different ticket, in order to make it easier for maintainers to keep track of things. This will also help you get those changes released faster. I just opened the following ticket for this purpose:
Related:
@sinoroc
It's not just to improve the UX. This warning really breaks things especially for those tools parsing stdouts.
It'll be nice to hide the warning, or redirect it to stderr and let users hide it.
Hello @kigawas,
This warning really breaks things especially for those tools parsing stdouts.
this is fixed since poetry 1.1.3. See https://github.com/python-poetry/poetry/pull/3131
Most helpful comment
Is there any chance of getting
get-poetry.pyto usepython3when it exists, in preference topython, especially now that python 2 support will be deprecated? Maybe at least ifget-poetry.pyis itself run underpython3? This has been an issue for _ages_ (#1042, #1257, #1494, #1878, #2106, #2222, #2352, #2547, among others); it was even briefly fixed in master until reverted by #2544. There was some more recent discussion about it in https://github.com/python-poetry/poetry/pull/2547#discussion_r449025727 too.Specifically,
I don't think that's what actually happens in this case -- it uses the first executable it finds that works, so even if the active interpreter for
get-poetry.pyispython3, if there's apythoninstalled it uses it instead, causing this issue.On all the Ubuntu 18.04 and 20.04 systems I run,
pythonis 2.7,python3is 3.x, and Poetry won't usepython3unless there's nopythonavailable at all, no matter what the installer is run with. Consequently I still have to leave a note in my installation instructions to tell people to modify the shebang in.poetry/bin/poetryto usepython3which I'd really like to avoid. It's not a great first experience of using Poetry!