Choose the host Python version used when running poetry installed with 'get-poetry.py'

[sinoroc]

Follow up to this issue:

• How to disable Poetry 1.1 warnings? (#3029)

Since #2683 a EOL warning message is displayed when poetry runs under a Python interpreter that has reached its end of life (EOL), for example Python 2.7, and 3.5. Fair enough. But when using a poetry installation initiated with get-poetry.py it does not seem possible to control which Python interpreter is being used. Which leads to the EOL warning message being legitimately displayed but there is no straightforward way for the user to switch to a different Python version. It is not reasonable to expect from the users that they uninstall the older Python interpreters.

Related

• How to disable Poetry 1.1 warnings? (#3029)
• No method to control the python version used (#522)
• poetry default to using python instead of python3 (#3184)

[ericriff]

Aslo on this subject, on OSs like ubuntu which have a python -> python2.x install , the shebang in /usr/bin/poetry defaults to python and, therefore, uses python2 . This results in the described warning about the EOL of p2, but also the following:

RuntimeWarning: The _posixsubprocess module is not being used. Child process reliability may suffer if your program uses threads.
  "program uses threads.", RuntimeWarning)

I believe that poetry should default to python3 when available and if it is not, fallback to python2.

[sinoroc]

Personal opinions:

• python should always be Python 2, python3 should always be Python 3. I think I had seen this as a somewhat official-ish statement from Python core somewhere, but can't find it any more, so I might as well have dreamt it. I still thinks it makes sense anyway, Python 2 and Python 3 are different things, I have never seen Python 1, and python has been a synonym of Python 2 for so long now.

• I do not know what the rationale is behind the get-poetry.py installation technique. Installing with pipx, or pex, or shiv or anything similar seem like better recommendations. But again, I do not know the rationale.

• Setting python3 as shebang, does not solve the issue when your default python3 is Python 3.5, and then it will be the same story when Python 3.6 reaches end of life (isn't it the case already?), so it is just pushing back the issue a bit further in time until it reappears again.

[finswimmer]

Hello,

I do not know what the rationale is behind the get-poetry.py installation technique.

I've talked about this in another issue (#3184 (comment)). The rational behind this, is perfect interaction with pyenv. Change the current python version with it and poetry will create the venv with this version immediately. That's the same reason why the shebang than uses /usr/bin/env instead of the absolute path to the interpreter used during install.

python should always be Python 2, python3 should always be Python 3. I think I had seen this as a somewhat official-ish statement from Python core somewhere, but can't find it any more, so I might as well have dreamt it.

I guess what you have in mind is PEP 394. This PEP has evolved about the time. Initially it was the recommendation that python should point to python2. Lot of distribution has changed it over the time (might be that ubuntu is the last one, that doing it?). So now the recommendation for the shebang is: Point it to python2 if the script only support python2, point it to python3 if the script only support python3. Point it to python if the script doesn't care which version it is. And this it, what poetry follows here. As I said the in linked comment above, we will have to change it, once we are dropping python2 support.

Two things I recommend instead of changing the shebang by hand:

1. Let python point to python3. With ubuntu you can do this using update-alternatives. There are people that say you should avoid this, as there might be packages that rely on that python points to python2. IMO if you really have such a case, tell the author to fix the shebang to what PEP 394 recommends.

2. Create an alias for poetry, which will run python3 /path/to/poetry.

fin swimmer

[sinoroc]

The rational behind this, is perfect interaction with pyenv.

I see. It could be mentioned in the "installation" section, and in the Python EOL warning message, or the FAQ.

Do people really use pyenv though?

I guess what you have in mind is PEP 394.

That might be it, yes. Thanks!

For the rest, I would like to remind that it is not just a matter of Python 2 vs. Python 3. If I remove python from my OS, but I still have python3 pointing at python3.5 I would get the message as well, right? And I assume it will happen with Python 3.6 later.

Aliases might be good enough and simple enough for most of the use cases. For example in ~/.bashrc or similar:

PATH_TO_POETRY=$(which poetry)
alias poetry-py2.7="python2.7 ${PATH_TO_POETRY}"
alias poetry-py3.8="python3.8 ${PATH_TO_POETRY}"
alias poetry="python3.9 ${PATH_TO_POETRY}"

---

Maybe I should accelerate the work on making poetry work out of a zipapp, maybe that could help a bit.

[brechtm]

@finswimmer

I've talked about this in another issue (#3184 (comment)). The rational behind this, is perfect interaction with pyenv.

Thanks for the clarification. However, not everyone uses pyenv and many people run Ubuntu. So how about at least having the option of forcing which python to write to the shebang line by means of an environment variable? Then we could do:

curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | POETRY_PYTHON="python3" python3 -

[sinoroc]

@brechtm If I may. Real question, I truly do not know:
Why do you want to use get-poetry.py then? Why not use any of other installation techniques?

[brechtm]

Why do you want to use get-poetry.py then? Why not use any of other installation techniques?

Because get-poetry.py is the recommended installation method, as per the Poetry documentation [1]? I haven't actually considered alternative installation techniques.

For my use case, however, installation is automated, so it should not require root privileges. pip install --user poetry might interfere with other packages the user has installed. Perhaps I could use pipx, but I didn't have a look at it yet since it seems silly installing pipx just for the purpose of installing Poetry.

For now, I'm using a locally patched version of get-poetry.py that prefers python3 to python.

[1] Perhaps the docs should mention pyenv if this indeed the reason for preferring python to python3? Also, a search function on https://python-poetry.org/docs/ would be great. (sorry, off-topic, I know)

[sinoroc]

When you feel comfortable enough with Python, I think it is worth considering the alternative installation techniques, especially if the default technique causes you issues. I have not used it but pipx looks nice enough, that I would recommend at least trying it.

---

A personal take on this....
This is how I often do these kind of things (assuming ~/.local/bin is listed in the PATH environment variable)? It works fine for me, but it might have its drawbacks as well.

# create a fresh virtual environment
pythonX.Y -m venv ~/.local/bin/.venvs/poetry-pyX.Y

# install poetry in that environment
~/.local/bin/.venvs/poetry-pyX.Y/bin/python -m pip install poetry

# add symlink in your binaries directory pointing to the newly installed poetry
ln -s ~/.local/bin/.venvs/poetry-pyX.Y/bin/poetry ~/.local/bin/poetry-pyX.Y

# use it
poetry-pyX.Y

# update it
~/.local/bin/.venvs/poetry-pyX.Y/bin/python -m pip install --upgrade poetry

[sinoroc]

I had missed it, the pyenv workflow is (succinctly) documented here:

• https://python-poetry.org/docs/managing-environments/

[agoose77]

A "simple" solution is to add a temporary directory to PATH, symlink /usr/bin/false as python, and then run the installer. This blacklists python

[sontek]

One of the primary reasons to use poetry over pip is because it manages the virtualenvs for you. I don't think requiring pyenv to install it and make it function is very useful. If I have to setup and use pyenv to use poetry, then I might as well just use pip inside the pyenv?

[sinoroc]

Pyenv does not deal with Python virtual environments (the name is misleading). Pyenv deals with installing and "activating" multiple Python interpreters on the machine. So you can have Python 3.7, 3.8, 3.9 installed and easily switch from one to another as your current main Python, i.e. switch python and/or python3 to a Python 3.7 or a Python 3.8.

[sontek]

@sinoroc Yes, but the problem is when utilizing a system that has "python" defaulting to python2.7, it usually means certain system applications are dependent on it BEING python2.7. If we force users to activate a python3 environment and squashing the "python" environment to being python3, some core parts of their system are going to break.

Unless we are suggesting a workflow of:

• pyenv local 3.9
• poetry add whatever
• pyenv local 2.7

So that they don't accidentally move on to using other parts of the system that depend on python NOT being python3.

If activating in environment to use poetry is necessary, then there isn't much difference from using pyenv and just doing:

python3 -m venv venv/
source venv/bin/activate

pip install . -r requirements.txt

[sinoroc]

I don't know. I don't feel like it is that big of a deal. I don't know why the shebang of poetry is not always python3 instead of python, does not make much sense to me either, but whatever, it does not matter that much. You seem to know what you are doing, it seems to me like you have outgrown the get-poetry.py installer, time to move to a different installation mechanism maybe.

[sontek]

@sinoroc Yeah, I'm more of discussing this because the ergonomics around it don't make sense to me and I would like to start recommending people use Poetry over things like pip and pipenv. So even though I know how to work around this flaw, I don't believe its safe to recommend use of the software when it'll be something MAJORITY of users hit.

Most systems aren't defaulting to python3 for "python" and having to work around it is a weird limitation with many easy fixes.

[finswimmer]

Hello,

So even though I know how to work around this flaw,

I still don't get why people are trying to "work around" it. At the moment poetry works with python2 and python3. So there is no need to switch.

I don't know why the shebang of poetry is not always python3 instead of python,

Because python2 and python3 are still supported.

I think this will change with the next minor release (1.2), because then we drop python2 support.

fin swimmer

[finswimmer]

The get-poetry.py script is now deprecated in favor of install-poetry.py, which will bind poetry to the python version it was installed with. See https://python-poetry.org/blog/announcing-poetry-1.2.0a1/#deprecation-of-the-get-poetrypy-script

As a downside the "pyenv workflow" no longer works.

[matt852]

The get-poetry.py script is now deprecated in favor of install-poetry.py, which will bind poetry to the python version it was installed with. See https://python-poetry.org/blog/announcing-poetry-1.2.0a1/#deprecation-of-the-get-poetrypy-script

As a downside the "pyenv workflow" no longer works.

The install-poetry.py file is Python 3 only. Is there one for both Python 2 & 3?

[neersighted]

The get-poetry.py script is now deprecated in favor of install-poetry.py, which will bind poetry to the python version it was installed with. See https://python-poetry.org/blog/announcing-poetry-1.2.0a1/#deprecation-of-the-get-poetrypy-script
As a downside the "pyenv workflow" no longer works.

The install-poetry.py file is Python 3 only. Is there one for both Python 2 & 3?

The get-poetry.py file is frozen just like Python 2. I can't tell you not to use it, but keep in mind that it is no longer supported and no improvements will be made to it.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.