bug: [bentoml-cli] build failed: Distro is required, got None instead.

[sujan-ml]

Describe the bug

when bentoml build, this error occurred. Today I moved to BentoML==1.0.11
it was fine with BentoML==1.0.10 when tried last.

To reproduce

bentoml build

Expected behavior

No response

Environment

bentoml: 1.0.11
python 3.8

[mqk]

For more context, this is presumably occurring because we're using a custom docker base image. Our custom base image starts with FROM python:3.8-slim. Do we need to set an envvar or something to let BentoML know what distro this is?
`

[mqk]

I've tried specifying distro: "debian" in the bentofile.yaml, and that seems to have gotten me past this particular error (but I don't think this is a good long-term solution), but then I run into another issue that seems familiar:

bentoml.exceptions.InvalidArgument: Invalid build option: docker.python_version="None", python version must follow standard python semver format, e.g. 3.7.10 

This is a result of docker.python_version ending up as a string "None" (not None), and that causes the version validation to fail. I swear we previously solved for this issue, but I can't find where or how.

[mqk]

Found where that python_version issue was previously fixed: https://github.com/bentoml/BentoML/pull/2623/files

[mqk]

So yeah, this is a regression: cd2d2ea

By getting rid of those t.Optional[str] you've undone the fix from the PR I linked earlier, and that causes a build problem for users of a custom base image. @aarnphm

[mqk]

I've confirmed that when I restore those t.Optional then I can get the bento to build. Note that I still have to provide distro: "debian" in order to get past the original issue reported here. That's undesirable (imo). Maybe we could use a value of "custom_docker_image" (or similar) for DockerOptions.distro when a custom docker image is used, and then we could add a dummy entry in CONTAINER_METADATA?

[aarnphm]

Hi there, this #3329 should address the regression.

[mqk]

Awesome, thanks! So I should close the PR that I submitted, correct?

[aarnphm]

yep

[aarnphm]

This has been addressed in 1.0.12