Welcome to toml-schema Discussions! #2
Replies: 1 comment 2 replies
-
Hi Bruno, My name is Cédric Champeau, aka @melix, and I'm working at Gradle on the OSS build tool project. I consider myself specialized in tooling and in Gradle my main focus for the last couple of years has been improving dependency management features of Gradle. As part of this work, we're considering a shareable, consumable version catalog file. You can see this as a tool to provide aliases to GAV coordinates, with, in addition, support for the richness of Gradle's rich versions. This is typically something which cannot be expressed in a BOM. In the team, I am the "champion" of the idea that using TOML to write and share this catalog would be the ideal format. There are different reasons for this:
You can find the full rationale for using TOML in the spec document: https://github.com/gradle/gradle/files/5646826/2020-12-05-Central.declaration.of.dependencies.Shared.externally.pdf However, this is still heavily debated internally. One of the reasons (and to be honest not the main reason) is the lack of support of a schema, which makes IDE completion and validation rather poor. Therefore, I'm particularly interested in such a feature. I'm going to illustrate why I chose TOML with a number of examples, with growing complexity. The simplest file you can write would look like this:
Which basically assigns an alias (
In Gradle, such a simple notation is equivalent to saying "you can use 1.9.9 and anything higher", which is basically the optimistic upgrade strategy. For many people, this is good enough, but Gradle supports a much richer model. In particular, what if you want to express that you need to stay on the Gradle allows you to do this using rich version constraints. In the TOML file, this would then be expressed as:
or:
Basically, what we like about TOML is that it's pretty lean and allows us to support a clean, straightforward syntax for the common use case, and still allows us to build a "more complex" model for richer declarations. The language itself supports this nicely because all in all, everything can be viewed as a flat list of <key,value> pairs. For us it would be important that the schema allows declaring this "either a string or a table of this type or ...". If you want, the equivalent in XML would be to support two notations:
or:
which is arguably more more verbose than the TOML equivalent. Having a richer version model is also important for us in case you want to share version numbers between different modules. For example, assume that you want to use the same version number for all modules of Groovy. You can then write this:
Then in a build script you can write:
the
And done! The catalog file also supports what we call "bundles", which are basically a set of dependencies grouped together:
in which case if you want to add a dependency on both in a file, you can write:
Last, this file is also used to provide plugin versions, which can then be shared by different projects of a single multiproject build:
then applying the plugin in a build script can be done without version:
As I said I'm not asking for any change in the schema proposal, but I think it's interesting to explain our use case, why we chose TOML, and why I think it's important to support, in the schema, the use case of having different options for the values. And I'd like to remember that it's not even endorsed that we would use an external file for this, let alone TOML. Currently the only thing we agreed on is a DSL (Groovy, Kotlin) but I'm pushing hard to simplify with an external file, for many reasons. Thanks for reading! |
Beta Was this translation helpful? Give feedback.
-
👋 Welcome!
We’re using Discussions as a place to connect with other members of our community. We hope that you:
build together 💪.
To get started, comment below with an introduction of yourself and tell us about what you do with this community.
Beta Was this translation helpful? Give feedback.
All reactions