If I have a Kotlin gradle script file that I want to apply to a project `./gradle/deps.gradle.kts` ,...

# gradle

[spierce7]

If I have a Kotlin gradle script file that I want to apply to a project ./gradle/deps.gradle.kts , do I have a way of statically accessing the file’s classes it defines externally in another kotlin file where I do something like this:

plugins {
  `kotlin-dsl`
}

buildscript {
  apply {
    file(File(project.rootDir, "gradle/deps.gradle.kts"))
  }

  dependencies {
    classpath(Plugins.kotlin) // Unresolved reference error
  }
}

[octylFractal]

I don't think so, generally the recommendation is to use buildSrc for that

[octylFractal]

but buildSrc won't work for the buildscript block in particular, but you could instead declare that classpath dependency as an api dependency of buildSrc

[spierce7]

I had all my dependencies setup in a file inside my buildSrc , but now I’m trying to add some extension methods for the multiplatform plugin inside of buildSrc .

The file I posted above is actually the ./buildSrc/build.gradle.kts file.

It’s important for circleci caching reasons that I have all my dependency information inside a single file, and I’m trying not to duplicate my kotlin version into 2 locations.

[octylFractal]

curious as to why you're adding the kotlin plugin to the classpath there then

[octylFractal]

kotlin-dsl already applies one version

[octylFractal]

and the plugin applied to buildSrc is irrelevant for the one applied to the project

[spierce7]

I want to be able to access the multiplatform plugin classes, so that I can add some extension methods for the plugin to my buildSrc

[spierce7]

If you know of a better way - I’m open

[octylFractal]

right, but that means it's a regular dependency of the buildSrc project, i.e. use the normal dependencies {} block

[spierce7]

oh - good call

[spierce7]

I still have the same problem though - don’t I?

[octylFractal]

yes, but if you can manage to parse the file instead, then at least that works somewhat

[octylFractal]

iirc. buildscript is more strict on what can be placed inside it

[spierce7]

my plan was to move my dependencies file to a file that could be applied

[spierce7]

that doesn’t appear to work though

[octylFractal]

if you add the dependencies in deps.gradle.kts instead, it might work

[spierce7]

whats what I’m trying

[spierce7]

I’m not getting any static resolution of the classes defined in those files when applied though

[octylFractal]

right, you can't get the classes from inside

[octylFractal]

what I'm saying is to call dependencies {} in there

[spierce7]

I’m not 100% sure - but am I required to define things on the ext, to gain access outside of there

[octylFractal]

then you don't need the class

[spierce7]

oh - I can’t do that. My team has like 50 modules

[spierce7]

that’d get to hairy I think - assuming I’m understanding you correctly

[octylFractal]

yea, probably

[spierce7]

I guess my best option is to duplicate the logic, and just explicitly declare the dependency here?

[octylFractal]

yea

[spierce7]

😞 Oh well

[octylFractal]

might be a good idea to file an issue with gradle for this sort of use-case

[spierce7]

thanks for your help!

[octylFractal]

it's usually only an issue with the kotlin plugin, but it is a pretty bad pain point

[spierce7]

I’ll do that

[spierce7]

actually

[spierce7]

the entire point is moot

[spierce7]

when applying the kotlin dependency - the entire thing keels over and gives me an exception -

> com/android/build/gradle/BaseExtension

[gildor]

Kotlin is statically typed language, it will not work with dynamically applied script, because there is no way to resolve members of dynamically applied script on compilation time

[gildor]

You can do only something like ext["kotlin"] or properties["kotlin"]

[gildor]

This is an exception related on Android plugin

[gildor]

But overall, it's known limitation of buildSrc.
Overall approach with manual application of version will work if you use dynamic syntax