haha, even better

I'm trying to use pex, but it seems to be choking on binary wheels that have a minimum platform in the wheel name.

Is this some known problem?

@creamy-optician-55754: possibly... have you looked at github.com/pantsbuild/pex/issues ?

When making bundles of jvm projects is there a common convention for where to keep configuration files and other things to bundle up?

src/java/org/example/coolproject/{conf,bin}

Or in their own part of the tree?

we don't have a great convention... we define bundles mostly in a bunch of project directories in the root

but that makes it difficult to share config

When I put pants on our ops-y python code I mostly made wrapper scripts in the existing structure that would magically invoke run or use a PEX if present. While good for backwards compatibility our existing structure was pretty haphazard (is it a "tool" or "script"?)

So the java code is in

src

but there is another root with

tarballs/myteam/custom-hard-to-share-build-file

or something like that?

yea

things that are jvm resources are under

src/resources/**/*

but pure-bundle stuff doesn't have a great convention

An O'Reilly book on "Directories and Naming Thing" would in practice be the most useful publication ever

While I have you, down the road do you see pants having a "docker/appc/AMI/container" bundle-like goal? Or would packer (or whatever makes the images) always invoke pants?

if somebody implements it, sure

we have a python wrapper around docker and pants to put a binary into an image

which assumes a bunch of things (like writing into

dist

) but works well in practice

internally here at 4sq, @limited-country-20626 wrote a docker task for pants that we are beginning to use

tdyas: So that's docker invoking pants, not pants making an image?

no, that’s pants invoking docker

complete with a

docker_image

target for BUILD files

I think he’s mentioned it before in this channel

Gotcha. We use https://www.packer.io/ some, which makes docker images, but I think just implements the image format without running the docker client

hmm, as an aside, packer seems similar to Red Hat’s “BoxGrinder” project I used at a prior job (http://boxgrinder.org/ but defunct since 2012)

I feel like I might be missing something obvious. Is it possible to do a make a tarball with a 'fat jar' + resources?

jvm_app

sticks everything in

libs

This used to be possible and probably still is, though the option help is mystifying, see:

-[no-]bundle-jvm-deployjar (default: False) 
Expand 3rdparty jars into loose classfiles in the bundle's root dir. If unset, the root will contain internal classfiles only, and 3rdparty jars will go into the bundle's libs dir.

That said - its also mystifying - to me - why you'd ever want to do this!

More helpful,

./pants bundle.jvm --deployjar [target]

. So the bundle.jvm scope does actually make some sense since bundle applies to other, non-jvm, backends where

--deployjar

makes no sense.

In pantsbuild itself you'll find:

./pants bundle.jvm --deployjar --archive=tar src/java/::
find dist -name "*.tar" -print -exec tar -tf {} \;
dist/src.java.org.pantsbuild.tools.jar.main.tar
./
./jar-tool.jar
dist/src.java.org.pantsbuild.tools.junit.main.tar
./
./junit-runner.jar
dist/src.java.org.pantsbuild.tools.runner.runner-binary.tar
./
./pants-runner.jar
tar -xf dist/src.java.org.pantsbuild.tools.jar.main.tar
java -jar jar-tool.jar -h | head -2
Usage:
 TARGET_JAR [-classpath=<CLASS_PATH_ENTRY,CLASS_PATH_ENTRY,...>] [-compress=BOOL]...

need to fix the help, now we treat internal jars and 3rdparty jars the same way, i.e, "If unset, the root will contain internal classfiles only" is no longer true, internal jars are also under libs, this is because even non-fat jars are getting bigger