Now that Amper gets fully decoupled from Gradle, a...

# amper

[Waldemar Kornewald]

Now that Amper gets fully decoupled from Gradle, are there any plans to move to a better configuration language (e.g. .kts files or Apple's Pkl)?
Or will extensions be the only solution for more advanced configuration (which could simplify detecting when to invalidate a build task's cache)?
Will the extensions API provide support for incremental caching?

[louiscad]

Kts files, i.e. Kotlin, will never happen, because it's not a static configuration language, but a Turing complete programming language, which is one of the reasons Gradle is so complicated and needs to run code before the tooling can know anything for sure.

Something else, as was already answered many times I think, could happen, but YAML (with schemas) is what we have for the time being, it does the job well enough for the tooling, and the limited nesting makes it bearable.

As for extensibility and incremental caching, I don't know, we'll see I guess.

[zsmb]

The team experimented with a bunch of different languages (including our own custom one), but so far none of them offered significant benefits over YAML for what Amper does. Maybe as more features get added we'll find a reason to change the language, but so far it works just fine.

[zsmb]

On the incremental part, I'll let them answer 😀

[Waldemar Kornewald]

I would've expected that at least Pkl would naturally come with a solution for merging/overlaying reusable config snippets in a type-safe way. It also allows writing functions for more complex use-cases. Did you give that a try? (note, it offers a Kotlin lib)

[joffrey]

Louis and Márton summarized things really well already.

To elaborate on the extensibility story, nothing is final yet, but we're definitely going to provide support for custom task cacheability as a first class citizen. For more complex use cases, it's always possible to handle more fine-grained caching during the execution phase, by exiting the task early. We will provide primitives for this.

We want to avoid complexity in the "configuration phase" because we want the tooling to be fast and accurate (there might not be a configuration phase at all, rather a simple parsing). Having functions in the configuration language makes this significantly harder. Typically, the configuration becomes harder to modify via automated tooling. Using the full blown Pkl language would cause problems in this respect. That said, we're still not completely closed to alternatives to yaml. With the new challenges brought by the extensibility story, we might revisit the configuration language.

[Waldemar Kornewald]

Alright, that clarifies it. Thanks everyone.