Hi there, I’ve got a question regarding 

./pant awslambda

  , we are currently on PANTS

v1.28.0

When pants is building an awlambda target, it seems to be always using python 2.7 even there is python 3.8 installed on our CI/CD environment, we’ve also specified the 

interpreter_constraints = ["CPython>=3.7"]

 in the pants.ci.toml file Is there a way to enforce it to use python 3.8? Here is part of the trace stack:

pid: 14794 -> /usr/bin/python2.7 /tmp/process-executionAmQ08c/pex_root/pip.pex/d3323a933395f1fea4b421b92e99bd2c3d524e6c --disable-pip-version-check --isolated --no-python-version-warning -q --cache-dir /tmp/process-executionAmQ08c/pex_root download --dest /tmp/tmpsuxiy3/manylinux2014_x86_64-cp-38-cp38 --index-url <https://pypi.org/simple/> --header Cache-Control:max-age=3600 --retries 5 --timeout 15 --platform manylinux2014_x86_64 --implementation cp --python-version 38 --abi cp38 --only-binary :all: --constraint constraints.txt boto3==1.12.20 idna<2.10 requests==2.23.0 ruamel.yaml==0.16.10 snowflake-sqlalchemy==1.2.3 raised Executing /usr/bin/python2.7 /tmp/process-executionAmQ08c/pex_root/pip.pex/d3323a933395f1fea4b421b92e99bd2c3d524e6c --disable-pip-version-check --isolated --no-python-version-warning -q --cache-dir /tmp/process-executionAmQ08c/pex_root download --dest /tmp/tmpsuxiy3/manylinux2014_x86_64-cp-38-cp38 --index-url <https://pypi.org/simple/> --header Cache-Control:max-age=3600 --retries 5 --timeout 15 --platform manylinux2014_x86_64 --implementation cp --python-version 38 --abi cp38 --only-binary :all: --constraint constraints.txt boto3==1.12.20 idna<2.10 requests==2.23.0 ruamel.yaml==0.16.10 snowflake-sqlalchemy==1.2.3 failed with 1

Hi, what is the

python_awslambda

target definition in your BUILD file?

the runtime is

runtime="python3.8"

So from the stack trace, it looks like Pex is getting all the right commands to build a PEX with Python 3.8. The python2.7 piece is a little confusing that it’s not actually what your PEX is being built with. Rather, it’s what PEX is using to run itself. This is like how both Pants and MyPy need to run with Python 3, but they can work on Python 2 code. Pex can run with Python 2.7, and still build Python 3 PEXes What is the specific error you’re getting / the full stack trace?

stacktrace

so, the

pid: 14794 -> /usr/bin/python2.7 /tmp/process-executionAmQ08c/pex_root/pip.pex/d3323a933395f1fea4b421b92e99bd2c3d524e6c

bit does indicate that pex is using pip under python 2.7 to build this target

does the AWS plugin do that

It does not. We determine interpreter constraints based on the transitive closure of targets. We merge them into a single set of constraints But because we set

--platform

, that doesn’t even matter.

--platform

overrides interpreter constraints with Pex. You can’t specify both at the same time. And in the original Pex command, it looks like we indeed are setting

--platform

correctly.

the ./pants awslambda command completes without error when we ran it in a venv with python 3.8

I think this is likely more relevant than the

compatibility

field or the

interpreter_constraints

option. I suspect there’s a bug with the venv somehow leaking.

@clever-table-90691: if you’re able to run with

./pants -ldebug ...

it should render a lot more information about how pex is being invoked.

ldebug

[2020-07-15T11:40:40.222Z] pex: Selecting runtime interpreter
[2020-07-15T11:40:40.222Z] pex: Using the current interpreter /usr/bin/python2.7 since no constraints have been specified and PYTHONPATH is not set.
[2020-07-15T11:40:40.222Z] pex: Selecting runtime interpreter: 0.1ms

… so it looks like however you are setting the interpreter_constraints is not sticking

hey @witty-crayon-22786, thanks for looking into this Do you mean?

export PANTS_CONFIG_FILES=<http://pants.ci|pants.ci>.toml

got it. ok: so, you might consider confirming that that is resulting in the options you expect: the debug input indicates that the constraint is not being applied: running

PANTS_CONFIG_FILES=<http://pants.ci|pants.ci>.toml ./pants help-advanced python-setup

should show you the option applied

3.8 is default

Thanks, Maryanne. @witty-crayon-22786 it looks like

lambdex.pex

, i.e. the pex that runs the Lambdex tool, does not actually have constraints applied. We set it to

lambdex.get_requirement_specs()

, but that results in None, meaning we have no constriants. However, that is different than when we resolve requirements, and it looks like the issue is that resolving requirements is not doing the right thing.

ok. if you have the context on it, would you mind opening the issue?

Well, I’m still unclear why that would be an issue. And I still believe that when you set

--platform

,

--interpreter-constraints

no longer apply. We had that wrong originally, and it took John walking me through it to fix that in Pants.

https://github.com/pantsbuild/pants/pull/10323 is also potentially relevant.

Hey Maryanne, I’m going to try to reproduce this tomorrow/today and figure out what’s going on. Are you able to please share a little more about your environment, eg which Linux version and the output of

which -a python

? This is Pants 1.28, right? It’d also help if you can share the constraints file if y’all are able to, even if some of it is stripped.