we're talking about a particular

slf4j-xxx

implementation? or

slf4j-api

?

It could sneak in transitively to unrelated targets which might in turn be a problem

we encourage people to add

slf4j-xxx

deps to binaries and tests only

we're talking about :logback in our case

such that they don't come in transitively

Maven does have such a concept

<scope>runtime</scope>

And test, for that matter

right... the equivalent here is adding them to your test or binary

Yeah, but test is easily worked around by just having diferent targets

@witty-crayon-22786: I think you are right.

+1 - the concept is just forced by maven's mono-model, its not needed in pants

... it would be needed if we did unneeded-deps warning

hm, what do you mean

we'd need to label dynamic module deps loaded via reflection

which is what runtime is

ah.

yea, that's unfortunate.

but that labelling could be just a different jvm_binary dep slot

thats also where we handle "provided" scpe

deploy_excludes

god java logging is completely utterly terrible

question - when you guys do pants releases where fundamental cli options have changed, whats the cutover strategy for introducing that to your users w/o incurring grief/poor user experience? we have a bolt-on called the “translator” that coaches users on options changes (e.g. “—xyz has changed, use —123 instead”) over time. I wonder if other organizations would find that beneficial to push upstream?

or do most folks just use a ‘rip the bandaid off’ approach?

We send and email and do the latter--and in general have a build support oncall rotation for when people need help

ah interesting

@enough-analyst-54434 I’m getting a CI failure starting with Core python test failure 831b005905d3f3dd36269cccf9186d1ee1110858 is the first bad commit commit 831b005905d3f3dd36269cccf9186d1ee1110858 Author: John Sirois <john.sirois@gmail.com> Date: Fri Jul 24 164932 2015 -0600 Support eggs for setuptools and wheel. I tried from a fresh clone of pants, the error I’m getting is: interpereters = cache.setup(paths=[os.path.dirname(self._interpreter.binary)], filters=[str(self._interpreter.identity.requirement)]) > self.assertGreater(len(interpereters), 0) E AssertionError: 0 not greater than 0 tests/python/pants_test/python/test_interpreter_cache.py💯 AssertionError 1 failed, 1115 passed, 6 xfailed, 1 xpassed, 3 warnings in 383.39 seconds

I’m doing the CI locally via build-support/bin/ci.sh

any idea why I would see different behavior locally compared to travis?

assuming the test doesn’t mock/isolate the interepreter cache, could it be failing to actually populate the interpreter cache on your machine?

I’m reading through the code now to try and figure it out… I assume something is specific to my machine.