Azure-pipelines-tasks: Support PyPy and PyPy3 in UsePythonVersion

[asmeurer]

It would be nice if UsePythonVersion supported "PyPy" and "PyPy3" as Python versions. Right now, it's a bit annoying to write a job that uses both interchangeably. I haven't actually fully figured out how to do it; I tried writing a script to create and activate pypy virtualenv, which required munging permissions, but it turns out environment variables aren't persisted between scripts, so it doesn't work.

[vtbassmatt]

We should get @brcrista 's input on designing this well. There are several other Python implementations which we could (in the future -- not suggesting we do it now) support with a similar pattern. Anaconda, IronPython, etc.

[brcrista]

I think this would be good. There's another extension I want to add to our version spec syntax: use 3.7-dev as sugar for >= 3.7.0-a0.

@vtbassmatt let's sync up and discuss how to design this. It might require some task-lib support.

[brcrista]

@asmeurer about environment variables: each build step runs in its own process. Sounds like you are using a virtual env as a way to get PyPy in your PATH?

If you are running on a hosted agent, you can often avoid using a virtual env entirely. You can use a ##vso command to set variables in that will be persisted between steps: https://docs.microsoft.com/azure/devops/pipelines/process/variables

If you really want the virtual env, you should be able to put everything that needs to run in the virtual env in a script and then activate the env at the start of that script.

[altendky]

Until this ticket gets resolved, here's a seemingly working build covering Linux/macOS/Windows for CPython 2.7/3.4+ and PyPy2/3.

https://dev.azure.com/altendky/exttr/_build/results?buildId=75&view=logs

Maybe at some point I'll try to figure out the structure of these tasks and how to get new software included in the images, or however that works. If someone knows those steps and can lay them out it might make finding a contributor easier.

Cheers, and thanks for the half of the problem this task does cover. :]

[brcrista]

We have a plan for this; I might as well sketch it out here:

Use Python Version finds its versions based on a directory structure, described here: https://github.com/Microsoft/azure-pipelines-tool-lib/blob/master/docs/overview.md#tool-cache

The gist of the fix will be to move the PyPy install locations so it looks like this:

$AGENT_TOOLSDIRECTORY/
    Python/
        3.6.4/
            x64/
                {tool files}
            x64.complete
    PyPy/
        2.0.0/
        3.0.0/

And change the code of the task to look for PyPy if the user asks for that.

[kapilt]

pypy2/pypy3 is a little ambigous for versions of 3, as thats inclusive of both 3.5 and 3.6, in particular i was interested in the latter, but found that its actually 3.5. the version proposal is also a little ambigous because pypy's python 3.6 latest release actually corresponds to pypy3.6 v7.1.1 so its unclear what the verison numbers to use for the task without additional research.

[brcrista]

We explored a few possible designs for this. The main alternative was something like this:

strategy:
  matrix:
    Python27:
      python.version: '2.7'
    Python36:
      python.version: '3.6'
    PyPy2:
      python.version: '2.7'
      python.flavor: pypy
    PyPy3:
      python.version: '3.5'
      python.flavor: pypy

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: $(python.version)
    flavor: $(python.flavor)

This is more semantically correct, since PyPy technically isn't a "version" of the Python interpreter, and would make it more natural to switch between versions of PyPy.

We ended up going with the simpler syntax that is rolling out with v0.150 of the task right now. The first reason is that we don't actually have a full matrix of interpreter versions for PyPy on the hosted agents. The second reason is that using pypy2, pypy3 as "versions" would work with a proposed, unifying "use" syntax.

If the question is "why don't we support more side-by-side PyPy versions" -- we could, and add syntax like pypy3.6, but it would be some additional work. Right now, I feel like testing on a full range of CPython versions and a couple of PyPy versions is enough for most projects. But we'll keep an ear out for feedback and see if this is something people want.

[brcrista]

This feature should now be available for all users.