but your error shows it bootstrapping a JDK8… and at some point you got JDK11 (perhaps via

--system

)

So the JDK11 would be coming from the compilation phase

yes. but the JdkSetup is a singleton, so everything should be using the same one.

it’s definitely a bit of a dodge (since the mismatch shouldn’t be possible at all), but: you should remove the

--javac-jdk=system

option there anyway

the relevant issue was fixed.

i expect that that will work around this, and we can track down mismatches outside of CI

Oh, yes, that would do it.

oh, actually: i think you’re also holding it wrong, maybe?

should use

jdk_setup.args(..)

to build the args to use.

(it should be equivalent, but…?)

oh, and should be using the

jdk_setup.append_only_caches

jdk_setup.args()

hadn’t been used in other cases, so that’s useful

ok

here is a good minimal example: https://github.com/pantsbuild/pants/blob/403bfc02767533eb0eef1d74a243bc020bde5bed/src/python/pants/backend/java/util_rules_test.py#L41-L60

I think I’ve got it

As part of https://github.com/pantsbuild/pants/pull/12955, we are trying to figure out how to allow configuring Pants to download a tool automatically while also allowing configuring use of a system-installed tool. One idea that I had is to make tool configuration into a target type. Any thoughts/comments on that approach? 1. This is what Bazel does with its notion of a “toolchain”: https://docs.bazel.build/versions/main/toolchains.html 2. A benefit of having tools be targets is that they can become (inferred) dependencies of code-related targets. For example, the Go SDK could be a target type and made a dependency of

go_mod

targets. This would allow multiple Go modules in a repository to use different Go SDK versions (or options to those SDKs) by specifying a different “go_sdk” target.

I never realized how badly I needed Python list splats until I actually started using them. It says in one character what I often had to say using a local

foo_iter()

generator

Hi, I am noticing this on my ubuntu machine:

Thoughts on changing

Paths.dirs

and

Snapshot.dirs

to only include the dir names where there was a match? if you have only the

file some_dir/subdir/f.go

and the glob

**/*.go

, it will include 

some_dir

when I only want 

some_dir/subdir

I’ve spent some time thinking about named resolves, the first part of which involve us somewhat inverting the way we approach lockfiles. Current we do this: 1. Write JVM artifacts 2. Add those artifacts as requirements to the lockfile 3. Resolve artifacts and their dependencies and write to the lockfile 4. Supply the lockfile as a dependency to the Java Sources AIUI, we need to change it so that the 

coursier_lockfile

 target does not have requirements, but instead, we infer those requirements based on the artifacts that are dependencies (inferred or otherwise) of 

java_source

 targets that depend on the lockfile. That needs dependency inference over 3rd party dependencies (and potentially having those present before a lockfile is ready) Is dependency inference at a stage where we can look into dependency JAR files to see if a dependency is present? (ping @fast-nail-55400)

https://docs.google.com/document/d/1sr1O7W9517w8YbdzfE56xvDb72LafK94Fwxm0juIRFc/edit# has some details on how we might expect to find the coordinates to use in a particular resolve

dependency inference is relevant to this, because dependencies are relevant to this… but even before inference for 3rdparty deps is working, you should probably assume that dependencies on 3rdparty libraries have been explicitly specified in BUILD files

that’s fair enough

ftr though: inference will probably not be able to fetch jars in order to determine their contents, precisely because at that point we haven’t done a resolve to know what they might contain. on the Python side, this is what the

module_mapping

is used for for requirements

The difference in JVM land being that listing the files inside a JAR will give you a full and accurate list of symbols that the JAR provides

ditto python land

but like in Python land, during dep inference, you’re trying to find the deps, and the deps influence the resolve, and the resolve influences what is in the fetched artifacts

and you can’t know the contents of the artifact before knowing which version of the artifact you’ll get.

In the case where you’re producing a lockfile, though, you can afford to resolve the

jvm_artifacts

knowing that you’ll be immediately writing a subset of them of the lockfile

not necessarily: conflicts with other 3rdparty dependencies mean that you may not get the declared version.