Kotlin-dsl-samples: Find a better build filename convention

[sdeleuze]

Note: I changed the issue scope after @oehme feedback.

Currently we need to specify explicitly build filename via a rootProject.buildFileName property in settings.gradle. And the default seems to use build.gradle.kts filename, which is from my POV not very clean looking due to the 2 dots. I do think gradle.kts would be a better filename.

gradle.kts is shorter, more elegant, and clearly communicate that Kotlin build files have first class support and are not a 2nd class extension of the Groovy ones. It is also consistent with gradle.properties.

[oehme]

Just to clarify: We don't plan to introduce any scanning in Gradle. Gradle always has an explicit build file per project.

The regex pattern is only used by the IDE to decide what files are Kotlin-Gradle files.

[sdeleuze]

I created a Twitter poll https://twitter.com/sdeleuze/status/804315252003323904

[sdeleuze]

Somebody asked why not build.kts https://twitter.com/dwursteisen/status/804322132129968133, and that's a good question ! To me build.kts would be fine as well, I just thought gradle.kts would have more chance to be selected because it clearly express that's a Gradle project, and not for example a Kobalt one or another build tool based on Kotlin. And it has also the advantage to allow using *gradle.kts pattern for IDE and tooling detection of Gradle build files while allowing foo.gradle.kts or foo-gradle.ktsfor people who like distinct names like @oehme, while being compatible with existing build.gradle.kts build filename.

[melix]

I don't think that's an issue we can simply fix with a Twitter poll :) There are several reasons for this extension. First of all, for Groovy/Gradle build files, the file name is build.gradle, but you can write compile.gradle or docs.gradle, ... So there's no limit to the base file name. It is even possible to apply from an arbitrary file name:

apply from: 'a.b'

So technically speaking, the .kts extension allows us to make the difference between a build file written in Groovy and a build file written in Kotlin. It also allows the IDE to understand that a build file is written in Kotlin (because it ends with .gradle.kts).

Now say we use gradle.kts. Then it would work as a replacement for build.gradle, but it has disadvantages:

• it doesn't make the distinction between a build file (gradle.kts) and a regular Kotlin script file (foo.kts).
• if you want a different file name, and you will need one, you will have to use compile.gradle.kts, so again the double extension.

Another option would be to use another extension, not .kts, but something else (.gradlek, .gkts, ...).

[sdeleuze]

@melix my proposal is to use gradle.kts as a default filename, but also to use *gradle.kts as an IDE/tooling filename pattern to allow people using foo.gradle.kts or foo-gradle.kts in addition to gradle.kts.

[melix]

I get it, but then the "2 dots" argument doesn't stand. Assuming fdkjjfgradle.kts is a gradle build file doesn't make me happy either.

[sdeleuze]

Hum, ok so based on your reasoning, the specific extension is maybe something that make sense.

That would make IDE happy, provide better/shorter/meaningful filenames compared to this strange (to me at least) double extension .gradle.kts even with custom build filename use case.

The main drawbacks is that it would make using a specific extension while it is a valid Kotlin Script file in term of syntax, but I tend to think that's a better tradeoff than the foo.gradle.kts convention which can be understood as foo.gradle with ktsextension or foofile with gradle.kts extension.

I guess it is also about finding a relevant extension ... .kradle should remain a joke I guess ;-) I will try te see if I come up with a better idea than .gradlek and .gkts.

[bamboo]

It's also worth noticing all the tooling we get for free by leveraging the .kts extension. Just imagine not having syntax highlighting on GitHub for build scripts written in Kotlin.

[melix]

Yeah, however I imagine it wouldn't be too hard (and I think it's actually already doable) for the IDE to recognize an additional extension.

• .kt for Kotlin classes
• .kts for Kotlin scripts
• .ktg for Kotlin Gradle builds?

[sdeleuze]

Make sense

[SourceNode]

No expert on Kotlin, but from my outsider point of view, Gradle build scripts should always end with .gradle. Obviously, the content of the build script would change if you were Groovy-based or Kotlin-based, so you would need something to distinguish between the two _inside the file_. So, why not just require Kotlin-based build scripts to have the first line of the file indicate it. Legacy scripts would not have this, so could be assumed to be Groovy. This problem is not going to stop with Kotlin . You will likely add support for other languages over time, so I imagine you wouldn't want to create a new extension every time. I've never liked making assumptions about the content of a file based on a file extension, but I suppose this is why MIME types exist. Anyway, when the solution isn't obvious as seems the case here, rethink what problem you are trying to solve. Maybe this won't work for tooling though...

[sdeleuze]

@bamboo .kts files handling is something really recently introduced so you don't have to deal with a huge number of historical tooling that won't evolve + it seems to me that even if Gradle build files follow .kts syntax, it requires special handling by IDE to import by default some Gradle stuff or something like that, so that's not really a raw .kts file.

So I given all the pro and cons discussed here + the fact that almost every developer I have talked with seems to dislike the double extension trick in build.gradle.kts, I hope another solution will be found.

build.ktg is a solution that would be nice I think, if you think build.kts is not enough Gradle specific name and if you don't like gradle.kts.

[benedictleejh]

I'll second @SourceNode's position that, ideally, Gradle build scripts should always end in .gradle, and there should be something like a shebang in the build script to differentiate between different script languages. The absence of the "shebang" ("shebang" because you may not want to use the Unix shebang #! directly) could default to assuming the script was written in Groovy, for backward compatibility.

On the tooling side, if I remember correctly, IntelliJ can detect the file type for extensionless scripts using a shebang, so that could certainly be adapted to be used here.

[sdeleuze]

Indeed if that's doable, .gradle extension + shebang would be great.