we probably ought to move the repository 100% into config at this point.

oh great, thanks for the example

I think I'd be in favor of that^^ if thats an option

Has anybody else seen this?

Exception message: Failed to fetch binary bin/native-engine/linux/x86_64/9bffa3ad514ec7693e718cb5db4fd633ee1decba/native_engine.so from any source: (Failed to fetch binary from <https://dl.bintray.com/pantsbuild/bin/build-support/bin/native-engine/linux/x86_64/9bffa3ad514ec7693e718cb5db4fd633ee1decba/native_engine.so>: Fetch of <https://dl.bintray.com/pantsbuild/bin/build-support/bin/native-engine/linux/x86_64/9bffa3ad514ec7693e718cb5db4fd633ee1decba/native_engine.so> failed with status code 404)

(this is the first run of

1.3.0.dev15

on our jenkins box)

hm... suspected that that might happen. the build for that tag failed to push for linux. cc @rough-minister-58256

will see if i can kick it off again. it might end up requiring script edits though.

Hello all

What does pants expect to happen inside the

invalidated

context manager to invalidate dependents?

What i meant was, if my current vt is valid but i still need to invalidate it along with all of it's dependents... what should i do?

@gifted-beard-62952 : if

vt.valid

, your task doesn't need to do any work for that target, other than publish any

self.context.products

it provides

Correct... However, say i wanted to time limit the cache version (although its valid)

What i would like to achieve is the invalidation of the current vt and all of it's dependents

no precedent for doing that.

would just not cache in that case.

which means, not copy to the results_dir, right?

@gifted-beard-62952 : well, don't set

cache_target_dirs

true

caching isn't enabled by default

...or just don't have an invalidated block.

ahh i see

That makes sense

for example, tasks that send something to

dist

generally don't use an invalidated block, and just re-run each time they're requested.

in java_lib for goal

a

If we have

excludes = [
    exclude('org.slf4j', 'log4j-over-slf4j' ),
    exclude('ch.qos.logback','logback-classic'),
  ],

and goal

b

doesn’t, and depends on log4j in code when we do

./pants compile a
./pants compile b

it works. but when we do

./pants compile a b

Then b complains log4j doesn’t exist, is this the expected behavior?

Have been debugging this for a while, probably there is something I overlooked, thanks for helping!

mid graph excludes are generally not a great idea, because they have unexpected behaviour like this.

deploy_excludes

are recommended

(ie, on a binary)

ya good point

even b doesn’t depend on a?