Closed IzakMaraisTAL closed 11 months ago
@IzakMaraisTAL,
Thank you for reporting this issue. I was able to replicate different versions in default python and pip environment in TFX 1.14 and TFX 1.15 dev images.
@roseayeon, Different python version in default environment(py 3.8) and pip environment(py 3.10) is causing this issue. Please have a look. Thanks
@IzakMaraisTAL,
Can you try using the latest TFX image. We have updated the docker image and recompiled and re-uploaded the newly-built docker image (from v1.14.0) to the DockerHub with "latest" tag. Ref: screenshot below
Please try out the latest image and let us know if you face any issues. Thank you!
On a side note... I imagine the image can be made smaller by removing one of the python versions from the image?
$ docker run --rm -it --entrypoint= tensorflow/tfx:latest bash -c '
python_A=$(python -V)
python_B=$(python3 -V)
conda init bash &> /dev/null
. /root/.bashrc
conda activate base &> /dev/null
python_C=$(python -V)
python_D=$(python3 -V)
echo python_A=$python_A
echo python_B=$python_B
echo python_C=$python_C
echo python_D=$python_D
result:
python_A=Python 3.8.18
python_B=Python 3.10.12
python_C=Python 3.8.18
python_D=Python 3.10.12
(Notice how both 3.8 and 3.10 is present in the image)
@singhniraj08, I have tested and can confirm that pip list
and pip install
work as expected in tensorflow/tfx:latest
: dependencies are installed into the same environment used by TFX.
Thanks for the fix!
On a side note... I imagine the image can be made smaller by removing one of the python versions from the image?
(Notice how both 3.8 and 3.10 is present in the image)
Since image size is contributing to https://github.com/tensorflow/tfx/issues/6386, this might worth considering.
@IzakMaraisTAL,
Thank you for the confirmation and feedback on TFX docker image size issue. I will pass this feedback internally to the team we will be working on the fix.
Since this issue is fixed for you, closing this issue. Please feel free to reopen and post your comments(if you still have queries on this). Thank you!
Hi the problem persists with the gcr.io/tfx-oss-public/tfx:1.14.0
image provided in Container Registery @singhniraj08
@Saoussen-CH,
The fix for this issue was introduced in tensorflow/tfx:latest
image and will persist in tfx:1.14.0
image. Please try using tensorflow/tfx:latest
image and let us know if you face any issues. Thank yoU!
Hey, @singhniraj08
Yes I know, but not on the gcr.io/tfx-oss-public/tfx:latest
provided in GCP as on Container Registery, which I am guessing was based on the old version of the tensorflow/tfx:latest
before the fix.
I am just letting you know, so you can pass the message internally and get it fixed.
Thank you.
@Saoussen-CH, Thank you for bringing this up. I raised a PR #6401 with fix which is already merged. This should reflect in upcoming TFX release image. Meanwhile if this is blocking you, you can build a image from Dockerfile by following instructions as shown here.
System information
Describe the current behavior
Pip in the TFX 1.14.0 Docker image uses the wrong python version.
This breaks our workflow of using this image as a base image and adding packages with pip, since the installed packages end up in the wrong environment. It also breaks
pip list
, which is needed to install compatible dependencies. This workflow is crucial to running custom components on vertex. Also for running standard components, like Transform with new dependencies liketensorflow_text
.It also breaks
tfx compile --engine=kubeflow|vertex
inside the container, since the tfx cli uses subprocess to call out to pip to check thatkfp
is installed.Describe the expected behavior
Pip in the docker container should install / reference the default python version used in the container.
Standalone code to reproduce the issue
Start with looking at the
pip list
output. In 1.14 it is missing a lot of dependencies:In 1.13 these where correctly listed:
We see this is because the default pip references the wrong python envronment. The default python is 3.8:
But pip references 3.10:
In the 1.13 image, these are the same:
Possible Workaround
In our Dockerfile we work around this by patching the
pip
script to reference the correct python: