that seems a lot easier to deal with

It moves where you need to worry about things, and selfishly moves them away from “stuff we own”, it doesn’t make it go away… But I like that 😛

what we want to do with lint output feels application-specific, or at least it's a flexibility i'd like to provide to the person running pants

feels a lot more unix-y (as much as people abuse that term) and i like it

I think “adding extra ways we can put lint output places” is uncontroversial. I think the controversial thing is saying “and none of those options should be to overwrite in-place” 🙂

(`@console_rule`s and `Snapshot`s provide a really nice hook for adding custom output formats)

i don't know if it's incredibly common to run

./pants lint

directly, i would typically expect that to be done in pre-commit hooks or in CI, both places where we have wrapper scripts

For the sake of precision:

fmt

not

lint

yes, thank you

But we should probably pick that discussion up when people who disagree with me are around, because I know there are people who do 🙂

if we're trying to make v2 fmt a drop-in replacement for v1 fmt, then that might be different, but i feel like we have the ability to rethink that here

I think it’s reasonable for this to be decoupled from v1/v2, we’re just running into it because it’s something we haven’t currently modelled in v2, and an option would be to say “let’s not model it”

But if we’re saying it shouldn’t be a thing in v2, we should also be comfortable saying we should remove it from v1

i agree with that characterization

and i think we shouldn't lose sight here of the fact that if we want to have in-place

./pants fmt

, we don't necessarily need to introduce a ton of complexity into the engine to support it

Assuming we don’t want any `console_rule`s to run afterwards, yes. If we want `console_rule`s to run afterwards, I think it’s a difficult design space.

yes

Anywho, interesting as this has been, I should head out! Have a great thanksgiving, I look forward to picking this up at some point!

More generally though, this issue feels more like a "I would like to sequentially compose @rules without needing to know their names", which is similar to filter chains in web frameworks

(ie, chain a series of functions with the same input/output type)

this is what

--query

pipelining does: https://github.com/pantsbuild/pants/pull/7356/files#diff-25eb113080fbb829d55e428771ef22f3R390-R412

Mm, indeed.

it needs some more work to be pretty

@aloof-angle-91616: For find-in-page: what is the shared input/output type/interface?

In the context of @rules, sharing registration might mean a new @rule type similar to union...?

ah, well, this (ab)uses

UnionMembership

it's two-phase, where

QueryParser

union members have rules to create an

Operator

union member, so there are multiple

yield Get

s here (i've rebased against master, but there's a merge conflict and i was going to fix it this weekend but didn't)

(in

query.py

)

hydrated_operator = yield Get(HydratedOperator, QueryParseResult, expr)

, then

operands = yield Get(WrappedOperands, GetOperandsRequest(
      op=hydrated_operator.operator,
      build_file_addresses=build_file_addresses,
    ))

and this provides the registry via the

@union

relationship:

@dataclass(frozen=True)
class KnownQueryExpressions:
  components: Dict[str, Type[_T]]


@rule
def known_query_expressions(union_membership: UnionMembership) -> KnownQueryExpressions:
  return KnownQueryExpressions({
    union_member.function_name: union_member
    for union_member in union_membership.union_rules[QueryParser]
  })