@aloof-angle-91616 On https://github.com/pantsbuild/pants/pull/6374 - I think you may have lost me at the point that implicit conversions came into the picture…

It looks like that’s gone in the current version?

that's correct. i was trying to describe what i had removed, which may have been more than a little confusing

the OP should be up to date

also the conversions were pretty explicit, i can't think of a more explicit way than saying

convert(tuple)

^that sounded aggressive, i didn't mean it like that

just saw the message

SyntaxError: 'return' with argument inside generator

and i wanted to say i remember the last time i made this mistake and it was incomprehensible so thanks whoever wrote that

i guess i can git blame

(for `return`ing at the end of an

@rule

which does yielding)

that comes directly from python

a

def

is either a function or a generator, but not both

take a look at this other PR, it's neat https://github.com/pantsbuild/pants/pull/6480

i'm thinking of deprecating

_copy_target_attributes

in codegen tasks and moving that into an attribute on the generated target type itself, e.g.

PythonLibrary.synthetic_passthrough_args == ['compatibility']

. this has the additional benefit of colocating the passthrough args with the target that they're getting passed through to. i'm thinking this probably best done with a new abstract task class subclassing

SimpleCodegenTask

, and then individual codegen tasks can switch over kinda like

BinaryTool

-- and then we can deprecate using

SimpleCodegenTask

directly. if this had existed before, i wouldn't have had to update multiple internal tasks to support

compiler_option_sets

, and in general this seems far more stable. i don't think this is a lot of code, and since the idea is to make a new class first, it shouldn't be too intrusive. i can put that up today, but if it sounds like something i should put up an issue for first, i can do that first.

passthrough

is overloaded though. should call it something else.

er, wait. deprecating SimpleCodegenTask over that sounds like massive overkill. it's just one property

would just deprecate (re)defining

_copy_target_attributes

...?

can do that by setting a mutable property on the method to see if it's been redefined.

that's what i was thinking at first but didn't know how to do

great

i'm sure there are other ways to determine if something has been overridden, but in 30 mins or so back then, that was the simplest way i could find

(so not asking for review at all, just it's there)

@enough-analyst-54434, @happy-kitchen-89482: a sketch of what (non-transitive)

./pants --v2 dependees

looks like: https://github.com/pantsbuild/pants/compare/master...twitter:stuhood/fast-dependees#diff-1296e3c25dac4b8e3dee225895ae16cfR23

but there is a question of whether dependees should not be an explicit goal, but rather a "root selection" algorithm, like

--changed

.

then you could do something like

./pants --dependees test $target

I do like that

and then if you wanted to just print out the dependees we could have

./pants --dependees print $target

or something

(as either an explicit goal or as a root selection algorith, it would work fine with `--loop`: ie

./pants --v2 --no-v1 --loop --enable-pantsd dependees src/scala/org/pantsbuild/zinc/analysis

)

@happy-kitchen-89482:

list

😉

Oh, yes, we already have this