Poetry: How do I tell poetry to use python 2.7?

[radix]

The README indicates that poetry supports older versions of python, but when I run poetry install in a fresh project directory it's using python 3 (the same one that poetry itself is running on). I can't find an option to specify the python version to use. I specified python 2.7 as a dependency in my pyproject.toml.

[sdispater]

Thanks for your interest in poetry!

You might want to take a look at https://poetry.eustace.io/docs/basic-usage/#poetry-and-virtualenvs

Basically, if you want to use a Python 2.7 virtualenv you will have to create it yourself using pew, virtualenv or even pyenv.

This is due to the fact that poetry, being a Python 3 only library, uses the venv module to create virtualenvs which will use the Python version for which poetry has been installed.

So you will be able to manage your Python 2.7 project with poetry but it won't be able to automatically create the virtualenv.

[radix]

@sdispater Does that mean I need to activate my virtualenv manually when I want to use poetry? I really want to avoid that. What if I create the virtualenv at ~/.cache/pypoetry/virtualenvs/{project}-3.6? Will that trick poetry into using my 2.7 virtualenv?

Could poetry instead use command line tools to create the virtualenv, so it could natively support managing python 2 virtualenvs, if specifying something like --python2 on the command line when setting up a virtualenv?

[radix]

(or adding a setting to pyproject.toml perhaps)

[sdispater]

I agree this is not ideal. But, for now anyway, there is no way around it.

However, I strongly suggest to use pyenv to create your virtualenv for Python 2.7 since you can then make it activate a virtualenv automatically when you are in your project's directory. This will remove the pain of activating it manually while still being able to use poetry.

I will keep that in mind, and if I can come up with a satisfying solution to this problem I will integarte it into poetry.

[radix]

@sdispater Could poetry shell out to CLI tools running different versions of Python instead of using the venv package directly in-process? This seems like a pretty standard way to do it that other tools use (like mkvirtualenv).

btw, it seems that creating a python2.7-based virtualenv at ~/.cache/pypoetry/virtualenvs/project-py3.6 works fine; poetry seems to be using the python version from that virtualenv so everything is natively python2.7 inside. The only issue I've run into is the creation of the virtualenv.

[sdispater]

@radix Why would poetry use an external dependency while there is a perfectly functional module in the standard library?

I perfectly understand what you are saying, believe me, but I don't want to bloat the CLI with options like --python, --three, --two like pipenv because it is a pain to maintain and each developer has its own way of managing its Python versions.

poetry behaves a lot like bundler in Ruby in the sense that it will use whatever Python version it has been installed for (or the virtualenv one if it's activated).

That's why I am currently working on making poetry compatible with Python 2.7 (which in this case will use virtualenv management tool like virtualenv) so that if you have a Python 2.7-only project you would just have to install poetry for Python 2.7 and it would behave like expected.

[radix]

Supporting poetry running on python 2.7 would be excellent. It would mirror how cargo works as well. Do you have any list of work that needs to be done that maybe I could help with?

Just for argument's sake, I think the answer to your first question is very clear: because it would enable more use cases. I personally never want to activate a virtualenv again in my life. It's one of the worst parts of Python development. I never even want to be at risk of mutating my virtualenv in a way that isn't tracked in a .toml or .lock file. So I want to make sure I use a tool that can take care of it entirely for me and isolate me from the environment.

However, the suggestion of having poetry actually run on python 2.7 would be a good alternative to supporting arguments like --two. So I'm happy as long as that's eventually possible :)

[sdispater]

To support 2.7, there is a bunch of things to do:

• Changing type annotations to Python 2.7-compatible ones
• Adapting any non-compatible code (which can be quite complex)
• Handling unicode problems that might occur

[sdispater]

@radix Just to keep you posted.

The Python 2.7 support is coming along quite well. The only part remaining is the packaging/building part the rest is already supported (project creation and dependency installation).

So, expect full Python 2.7 support sometime next week :-)

[radix]

Thanks so much for the Python 2.7 support, I've verified it works!