feat: inherit the runtime graph if the base image was built from envd

[aseaday]

Description

We support the custome image now:

def build():
    base(language="python", image="python:3.9-slim")

And if the user's envd manifest has a custom base image built from envd such as:

def build():
    base(language="python", image="a-company-machine-inf-team-custom-image:latest")

And the base image's envd files may had some runtime configurations as followings:

    runtime.command(commands={
        "test": "ls /",
    })
    runtime.environ(env={"ENVD_MODE": "DEV"})

We should support inheritance so that the new container could has these runtime functions automatically.
It is related to #815 and if this feature prposal was approved by community. I will add this function to #815

---

Message from the maintainers:

Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.

[aseaday]

@kemingy @VoVAllen @zwpaper WDYT?

[zwpaper]

It seems great to me!

I have some questions, maybe we can discuss or explain them in docs

1. https://github.com/tensorchord/envd/pull/815/files proposed RuntimeCommands is not saved, if this feature goes, maybe RuntimeCommands should also be saved?
2. should we add an option to disable(or enable) this inherit?
3. when inheriting, how would we overwrite if new components(RuntimeCommands, Envs, etc.) written in the new build.envd by users?

[VoVAllen]

Thanks for the proposal! Sounds good to me. Also do you have any specific scenarios for this? So that we can understand the pro/cons when implement it.

[aseaday]

It seems great to me!

I have some questions, maybe we can discuss or explain them in docs

1. https://github.com/tensorchord/envd/pull/815/files proposed RuntimeCommands is not saved, if this feature goes, maybe RuntimeCommands should also be saved?
2. should we add an option to disable(or enable) this inherit?
3. when inheriting, how would we overwrite if new components(RuntimeCommands, Envs, etc.) written in the new build.envd by users?

1. It was becuase I misunderstood the meaning of runtime.command, I deleted it now.
2. I think we should had a option in base function to turn it on/off.
3. It is the real question I cared about because I was also confused about that in fact all runtime.xxx functions had no overwrite feature. We can treat base inheritance as a function contains some runtime and how to overwrite is decided by the runtime.xxx's overwrite deisgn.

[aseaday]

A specific scenarios is as the follows:
User Alice is a team member who build a base image for the others especially new commers. He hope the containers could do some followings things automatically:

• update training data to the latest version. runtime.command("dvc sync")
• start the tensorboard and listen on a fixed port. runtime.expose and runtime.daemon

Alice don't want the others users include which means it need to rebuild again. Alice want the base could inherit the runtime feature from parent image directly.

@VoVAllen

[VoVAllen]

I see what you mean. And I realized this can also be a way if users want explicit dependency control. Currently, apt install and pip package install happen in parallel, all on base images. If user want explicit dependency such as python depends on apt packages, your proposal can be a solution