ok... How do I declare loose file dependencies as resources for running in a go test?

I'll look at #5119 presently. As for loose file deps - that'd unfortunately be new feature.

Oh dear 😞 we don't have a concept of a runfiles tree or anything?

nope

Right now loose file deps are handled ad-hoc by JunitRun and PytestRun (tasks2/) over Files targets

Ok... So adding that support for Go shouldn't take me long, right? 🙂

It shouldn't. As I recall source chroots are already built.

I've tried to make the jax_ws plugin work with a minimal

pants.ini

file:

[GLOBAL]
pants_version: 1.3.1rc1

plugins: [
    'pantsbuild.pants.contrib.jax_ws==%(pants_version)s',
  ]

this gave the same error

@dazzling-plumber-90795 a quick repro finds me:

jsirois@gill /tmp/1.3.x_jax_repro $ ./pants targets 2>/dev/null | grep jax
                  jaxb_library: A Java library generated from JAXB xsd files.

So the jaxb plugin installs, but the

jax_ws_library

target type does not exist. Is this a typo in your BUILD file? I'm not too familiar with the plugin.

Any thoughts on where https://github.com/pantsbuild/pants/issues/5120 should be fixed? What level of thing should be detecting that it has no work to do and returning? The task execute method?

I am using pants to automatically download the thrift compiler for me. I am now interested in using the same binary from within a sibling build script (non-pants). Is there an easy way to retrieve or extract the locating of the thrift binary?

And do we have any proper end-to-end integration tests (e.g. a shell script which runs

./pants foo

), rather than nudging at stuff through the python?

@average-vr-56795 we do have those style tests in-general, geneally the targets are tagged integration and they use a base class ... details in a sec

For example

tests/python/pants_test/backend/python/tasks2/test_pytest_run_integration.py

So, infra is there, looks like coverage using it is just needed for this case

Fabulous, thanks! 🙂

@rapid-apartment-37923 no, although https://github.com/pantsbuild/pants/issues/4006 is related

Let me firm up that no with a quick check, may be able to - sort-of

@enough-analyst-54434 the

jaxb_library

installs without any plugins section in the

pants.ini

file

Yeah, getting back to that in a few minutes here

ok thanks

Yeah, so @rapid-apartment-37923 nothing at all stable and direct. Most of the pieces though by demonstration - the missing piece of the path is the platform identifying directories in the final ls:

jsirois@gill ~/dev/pantsbuild/pants (master) $ ./pants options --scope=GLOBAL --name=pants_bootstrapdir
pants_bootstrapdir = /home/jsirois/.cache/pants (from HARDCODED)

jsirois@gill ~/dev/pantsbuild/pants (master) $ ./pants options --scope=thrift-binary
thrift-binary.supportdir = bin/thrift (from HARDCODED)
thrift-binary.version = 0.9.2 (from HARDCODED)

jsirois@gill ~/dev/pantsbuild/pants (master) $ ls -l ~/.cache/pants/bin/thrift/linux/x86_64/0.9.2/
total 39232
-rwxr-xr-x 1 jsirois jsirois 40170146 Dec 20  2016 thrift

@enough-analyst-54434 thanks for the pointers. I will see how I can proceed from there :-)

NP, I checked out the code involved and its too adhoc to say adding support for revealing binary paths would be quick and easy. Not hard, but a bit of work to clean things up.

@dazzling-plumber-90795 - there is a bug in that package's setup.py, workaround is:

jsirois@gill /tmp/1.3.x_jax_repro $ cat pants.ini
[GLOBAL]
pants_version: 1.3.1rc1

plugins: [
    'pantsbuild.pants.contrib.jax_ws==%(pants_version)s',
  ]

backend_packages: +[
    "pants.contrib.jax_ws",
  ]

That last

backend_packages

entry gets the target registered. I'll file an issue here shortly to get this corrected in the released package.

Thanks @enough-analyst-54434, confirmed that that works for me

@enough-analyst-54434 on https://github.com/pantsbuild/pants/issues/5120 - should task.execute be the thing which generally decides "I have no work to do for this target"?