Pipenv should check implementation version when choosing a runtime

Describe your environment

1. OS Type: macOS 10.13.3
2. Python version: $ python -V

Python 2.7.13 (c925e7381036, Jun 05 2017, 20:53:58)
[PyPy 5.8.0 with GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)]

1. Pipenv version: $ pipenv --version: pipenv, version 9.1.0

Expected result

$ pyenv local pypy2.7-5.8.0
# Creates .python-version that sets the project's python 
# version to the specific pypy version
$ pipenv install --python pypy
# Installs packages in virtualenv created with pypy2.7-5.8.0

Actual result

$ pipenv install --python pypy
Creating a virtualenv for this project…
Using /Users/josh/.pyenv/versions/pypy2.7-5.9.0/bin/pypy to create virtualenv…
# Installs packages in virtualenv created with pypy2.7-5.9.0, 
# or whatever the latest version of pypy2.7 I have installed is

I have to uninstall pypy2.7-5.9.0 and any other later versions to be able to use v5.8.0 with pipenv. I need to test with 5.8.0 specifically because that is the latest version that the heroku python buildpack supports.

Perhaps pipenv should defer to .python-version when choosing the python version to use, unless it conflicts with python_version or python_full_version in the Pipfile, in which case throw an error.

[techalchemy]

At a glance you are simply suggesting improvements to our existing handling of this which seem straightforward. While the issue is closed (think of it as triaged -> not prioritized yet), I suspect we’d entertain a PR on this

[joshfriend]

I think this should be reopened because as is, pipenv install creates environments that immediately fail check. For example:

Pipfile:

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"

[packages]
testpackage = "*"

[requires]
python_full_version = "3.5.3"
implementation_name = "pypy"
implementation_version = "5.10.1"

pipenv install will create the venv with CPython (probably, unless you only have pypy installed), but pipenv check will then immediately fail:

$ pipenv check
Checking PEP 508 requirements…
Specifier implementation_name does not match pypy (cpython).
Specifier implementation_version does not match 5.10.1 (3.5.3).
Failed!

Pipfile.lock:

{
    "_meta": {
        "hash": {
            "sha256": "c637dfe39ab17bf44ba426526e66497c8e9d4663eafa9214c7e5edcb13b0d7e2"
        },
        "host-environment-markers": {
            "implementation_name": "cpython",
            "implementation_version": "3.5.3",
            "os_name": "posix",
            "platform_machine": "x86_64",
            "platform_python_implementation": "CPython",
            "platform_release": "17.4.0",
            "platform_system": "Darwin",
            "platform_version": "Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64",
            "python_full_version": "3.5.3",
            "python_version": "3.5",
            "sys_platform": "darwin"
        },
        "pipfile-spec": 6,
        "requires": {
            "implementation_name": "pypy",
            "implementation_version": "5.10.1",
            "python_full_version": "3.5.3"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.python.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "testpackage": {
            "hashes": [
                "sha256:fd0076de3a2c8c695826e466cbb0f9febc6ea8474302ec3e673dbe46cd278b6a"
            ],
            "version": "==2.27"
        }
    },
    "develop": {}
}

The expected behavior would be that anything in the requires section of the Pipfile should be considered for install such that pipenv doesn’t end up creating environments that fail the check process with no changes. For this example, that would mean looking at the python implementation type when finding a matching python executable. I believe only python_full_version and python_version are currently used during install.

Of course, not all PEP508 markers will be useful as a requires directive, but if they are given in the Pipfile and don’t match, an error should be given if the criteria are not able to be satisfied.

This feature would be very useful for anyone that requires non CPython runtimes.

@techalchemy I don’t think this would need to use pyenv shims. I think when selecting the python runtime, pipenv will just have to additionally examine implementation_version and implementation_name. That’s something I might try out soon when I get the chance. Limitations on that would be that any runtime with python_version less than 3.3 will report those markers as cpython and 0. In that case the only recourse is to specify the full path to the executable.