translatenix

In my opinion, it’s important that the Java version/vendor can be changed in a single place. For example, I often use this to reproduce a failed CI build.

Perhaps you could add `pklJvmProject.gradle.kts` and apply it in the other files.

How about renaming `DEFAULT_JVM_VERSION` to `JDK_VERSION`? This `val` is what developers will want to find/edit when troubleshooting. I'd also add `val JDK_VENDOR` just in case. I think the project property...

I think `JDK_VERSION` is correct, but mainly I'd like to get rid of `DEFAULT`. `const` is only an optimization, but a vendor `val` isn't essential. System property would be a...

The IntelliJ plugin uses a static analyzer and can only detect some constraint violations. To have the element type checked by the evaluator, you need to write `local randomValues: Listing...

My understanding is that packages are always cached unless `--no-cache` is specified. Nevertheless, something like `pkl project resolve --download` or `pkl download-package` (without arguments) could certainly be useful.

Is there a benefit in keeping resolution and download decoupled? That was the idea behind `pkl download-package` without arguments. If resolution ever becomes non-deterministic, for example due to supporting some...

It’s about actively avoiding resolution, not actively avoiding download. If all I want is to download, I should never have to worry about `PklProject.deps.json` changing as a side effect. According...

I guess I don’t mind if `pkl project resolve` also downloads packages, although I don’t really see the need either. I don’t think it saves much network I/O as packages...

Oh I thought that `pkl project resolve` would just download metadata. If it has to download the packages, it should definitely store them in the cache, at least by default.