Provide a proper settings plugin instead of relying on a remote script

[rnett]

Applying a Gradle "plugin" via including a script (i.e. apply("some file") is frowned upon for a variety of reasons, including the lack of versioning, lack of dependency management (i.e. locking, or hosting in your own repository), and making build script compilation avoidance harder.

I don't see anything in your settings script that would be impossible to do via a settings plugin. For that matter, I don't see what value the settings plugin provides - it's easier and much better practice to just add the build plugin yourself.

[y9vad9]

I personally think introducing a settings plugin just to solve this particular problem might be overengineering it — especially considering that solution #2 (once implemented) might make it unnecessary altogether.

Instead, I’d recommend going with the tried-and-true approach: define your dependencies and plugins in libs.versions.toml. It’s lightweight (usually no more than ~5 lines) and gives you full control. You can also look at the hosted script and published Gradle version catalog for reference if needed.

That said, applying Elide at the project level (rather than per-module) could indeed help reduce duplication. Even though this can already be addressed with precompiled scripts.

[rnett]

I agree with all of that, using a version catalog and whatever mechanism they already have in place for sharing plugins across projects is likely to be the easiest approach for most consumers.