```❯ kotlin --help WARNING: Found a project.yaml i...

# kotlin-toolchain

[James]

❯ kotlin --help
WARNING: Found a project.yaml in '.../Projects/tools.logfmt', but the wrapper script is missing; using Kotlin Toolchain v0.11.1.

How do I disable this warning?

[James]

set -Ux KOTLIN_CLI_WRAPPER_ALWAYS_USE_INTRINSIC_VERSION 1

In my fish config solved it

[joffrey]

But why don't you generate the wrappers for your project instead? You can use kotlin update --create to generate them

[James]

First thing I do is to add them to my .gitignore and delete them locally. Same with gradle wrapper 😅

I'm not a big fan of putting wrapper scripts into version control.

[James]

Also, our repository uses .sdkmanrc

[joffrey]

The wrappers are the source of truth for the Kotlin Toolchain version at the moment, so IDE support will not work without them, and changes to your global installation might affect your project

[James]

Mmm.... Rip.

[joffrey]

Deleting them is equivalent to deleting gradlew , gradlew.bat, gradle-wrapper.jar and gradle-wrapper.properties (I don't know if that's what you usually do)

[James]

Yep, I do that.

I delete gradle/

and gradlew and gradlew.bat. Works fine

[joffrey]

Then on CI you have to install a Gradle / Kotlin Toolchain

[James]

Correct

[joffrey]

And everybody else cloning the project isn't guaranteed to use the proper version of the build tool

[James]

sdk env solves that

[James]

That's the conventions we use.

[joffrey]

I see, thanks for sharing!

[joffrey]

We're considering putting the Kotlin Toolchain version in the project.yaml file, so any wrapper/global installation can be sure to use the correct distribution

[James]

That'd be cool!

There's so many ways to do version pinning nowadays as well, the latest one I've seen is .<tool>-version . Which we do as well internally for CI version pinning for things that are not supported by sdkman.

[James]

I was gonna swallow the pill and use wrapper scripts for this project, but:

ERROR: Kotlin wrapper scripts cannot be updated because a directory with a conflicting name exists: /.../tools.logfmt/kotlin

I named the directory kotlin to put the module templates in.

Do you have any suggestions for what else I should call the directory that would be more conventional and not conflict with others?

[joffrey]

Maybe templates? We're actually also considering a place to put templates, and the name is a topic in itself.

[James]

templates is a bit generic 👀

[joffrey]

But it's local to your project. Maybe build-templates?

[joffrey]

Seems aligned with build

[James]

Agreed