-
-
Notifications
You must be signed in to change notification settings - Fork 393
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only pull compile dependencies during compilation #4028
Only pull compile dependencies during compilation #4028
Conversation
Maven offers to add dependencies only at runtime, with its runtime scope. This tries to respect that, by not pulling purely runtime dependencies during compilation.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
@alexarchambault could you elaborate a bit on the problem in the PR description and how you are solving it? Some of the code changes seem pretty non-obvious to me |
@@ -210,7 +210,7 @@ trait KotlinJsModule extends KotlinModule { outer => | |||
outputMode = binaryKindToOutputMode(kotlinJsBinaryKind()), | |||
irClasspath = Some(compile().classes), | |||
allKotlinSourceFiles = Seq.empty, | |||
librariesClasspath = compileClasspath(), | |||
librariesClasspath = upstreamAssemblyClasspath(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
e.g. what does this have to do with compile time deps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just opened #4039 with solely this change, and more comments / explanations. Basically, the PR here aims at bringing less JARs in class paths made for compilation (like compileClasspath
), while the same JARs as currently should be around at runtime.
The linker needs a class path for runtime, so we pass upstreamAssemblyClasspath
instead (that contains all dependencies JARs)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we could have a new dedicated target, like runDependencyClasspath
- with all dependency JARs, including JARs made for runtime, but excluding the current module classes. Or maybe we could just rename upstreamAssemblyClasspath
, given it can have a broader uses.
To expand the PR description, Android dependencies tend to pull more dependencies at runtime, for example. Compile-time:
Runtime:
The PR here only passes the first set of dependencies to javac / kotlinc |
The current code passes a class path made for compile time to the Kotlin JS linker. While it's not a problem with the current main branch that doesn't really make a difference between compile and runtime class paths, this will be a problem with #4028, that can bring less JARs in `compileClasspath` (while all JARs will be around in runtime targets, like `resolvedRunIvyDeps`, like currently)
The current code passes a class path made for compile time to the Kotlin JS linker. While it's not a problem with the current main branch that doesn't really make a difference between compile and runtime class paths, this will be a problem with com-lihaoyi#4028, that can bring less JARs in `compileClasspath` (while all JARs will be around in runtime targets, like `resolvedRunIvyDeps`, like currently)
Maven offers a way to pull some dependencies only at runtime, via [Maven scopes](https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope). Roughly speaking, in Maven, dependencies can be added - only for compilation (`provided` scope) - for compilation and runtime (`compile` scope - `compile` is for both compile-time and runtime) - only at runtime (`runtime` scope) This matters during dependency management: coursier can pull runtime dependencies or not, for example. Mill already knows about compile-time versus runtime, with `compileIvyDeps` / `ivyDeps` / `runIvyDeps`, which are equivalent to Maven scopes `provided` / `compile` / `runtime`. The PR here asks coursier not to pull runtime dependencies in Mill class paths made for compile-time, like `compileClasspath`. --------- Co-authored-by: Li Haoyi <haoyi.sg@gmail.com>
Maven offers a way to pull some dependencies only at runtime, via Maven scopes.
Roughly speaking, in Maven, dependencies can be added
provided
scope)compile
scope -compile
is for both compile-time and runtime)runtime
scope)This matters during dependency management: coursier can pull runtime dependencies or not, for example.
Mill already knows about compile-time versus runtime, with
compileIvyDeps
/ivyDeps
/runIvyDeps
, which are equivalent to Maven scopesprovided
/compile
/runtime
.The PR here asks coursier not to pull runtime dependencies in Mill class paths made for compile-time, like
compileClasspath
.