Other Python versions unexpectedly present

[PeterJCLaw]

I've just tried to switch to the cimg/python image and am getting errors due, I think, to the presence of other Python versions in the image than the named one. (I'm switching because I've also just started seeing this issue with the circleci/python images).

My use-case is admitedly little unusual -- I'm trying to test a script which auto-detects a version of Python to use (preferring newer ones), however previously I was able to rely on the images containing only a single version of Python and thus validate that the script (including its detection) worked on each version of Python.

Here's an example of a failing build: https://app.circleci.com/pipelines/github/PeterJCLaw/srcomp-dev/35/workflows/6cb3cd62-a361-4ae5-822d-f2ba3a1e32c3

Unfortunately I don't know exactly when the issue started as the code in question changes very slowly; it was updated this week for a security update in an package unrelated to the script which is having issues.

Is it expected that on the 3.7 image there is also a Python 3.8 installed? (for example)

[NickAJScott]

I've had the same issues and it seems to be because python3.8.5 is inside /usr/local/bin (we were changing the PATH to include that location and as a result picking up that version rather than the image version which is in /home/circleci/.pyenv/shims/python3)

[amitg-dt]

I'm also getting another version when when using cimg/python (tried with 3.7 and 3.7.12 tag):

!/bin/bash -eo pipefail

pipenv install

Creating a virtualenv for this project... Pipfile: /home/circleci/project/Pipfile Using /usr/bin/python3 (3.8.10) to create virtualenv... created virtual environment CPython3.8.10.final.0-64 in 339ms creator CPython3Posix(dest=/home/circleci/.local/share/virtualenvs/project-zxI9dQ-Q, clear=False, no_vcs_ignore=False, global=False) seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/home/circleci/.local/share/virtualenv) added seed packages: pip==21.2.4, setuptools==58.0.4, wheel==0.37.0 activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

[FelicianoTech]

This all seems to be around PATH. If you manipulate PATH, things can happen.

For the pipenv example, I see if there's something we can do to let it know it's in a pyenv environment.

[PeterJCLaw]

Please note that the original reproduce does not involve modifications to PATH.

[amitg-dt]

This all seems to be around PATH. If you manipulate PATH, things can happen.

For the pipenv example, I see if there's something we can do to let it know it's in a pyenv environment.

I'm also didn't manipute the PATH, the only step before is 'pip install pipenv' Please watch the file system after extracting cimg/python:3.7 - you can see that the python version is 3.8 https://drive.google.com/file/d/1xB2XCDiMovLvhnYwPyM_vBKkDMiJQ0HX/view?usp=sharing

The image digest is f90d693d4a06

[NickAJScott]

Yup my original comment was due to the changing of the path, in the original one it sounds like it's due to the script finding the latest version available (which is the one inside the usr/local/bin folder) whereas the intended one for each version is in the path in the pyenv shims folder. I'm not sure you can expect there to never be a newer version of python somewhere in the image (as they also come with other programs installed e.g. visual studio, which also contains a 3.8 version of python)

[amitg-dt]

I've "Bypassed" the issue by adding python version flag to pipenv.... pipenv --python 3.7 install

[FelicianoTech]

Closing this issue due to lack of activity. I checked the image for Python v3.10.5 and didn't see an additional system Python in that image. Please feel free to open an new issue (and link back to this one) if there is new information.

[PeterJCLaw]

Closing this issue due to lack of activity.

@felicianotech apologies, was there more information that was requested here? From what I can tell the lack of activity is because the community are waiting on a response from the maintainers, though perhaps I am missing something?

For clarity, here's some minimal reproduces (having done fresh docker pulls of the named images):

$ docker run -it --rm cimg/python:3.7 which python3.{6,7,8,9,10}
/home/circleci/.pyenv/shims/python3.7
/usr/bin/python3.8

$ docker run -it --rm cimg/python:3.8 which python3.{6,7,8,9,10}
/home/circleci/.pyenv/shims/python3.8

$ docker run -it --rm cimg/python:3.9 which python3.{6,7,8,9,10}
/usr/bin/python3.8
/home/circleci/.pyenv/shims/python3.9

$ docker run -it --rm cimg/python:3.10 which python3.{6,7,8,9,10}
/usr/bin/python3.8
/home/circleci/.pyenv/shims/python3.10

I would not have expected that Python 3.8 was present at all in images other than cimg/python:3.8 (or at least not on PATH). Could you clarify whether this is expected?

If it is expected, I would encourage documenting that that is the case.