Did Twitter do anything special with python's stderr/out buffering within Jenkins?

Not that I recal

Maybe that env var is set?

forget the env var

PYTHONUNBUFFERED=1

Yeah I believe I've tried that

I'll give it another shot

They were using console plugins by that point in time, can't remember the names of the plugins, those may have helped

One added timestamps to logical console lines

I ended up figuring it out (after 2 year of suffering this!)

It was a wrapper in our service builder around subprocess calls that teed the output for logging

Regarding my comments on https://rbcommons.com/s/twitter/r/2778/

Part of the problem I’m having isn’t technical, its political. The wire devs have been hostile to pants in the past, suggesting in a large meeting that we should shut the project down.

At least some of them are a bit isolated from the rest of the company too, working in another remote office.

What we are doing in some places is generating some of our pants.ini configuration that comes from Maven so that is a potential solution for us. We do this to define all of the JDK path information, for example.

(also, for whatever reasons, the person spearheading most of the wire development is a big Maven fan…)

But I do think this is a great change overall to keep new users from having to install a BUILD.tools file

I am performing a publish of the java tools to pick up the new jar-tool version

@enough-analyst-54434: I’m trying out 2778 again with the redirect in BUILD.tools...

Thanks

Hmm, I expected this to work but it didn’t:

target(name='wire-compiler',
  dependencies=[
    '3rdparty:com.squareup.wire.wire-compiler',
  ],
)

(the wire_gen task still sees wire 1.6.0)

Cleaning up some context and trying again.

Also, the spec need not be in BUILD.tools at all, write down a single arbitrarily deep spec in oants.ini right?

Which setting are you suggesting I change in pants.ini? Currently I have:

[gen.wire]
# Make sure Pants dependencies on wire are the same versions declared in our maven build under parents/base/pom.xml
javadeps: ["3rdparty:com.squareup.wire.wire-runtime"]
# Add guava to the list of wire_compiler deps because the 'sjar()' macro excludes transitive guava deps
# from everything in 3rdparty.  We do this in 3rdparty because there are many different versions of guava declared
# and we only want to choose one.
wire_compiler: ["3rdparty:com.squareup.wire.wire-compiler", "3rdparty:com.google.guava.guava”]

It looked to me like in the patch there is a hardcoded reference now to

//:wire-compiler

(I commented in the RB)

Nothing has changed, just s/list/string/

No - should not be the case

I'll be at a keyboard in 10 minutes if you don't figure this out

Don’t sweat it. I’m still digging myself.Maybe the problem is in the way wire_gen tries to detect the version of wire. Its got this little snippet of code:

@memoized_property
  def _wire_compiler_version(self):
    wire_compiler = self.tool_targets(self.context, 'wire_compiler')[0]
    wire_compiler_jar = wire_compiler.jar_dependencies[0]
    wire_compiler_version = wire_compiler_jar.rev
    return Revision.lenient(wire_compiler_version)