Python3 not configured out of the box.
The lack of Python3 Tensorflow pre-install is somewhat grating. While python2 is still in wide use, Python3 is also widely adopted. My company specifically writes our code in python3 so it was a bit sad to see the container not having support for py3 right out of the box without installing things like pip3 and Tensorflow. This is especially sad because the general ubuntu machine learning AMI supports both out of the box.
The lack of Python3 Tensorflow pre-install is somewhat grating. While python2 is still in wide use, Python3 is also widely adopted. My company specifically writes our code in python3 so it was a bit sad to see the container not having support for py3 right out of the box without installing things like pip3 and Tensorflow. This is especially sad because the general ubuntu machine learning AMI supports both out of the box.

#1
Posted 10/31/2017 12:50 AM   
Our TensorFlow container is currently based on Python 2. We are looking into a version supporting Python 3.
Our TensorFlow container is currently based on Python 2. We are looking into a version supporting Python 3.

#2
Posted 10/31/2017 11:29 PM   
Any timeline for supporting Python3? It is a stopper here, as our codebase is using Python3. Thanks!
Any timeline for supporting Python3?

It is a stopper here, as our codebase is using Python3. Thanks!

#3
Posted 11/01/2017 03:42 PM   
Note that OpenAI switched the whole company to Python3 more than a year ago, this is a blocker for anyone using anything coming from OpenAI. It's not just an issue of "not being configured out of the box". TensorFlow versions are Python specific, so doing "pip install python3" will force you to do "pip3 install tensorflow" but that gets you stock version of TF rather than NVidia.
Note that OpenAI switched the whole company to Python3 more than a year ago, this is a blocker for anyone using anything coming from OpenAI.

It's not just an issue of "not being configured out of the box". TensorFlow versions are Python specific, so doing "pip install python3" will force you to do "pip3 install tensorflow" but that gets you stock version of TF rather than NVidia.

#4
Posted 11/03/2017 04:12 AM   
Why doesn't it support both?
Why doesn't it support both?

#5
Posted 11/03/2017 05:08 PM   
I also am looking for Python 3.6 support. I would take a stab at building my own image, but can not locate a Dockerfile for your Tensorflow 17.10 image. If I had that, I could presumably make adjustments to build a tensorflow module for py3.6 that has the nvidia secret sauce. Could you publish your Dockerfiles somewhere (or, maybe I'm blind and they're already available, but where)?
I also am looking for Python 3.6 support. I would take a stab at building my own image, but can not locate a Dockerfile for your Tensorflow 17.10 image. If I had that, I could presumably make adjustments to build a tensorflow module for py3.6 that has the nvidia secret sauce. Could you publish your Dockerfiles somewhere (or, maybe I'm blind and they're already available, but where)?

#6
Posted 11/07/2017 03:33 AM   
[quote="jamieinfinity"]I would take a stab at building my own image, but can not locate a Dockerfile for your Tensorflow 17.10 image. ... maybe I'm blind and they're already available?[/quote] No, we don't publish those Dockerfiles. Please see [url]https://devtalk.nvidia.com/default/topic/1025790/docker-and-nvidia-docker/dockerfile-/post/5217413/#5217413[/url] for an explanation of why. As for a timeline for formal Python3 support, as @AdamBeberg indicated above, we are looking into this. It's certainly possible to support; the main issue is that we need a bit of time to sort out details of how to do this in a way that's consistent across frameworks. (Right now it's inconsistent; some are Py2 only, some are Py3 only, and at least one has both inside the same image.)
jamieinfinity said:I would take a stab at building my own image, but can not locate a Dockerfile for your Tensorflow 17.10 image. ... maybe I'm blind and they're already available?


No, we don't publish those Dockerfiles. Please see https://devtalk.nvidia.com/default/topic/1025790/docker-and-nvidia-docker/dockerfile-/post/5217413/#5217413 for an explanation of why.

