select python version from pyenv

[tmshn]

Pull Request Check List

Resolves: #2558

• Added tests for changed code.
• Updated documentation for changed code.

Note: this is currently rough, early stage of implementation. It's here to receive voices from the community. tests/documentation will be added later.

What's changed

On Python version selection on creating virtual environment, Poetry now utilize versions from pyenv.

To be fixed

• python = "3.7" seems not compatible with 3.7.x? examine this case
• Warning on activating venv that Python is not compatible

$ poetry run python -V
The currently activated Python version 3.8.2 is not supported by the project (~3.7.1).
Trying to find and use a compatible version.
Using /root/.pyenv/versions/3.7.7/bin/python (3.7.7)
Python 3.7.7

[justinmayer]

I can see the benefit of looking in other places for potential Python interpreters, but if adding support for that, I think it should be more inclusive than just Pyenv. For example:

• asdf — specifically its Python plugin
• Pythonz

… are two additional projects that should not be left out if adding support for detecting available Python interpreters.

(In VirtualFish, I added support for all three.)

Related issue: #1518

[joshfriend]

Something that people got wrong when adding this kind of feature to pipenv was not making the logic smart enough to handle alternative python implementations such as pypy or jython (see the full list of PEP508 markers). This PR only matches major/minor version and ignores the patch version and existence of pypy completely.

I think this would be a fantastic feature if given some more consideration, but as is here, especially without being able to disable the behavior (e.g. PIPENV_DONT_USE_PYENV), it won't be a success.

[jalaziz]

I wouldn't call that "wrong". Just incomplete.

There's nothing wrong with supporting the majority use case first and iterating. That's just standard iterative development.

This functionality would make life better for a bunch of users (myself included), so why block it on adding support for less popular implementations?

And before I get attacked. I'm not saying that support for PyPy, Jython, asdf, and Pythonz shouldn't be added. I'm just saying those could be contributed separately.

[rch]

I'd like to be able to use this as a starting point for sharing a virtualenv among a group of related projects, while managing the actual dependencies separately.

Here's an example of a project (not mine) where this capability would be useful: DSV

I'm currently handling my case with pyenv and manually maintaining requirements.txt files, but this is obviously cumbersome and error prone. Integrating Poetry a little more closely with pyenv seems like a logical path.

I'm all for supporting other version managers as well, but this patch (and pyenv support generally) seems like a step in that direction.

[joshfriend]

I'm just saying those could be contributed separately.

What I was trying to ask for (but it didn't come out in text accurately at all, oops) is to not add this feature without a way to turn it off. If poetry starts picking python versions from pyenv, it will pick the wrong one for anyone who isn't using CPython and is thus broken for those users.

[finswimmer]

Hello @tmshn,

thanks a lot for your contribution 👍 I absolutely understand that this "kind of magic" would be useful from the user perspective. But like @justinmayer said, there are much more tools and poetry doesn't want to prefer one or another.

The intended way of telling poetry what interpreter it should use for the venv is "poetry env use".

[github-actions]

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