I've been wondering if we need the raw output mode in the

peek

goal, or if it can always emit JSON? cc @flat-zoo-31952 @witty-crayon-22786 @hundreds-father-404

What’s the best way to capture stdout from a process to a file? (I’m looking to concatenate a bunch of files together and store the results, and

cat

seems to only output things to stdout)

An invitation to a bikeshed:

today in comments that took 5 hours to discover I needed to write:

"", # THIS BLANK LINE WILL BREAK EVERYTHING IF DELETED. DON'T DELETE IT.

@curved-television-6568: new thread re: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1632902139461200?thread_ts=1632872254.453100&cid=C0D7TNJHL

@happy-kitchen-89482 if we proceed with

./pants peek

hydrating async fields, like evaluating the

sources

field, then I think there's less value for

./pants filedeps

? They now do the same thing, minus having to extract the info from JSON

@hundreds-father-404: new thread for https://pantsbuild.slack.com/archives/C0D7TNJHL/p1632933458477400?thread_ts=1632931275.469400&cid=C0D7TNJHL

black

doesn’t actually mix in the user pythonpath, so it shouldn’t need to use the user’s requirements, should it?

ValueError: You are using the lockfile at 3rdparty/python/lockfile.black.txt to install the tool `black`, but it is not compatible with your configuration:

- You have set interpreter constraints (`CPython>=3.6.2`) that are not compatible with those used to generate the lockfile (`CPython<3.10,>=3.7,>=3.8`). You can fix this by not setting `[black].interpreter_constraints`, or by using a new custom lockfile.

To regenerate your lockfile based on your current configuration, run `./pants generate-lockfiles --resolve=black`.

BTW I updated the docsite to refer to

check

instead of

typecheck

in 2.8

I forget, did this deprecation go into 2.7?

@bored-art-40741, @fast-nail-55400: @ancient-vegetable-10556 and i discussed my grabbing https://github.com/pantsbuild/pants/issues/13036 + “transitive classpath composition” this afternoon to ease landing the deploy jar patch

@bored-art-40741: regarding zinc

Hmm, it looks like all javac and junit tests are broken at HEAD :\

Philosophical quandary: I’m using 

/bin/cat

as part of a build step. It’s a POSIX utility in its POSIX location, and I’m using POSIX-compliant args (i.e. nothing implementation-specific) for it. Should I use a 

BinaryPath

 request to find that (and be consistent with the rest of Pants), or am I OK directly calling 

/bin/cat

and saving an extra step in the graph?

hey folks: i’m on

dev

release duty today: if you have anything in flight that you’d like me to wait for, let me know

@fast-nail-55400: so, it seems like https://github.com/pantsbuild/pants/issues/13055 is probably the most important JVM issue right now

How do I tell pants that a non-zero exist code is ok (from an external tool) and prevent things from blowing up? Context: https://github.com/pantsbuild/pants/pull/13063 I am seeing this in an integration test, this is a legit lint failure but I get an exception instead:

pants.engine.internals.scheduler.ExecutionError: 1 Exception encountered:
E           
E           Engine traceback:
E             in select
E             in pants.backend.python.lint.pyupgrade.rules.pyupgrade_fmt
E             in pants.engine.process.fallible_to_exec_result_or_raise
E           Traceback (most recent call last):
E             File "/tmp/process-executionnlGzOO/src/python/pants/engine/process.py", line 275, in fallible_to_exec_result_or_raise
E               local_cleanup=global_options.options.process_execution_local_cleanup,
E           pants.engine.process.ProcessExecutionFailure: Process 'Run pyupgrade on 1 file.' failed with exit code 1.
E           stdout:
E           
E           stderr:
E           Rewriting f.py

@hundreds-father-404: do you think you’ll be able to get to https://github.com/pantsbuild/pants/issues/13024 next week? @fast-nail-55400 might be touching that area to potentially expose produced/consumed symbols generically

@enough-analyst-54434: i’m happy to grab https://github.com/pantsbuild/pants/issues/13075 if you have other things to tackle

I’m on release today. will get something out later tonight

Do you think it'd be helpful to replace this:

> [INFO] Building dockerfile_parser.pex from dockerfile-parser_default_lockfile.txt

With this?

> [INFO] Building dockerfile_parser.pex from <https://github.com/pantsbuild.pants/2.8.0.dev3/src/python/pants/backend/docker/dockerfile_lockfile.txt>

I'm seeing process execution sandbox dirs without

__run.sh

, is that normal?

I'll be wrangling a 2.7.1rc0 today to right the ship for

./pants repl

invocations that include 3rdparty deps. If there are other cherry-picks that should go out, let me know; otherwise I'll give a heads up here when I prep the release notes.

With Python 3.10's release, any thoughts on whether to start releasing Pants with Python 3.10? If so, would it be appropriate to drop Python 3.7?

Heads up, Alex at Coursier merged https://github.com/coursier/coursier/pull/2197, so we might see an end to our Coursier JVM bootstrapping woes soon. I asked on that PR for assistance cutting a binary release that we could test in our CI, since I couldn't figure out how to cut a release just from the Coursier documentation--but if anyone here wants to take a crack at it, please feel free

So after merging in main, I'm seeing the JVM tests take a really long time for trivial tests. I haven't verified, but I'm like 95% sure that this must be Coursier bootstrapping on every single test run, presumably because it's now being configured to use a hermetic cache directory instead of the default home directory cache. Was this deliberate? If so, do we plan to revert this behavior once we solve the locking issue?

Ah, just missed it, we recently passed 10k commits!

I’ve got tests failing due to Java Runtime issues, and I’m trying to make sense of how why there might be different JDKs being selected for build vs runtime, can someone help me out here? • Test code • CI failure

@witty-crayon-22786 I think this has interplay with the

Classpath

code you wrote, but I’m not certain

so, i don’t fully grok why there would be a mismatch. you’re using a single

RuleRunner

, and the arg here: https://github.com/pantsbuild/pants/pull/13029/files#diff-aee5724dfe06aa0bab619b4ad11027306d06f63f6deb47266ee3b824f1f03c8cR77-R81 … should be applied for all usages. so the JdkSetup used should be the same in both cases.