As for a timeline for formal Python3 support, as @AdamBeberg indicated above, we are looking into this. It's certainly possible to support; the main issue is that we need a bit of time to sort out details of how to do this in a way that's consistent across frameworks. (Right now it's inconsistent; some are Py2 only, some are Py3 only, and at least one has both inside the same image.)

#7
Posted 11/07/2017 05:51 AM   
Looks like @kmuchmore posted Dockerfile for building python3 here: https://blog.kickview.com/python3-on-the-dgx/
Looks like @kmuchmore posted Dockerfile for building python3 here:


https://blog.kickview.com/python3-on-the-dgx/

#8
Posted 11/10/2017 10:30 PM   
Thanks for the link @avolkov1! Really hoping official support comes sooner than later. Taking the additional time to configure the container on an AWS instance ends up incurring the users some unnecessary costs.
Thanks for the link @avolkov1!

Really hoping official support comes sooner than later. Taking the additional time to configure the container on an AWS instance ends up incurring the users some unnecessary costs.

#9
Posted 11/14/2017 08:16 PM   
Hi All, Looking for some more feedback on this request. Which option would you prefer and why? 1) Two separate docker containers: One container with python 2.x and one container with python 3.x 2) One docker container with both python 2.x and 3.x included, with a larger container size Appreciate the interest and suggestions! Joey
Hi All,

Looking for some more feedback on this request. Which option would you prefer and why?

1) Two separate docker containers: One container with python 2.x and one container with python 3.x

2) One docker container with both python 2.x and 3.x included, with a larger container size

Appreciate the interest and suggestions!

Joey

#10
Posted 12/20/2017 07:17 PM   
I prefer 1). Having 2 versions of Python causes breakages with things using wrong version of Python unintentionally As a matter of fact, my machine allocation script has the following echo "Python 2 die die die" sudo mv /usr/bin/pip /usr/bin/pip.old sudo ln -s /usr/bin/pip3 /usr/bin/pip sudo mv /usr/bin/python /usr/bin/python.old sudo ln -s /usr/bin/python3 /usr/bin/python
I prefer 1). Having 2 versions of Python causes breakages with things using wrong version of Python unintentionally

As a matter of fact, my machine allocation script has the following

echo "Python 2 die die die"
sudo mv /usr/bin/pip /usr/bin/pip.old
sudo ln -s /usr/bin/pip3 /usr/bin/pip
sudo mv /usr/bin/python /usr/bin/python.old
sudo ln -s /usr/bin/python3 /usr/bin/python

#11
Posted 12/20/2017 07:22 PM   
I agree with @yaroslavvb on option 1), having two versions of python installed creates a nightmare, especially when you need to install or modify any of the framework installs.
I agree with @yaroslavvb on option 1), having two versions of python installed creates a nightmare, especially when you need to install or modify any of the framework installs.

#12
Posted 12/20/2017 08:18 PM   
Separate containers. I've currently built my own image using the existing "FROM nvidia/cuda:9.0-devel-ubuntu17.04" image which works surprising well as a base. Tack on CUDNN 7.x and a rebulid of TF 1.4 or cntk (or in my case, both) and I'm right as rain.
Separate containers.

I've currently built my own image using the existing "FROM nvidia/cuda:9.0-devel-ubuntu17.04" image which works surprising well as a base. Tack on CUDNN 7.x and a rebulid of TF 1.4 or cntk (or in my case, both) and I'm right as rain.

#13
Posted 12/20/2017 08:26 PM   
As a side-note, Amazon Deep Learning AMI images do not have Python 3.5, it's Python 2.7 and Python 3.6 only. So for AWS compatibility I'd prefer Python 3.6
As a side-note, Amazon Deep Learning AMI images do not have Python 3.5, it's Python 2.7 and Python 3.6 only.
So for AWS compatibility I'd prefer Python 3.6

#14
Posted 12/22/2017 12:02 AM   
@yaroslavvb - 3.5 is the one provided by Canonical, so that's (mostly) what it would be. It doesn't actually matter what version is in the base OS, if any, since a the Python in question would ship inside the container.
@yaroslavvb - 3.5 is the one provided by Canonical, so that's (mostly) what it would be. It doesn't actually matter what version is in the base OS, if any, since a the Python in question would ship inside the container.

#15
Posted 12/22/2017 12:18 AM   
Scroll To Top

Add Reply