who’s on release duty today? we probably need both a

2.8.0.dev

and a

2.7.1rc

build-wheels step is broken due to my last PR with this error:

All registered symbols: ['_python_requirements_file', 'archive', 'experimental_shell_command', 'files', 'pants_requirement', 'pex_binary', 'pipenv_requirements', 'poetry_requirements', 'python_artifact', 'python_awslambda', 'python_distribution', 'python_library', 'python_requirement_library', 'python_requirements', 'python_tests', 'relocated_files', 'resources', 'setup_py', 'shell_library', 'shunit2_tests', 'target']

https://github.com/pantsbuild/pants/runs/3841481284?check_suite_focus=true#step:9:1272

@witty-crayon-22786 are you envisioning a particular dynamic UI experience for

./pants check

? I'm starting to implement Go support. I see you have streaming output for Java

It looks like

go tool compile

doesn't have any output though. Only

stdout

upon errors I'm not sure if I'm supposed to batch every package's compilation together like we do with MyPy, or return one

CheckResult

per

go_first_party_package

? The latter, right?

the streaming output should be a property of the compile itself, rather than of

check

in particular: so you can mark the compiler result type

the JVM marks

FallibleCompiledClassfiles

(which is the output of

javac

or

scalac

) as

EngineAwareReturnType

, so that regardless of why you are compiling, you see the output

(i.e., while compiling for

test

, we still want streaming compiler output)

Hm that will result in

check

double streaming, right? Just with no std{out,err} attached to it

ah nvm, I see. You do bundle it all into a single `CheckResults`:

return CheckResults(
        [
            CheckResult(
                result.exit_code,
                stdout="",
                stderr="",
                partition_description=str(coarsened_target),
            )
            for result, coarsened_target in zip(results, coarsened_targets)
        ],
        checker_name="javac",
    )

yea. and the compile result type is “fallible” in order to avoid raising an exception for compile errors under

check

… but also, because it’s fallible, it will fail slow, which means that all compile errors possible will be rendered, rather than failing immediately on the first failure

(there are some rough edges to the fallibility though: when a goal like

test

must have a classpath, it will currently raise an exception… but it could potentially exit cleanly with “Could not compile test: failed” or something)

Hm, in Go, you have to have the

__pkg__.a

files (the result of compilation) for transitive dependencies present when compiling. If a dep failed to compile, are you saying we should continue attempting to compile?

no: it’s roughly the same on the JVM

it’s just that that subgraph failed to compile, not necessarily all of them

so that subgraph has failed, but other subgraphs can proceed until they encounter a failed result

if a dependency has failed, a compile will say so: https://github.com/pantsbuild/pants/blob/16add0b82e9f1ea682d0e63a3c1b3b6ec8ed61ba/src/python/pants/backend/java/compile/javac.py#L72-L78

but meanwhile, other portions of the graph may go on compiling

https://github.com/pantsbuild/pants/pull/12859 has the before and after, so it might be useful to look at

@hundreds-father-404: is it possible for the

run

goal to generically get a field(set) for targets if they have a particular field? it uses

TargetRootsToFieldSetsRequest

, which doesn’t seem to have that capability yet

oh. hm, i guess what i would need is for

RunFieldSet

to have an optional field that was inherited by subclasses

actually, since it’s optional, i guess i can just check for it afterward, huh.

What are you trying to do?

add a field:

class Restartable(BoolField):
    alias = "restartable"
    default = False
    help = ("If true, runs of this target may be interrupted and "
            "restarted when its input files change.")

…generically to `Target`s which will be used with

RunFieldSet

but i don’t think that i can enforce it, so I think that the next best thing is to request the underlying target, and look for it as optional

then implementers would need to add it manually to their runnable

Target

.

hm, i guess what i would need is for RunFieldSet to have an optional field that was inherited by subclasses

I think the benefit of doing that, rather than re-requesting the target, is you can inspect the FieldSet rather than having to resolve a target

is there precedent for implementing

optional_fields

and having subclasses preserve that? always a bit error prone to override concrete fields

Not quite, I think the closest we have is

StyleRequest.prior_formatter_result

, which is not a field

Should use

WrappedTarget