Provide option to enforce Python Runtime version via env_decorator / setup.py

[jiyer2016]

Is your feature request related to a problem? Please describe.
I use my own Docker Base Image which I know can be customized via the docker_base_image arg in the "env_decorator"
However, I am still unable to use BentoML's autogenerated DockerFile - since my environment's build process restricts me from using the COPY command in a Dockerfile:

COPY . /bento

I need to use my own custom written Dockerfile.

I notice the comment below - where the onus on the user to ensure that the python version in the docker image matches that of the BentoService bundle

        docker_base_image: used for customizing the docker container image built with
            BentoML saved bundle. Base image must either have both `bash` and `conda`
            installed; or have `bash`, `pip`, `python` installed, in which case the user
            is required to ensure the python version matches the BentoService bundle

Describe the solution you'd like
In my situation where I'd like to use my own custom written Dockerfile - I'd like to propose a mechanism to enforce specific versions of the Python Runtime
Could we have a facility where the python runtime version can be specified via the "env_decorator".
Something like:
@bentoml.env(python_requires='~=3.3')

This setting could be carried over into "python_requires" in setuptools.setup

import setuptools

setuptools.setup(name="my_package_name",
                           python_requires='~=3.3', 
                           ...)

A pip install will then prevent the package being installed on incompatible python runtimes and hopefully fail-fast my custom docker build process - Reference Link

Describe alternatives you've considered
None

Additional context
None

[parano]

Hi @jiyer2016, thanks for the feature request.

BentoML by default uses the Python version of the Python session where the saved bundle is created. This ensures it reproduces the exact same environment and avoids problems caused by the differences between python versions.

That being said, if you run the BentoService#save call from python 3.3, the saved bundle will have that information in the bentoml.yml file. I don't feel it makes sense to expose this parameter for users to change the python version since you always want to use the same python version across training and serving.

If you want to use a specific python version in your docker image and you can't ensure all training code runs on the desired python version - I'd recommend use a docker base image that does not have conda and install the desired python version in this base image. That way, BentoML won't try to install the python version specified in bentoml.yml(bentoml does this via conda and skips this if conda is not presented in the base image).

Hope that makes sense, let me know if I misunderstood your request.

[jiyer2016]

Can bentoml (by default) create the setup.py such that the call to setuptools.setup() includes the version of the python runtime from the training environment (in the python_requires parameter)?

That will ensure the pip install fails-fast if the python version in the runtime drifts too far away from that of the training environment.

I feel that may be particularly useful in environments that don't use conda OR can't use the auto generated Dockerfile (like my case)

[parano]

@jiyer2016 got it, that's a great idea and definitely doable since we already have the python version information during save and it should be straightforward to add that to the setup.py.

I think I understand your original request to add a python_requires='~=3.3' parameter better now and I start to think it's a really a great idea:

It could be dangerous if the user didn't test the compatibility well between different versions. And some of the libraries used may also behave differently across different python versions especially when it comes to model serialization or deserialization.

But for advanced users, the benefit is obvious: fail fast when python version mismatch(pip install, docker build with custom base image), much faster docker build when the python version in the docker matches the requirement and it skips installing the exact python version via conda in every docker build.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.