Hello Pants Developers, I just sent an email out to pants-devel@, but I wanted to make sure I copied the information here for any that might miss that. At the summit Patrick and I mentioned that we were working on fleshing out and open sourcing an in-house distribution format we have called Vex. The actual details of what it is and how it works remained an unanswered question after the summit. So I started writing up a comprehensive design doc which I'm finally ready to share with you all here: https://docs.google.com/document/d/11EvbyvahZBhzseo5IHXvZdm-T-Kt95Bmi8T5m8taCuA/edit?usp=sharing That design doc covers every possible detail I could think of about the design and implementation of Vex, and hopefully answers any questions anyone might have. Of course, you are invited to comment with any further unanswered questions you might have and make suggestions for further work!

sweet

@silly-article-89931: This is very interesting! Are any of the components okay to share as is (i.e. in something as simple as a gist or email patch)? I’d be interested in looking at wheelwright.sh specifically

@ancient-stone-50795: just got out of a meeting with our VM team about source/target/bootclasspath... we really need to be shipping the appropriate bootclasspath for each version

@ancient-stone-50795: it would be good if you guys could either hold off on 2494, or design that in

@mammoth-autumn-2551: Here is a gist of wheelwright: https://gist.github.com/patricklaw/32292c528b17f9eb73f9 If you want to see more of the actual vex source, I can share a link to a review of it on RBCommons, but it’s not cleaned up and necessarily in its final reviewed state just yet (not ready for a full review yet).

@silly-article-89931: This is perfect for me now— thanks!

@witty-crayon-22786: I think @jolly-chef-92794 is thinking about bootclasspath

@witty-crayon-22786: handling bootclasspath (for compilation at least) is included in https://rbcommons.com/s/twitter/r/2494/

@jolly-chef-92794: nice...

@jolly-chef-92794: apologies for not reviewing.

@jolly-chef-92794: one quick bit of feedback... the

target

and

compile args

must always match (iirc)... so allowing them to be set independently is probably redundant

but also, having the different "platforms" configured in a single place and then referred to from the targets would make more sense to me

otherwise i'd expect a lot of copypasta

Yeah, in our internal repo to test this I added a plugin that wraps up this information that the other targets point to, but I wasn't sure whether I wanted to include it upstream because it felt a bit hacky. I made a build file alias for

compile_settings(name, source_level, target_level, compile_args)

which looks like a target, and gets registered in a global dictionary. I stuck these in our top-level BUILD file after our source roots, and referred to them in targets like:

java_library(name='foobar',
  target_level=compile_settings('1.8').target_level,
  source_level=compile_settings('1.8').source_level,
  compile_args=compile_settings('1.8').compile_args,
)

Which seems kind of ugly, though it gets around the worst of the copypasta.

Maybe I could make a formal

java_compile_settings

target which just stores information, and then have jvm_targets optionally take in

compile_settings=':foobar-settings'

, and resolve and extract data from that.

Why is that a target at all?

It seems like it just represents a bucket of config

Yeah; it would only be a target for convenience in being able to refer to by spec.

hmmmm

Alternatively it could just be a named object stored in a global dict somewhere

This feels sort of subsystem-ey

Yeah, and if your whole codebase was uniform, or at least the majority of it, it would be nice to set the default in pants.ini

i'd recommend moving it into a subsystem

which defined the "names" of each platform

("jdk8", "jdk8-with-custom-bootclasspath") etc

because while i recognize your need to allow for customization, allowing for ALL parameters there is terrifying

@witty-crayon-22786: We separate out ‘target’ from the other compiler args already in config options java_compile. I considered it a possible omission that we don’t do this in zinc-java-compile.

I too like the idea of being able to reference a bucket of config by name. We could put this in the jvm subsystem.

yes please.