Compatible wheel package determination ignores py2/py3 designation

[aws]

Compatible wheel package determination ignores py2/py3 designation

[jasonmk]

After further investigation, it looks like this might be able to be worked around by using a python3-only virtual env. I was hoping to avoid this in case we had a project that used both python2 and python3 functions, but in retrospect that would probably break completely anyways.

Apparently, even though I had python36 as my default python and was using the python36 runtime, aws-sam-cli was still hard-coded in my install to run under python27 and as a result was using pip2.7. Would it make more sense (or even be possible) to have the lambda-builder use the version of pip that matches the runtime version rather than the version matching sam-cli?

[jfuss]

@jasonmk Thanks for the detailed issue!

What OS are you running on?

We are adding some improvements in this area in #55. We (SAM CLI) pick the first python in the PATH, the PR will be adding support for picking the first executable in the PATH that is validated. From SAM CLI, you can also use the --use-container option that will run the build in a container. This will ensure the correct python version is used. It is slower but does give you another path forward. You can also muck with your PATH but I tend to just do the --use-container until we have #55 merged and released.

[jasonmk]

This is CentOS 7. I had tried it with a container but got a different error. However, that seems to be working now so it's possible I had the same cross-contamination issue there as well.

Definitely a lot slower....

I almost wonder if it wouldn't make more sense to treat python the same as node or ruby. Don't make any assumptions about anything (first in the path or default versions etc) and specifically look up the commands for the runtime in use. That would have the advantage of also letting you combine python2 and python3 functions in the same project without using containers. (I'm actually against using python2 at all for philosophical reasons, but I'm sure people out there do it.)

[jfuss]

#55 will get you that flexibility (authored by @TheSriram). Python was the first one written and we are heading towards a more robust way of resolving the executables across all runtimes supported.

"(I'm actually against using python2 at all for philosophical reasons, but I'm sure people out there do it.)"
But you installed SAM CLI in Py2 :(

[jasonmk]

Not on purpose. I try to always keep python3 as the default, but apparently something got messed up. I'm not a python developer by far so I get confused a lot switching around between the system default and what I'm trying to use for my projects....

[jfuss]

I think this issue is a duplicate of #11 and #30. This both should be captured by PR #55. I am inclined to close in favor of the ones we have open.

On the installation, for linux we provide LinuxBrew as an installation mechanism. We are considering expanding this to Snap as well. Either would help in keeping you system sane and get you off Py2.

[jasonmk]

Never heard of linuxbrew. Snap wasn't CentOS compatible last I checked, but I know they're working on it.

Feel free to close if it's covered. I'll keep on eye on 55.

[sriram-mv]

@jasonmk Yes #55 should help you to run build with the appropriate python executable that matches your runtime.

[CoshUS]

Closed as #55 is merged.