thanks John

@enough-analyst-54434: perfect

./pants help-advanced doc .... not so perfect, took me a while to find the right spelling!

ahh... I forgot to check help advanced

regardless, thanks a bunch!

@limited-terabyte-34878: merged as `a97ce6e`; thanks!

thanks stu!

everyone: welcome @red-cpu-25099 (Timur), who just started for Twitter in London

he's going to start by working on making it possible to locate the

--workdir

outside of the buildroot

I am trying to figure out what happening with options in unit tests. Is it true that for each task in unit tests task.get_options().pants_workdir should be equal to workdir configured in BaseTest?

Yes

ie: /tmp/abc123_BUILD_ROOT/.pants.d

Thanks John. In my case (antlr_gen test) it’s looks in wrong way. And also looks like I got pants_workdir from global_options default. Where can you recommend to start digging from?

Not sure how you work, but I'd be examining that tests setUp hierarchy 1st and then if you're a print guy, use that, if you're a debugger guy, insert pdb breakpoints. I can say I never use pdb so could not be of much help there.

thanks

In antlr gen test Pants creates a synthetic_target that points to generated sources. In my branch generated sources has been created in directory outside of build root, that’s why I’m getting this target points to ../tmp_***_workdir dir. What is the proper way to fix it?

@red-cpu-25099: the sources are probably be relativized to the wrong directory

when you relativize a path to the directory that contains it, it will not begin with

../

one thing that can help to enforce that is to try and use

from python.pants.util.dirutil import fast_relpath

in more places

it enforces that one directory is a prefix of another

so you get the error early.

@red-cpu-25099: in that particular case (codegen) sources should likely always be relative to the workdir

@witty-crayon-22786: is it true that 'AbstractTarget' class 'address' field (in general) should be relativized to the build root?

in this case for this particular synthetic target it will not be true

I’m working on a task to create symlinks to classes folders for targets from

pants_distdir

. It is required for the IntelliJ Pants plugin because it needs to know where are

*.class

files are stored for a particular target. With recent changes for incremental caches these paths are no longer stable from run to run. During implementing this new task to create symlinks I faced a few design dilemmas. First, we do replace

classes_dir

with

jar_file

in

runtime_classpath

product. Also I want to make this task smarter by changing symlinks only for changed targets, in order to do so I will need to know invalid targets and output folders for them. I came up only with one solution for the problem. A new product that will contain

classes

folders for newly compiled targets.

jvm_compile

will populate the product that will be consumed by my task.

Any objections regarding my solution? Do you think there is a better way to get

classes

folders?

Why can't the plugin consume the jars directly?

@bored-art-40741 I might try to use `z.jar`s. It might work as well. IntelliJ normally consumes a folder as a compiler output. But anyway my concern is how to not update all symlinks on every call but just the changed ones.

Have you tried just updating them all and seeing what the perf is? Updating at most a few thousand symlinks is probably a trivial operation

I don't think a new product is necessary. At worst, you could just have a flag to ZincCompile that indicates that it should update some symlinks to products that were invalidated on this run