discussion: How to maintain different frontend language versions

[gaocegege]

Description

#1228

---

Message from the maintainers:

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

[cutecutecat]

If we split envd to three repos: frontend + backend + user:

• frontend: maybe envd-lang, only do the conversion from starlark to llb. Compatible with any version of backend
• backend: maybe envd-core, a llb execution engine. **Most bugs happen here. **
• user: maybe envd-client, a user interface client like src/app, it could dynamically pick version of frontend, and have a dependency of backend,

Then we are able to maintain only one backend and one user, with several branch or tag of frontend. As there might not so many changes in frontend, the cost of maintenance maybe not so huge.

[kemingy]

If we split envd to three repos: frontend + backend + user:

* frontend: maybe `envd-lang`, only do the conversion from `starlark` to `llb`. Compatible with any version of `backend`

* backend: maybe `envd-core`, a llb execution engine. **Most bugs happen here. **

* user: maybe `envd-client`, a user interface client like `src/app`, it could **dynamically** pick version of `frontend`, and have a dependency of `backend`,

Then we are able to maintain only one backend and one user, with several branch or tag of frontend. As there might not so many changes in frontend, the cost of maintenance maybe not so huge.

I agree that we should decouple the starlark frontend from the real LLB graph.

However:

• There is no such kind of LLB execution engine in envd. The implementation is more like rule-based compile process based on the Graph (actually a key-value map). Refer to proposal(ir): state based implementation #972
• We should not split it into 3 repos. That will introduce overwhelming overhead.
• Dynamical linking works if and only if we have a clean decoupling design. But underlying, there should be several branches for different major versions.

[gaocegege]

Personally, I prefer to support two lang versions in one release.

Because users may need to support existing build.envd, and investigate if v2 is better.

dockerfile frontend uses the image docker/dockerfile to implement this.

When you write

# syntax=docker/dockerfile:1

The docker builder pulls the docker/dockerfile:v1 and uses this image to parse the language and get the LLB states.

In this approach, the starlark and the backend implementations are all in a separate image.

[kemingy]

Personally, I prefer to support two lang versions in one release.

What do you mean in one release?

The docker builder pulls the docker/dockerfile:v1 and uses this image to parse the language and get the LLB states.

Does that mean the latest code doesn't contain anything specified to v1? Is it just an old image?

In this approach, the starlark and the backend implementations are all in a separate image.

Do you mean docker images? I don't get it. Why do we need multiple images for a CLI?

[gaocegege]

I mean one CLI for multiple versions.

[gaocegege]

We decided to keep two versions in envd. And a new comment will be introduced to tell users which version is using.