because they all reduced to functions

True. Are executions of concrete sets of args re-run, or are they still cached in the product graph?

getting lunch, so I’m not going to be responsive for a bit

executions should all be cached in the product graph, afaik

it's very likely that this morphs back into subclasses of Rule in your branch, and i'm down.

...the only part that was unnecessary, afaik, was the Nodes. in the sense that all of these computations break down into series of functions, and it's only actually necessary to have Nodes for projection/selection/etc

oh, ie, we move towards the model of having mostly one type of Node. So intrinsics are a rule type but not a node type

yea, exactly.

I like that

when should you use

PrimitiveField

in a

Payload

object vs just direct use of a value?

seems like the idea is that it provides inherent fingerprinting, but I see other cases where values are used directly without a

*Field

wrapper

hm, seems like that might be a special case that can only contain

None

values

@enough-analyst-54434 I’m trying to run your target name removal script from https://rbcommons.com/s/twitter/r/4287 in pants repo for sanity test. but got

[tw-mbp-yic pants (x)]$ find . -name "BUILD*" | \
>     xargs grep -E "name\s*=" | \
>     sed -r -e "s|((.*/)?([^/]+)/BUILD[^:]*):.*name\s*=\s*['\"]([^'\"]+)['\"].*|\1 \3 \4|" | \
>     while read file dir name
>     do
>       [ "$dir" == "$name" ] && echo "$file $name"
>     done | \
>     sort -u | \
>     while read file name
>     do
>       sed -ri \
>         -e "s|(\s*name\s*=\s*['\"]$name['\"]\s*,\s*|(|" \
>         -e "/name\s*=\s*['\"]$name['\"]/d" $file
>     done
sed: illegal option -- r
usage: sed script [-Ealn] [-i extension] [file ...]
       sed [-Ealn] [-i extension] [-e script] ... [-f script_file] ... [file ...]
[tw-mbp-yic pants (x)]$

anything obvious I’m missing?

You're not using a reasonable OS

I'm on linux

So may need BSDism adjustments

-r on gnu sed is extended regexp switch

$ bash script
sed: -e expression #1, char 46: Unmatched ( or \(
sed: -e expression #1, char 41: Unmatched ( or \(
sed: -e expression #1, char 38: Unmatched ( or \(
sed: -e expression #1, char 40: Unmatched ( or \(
sed: -e expression #1, char 45: Unmatched ( or \(
sed: -e expression #1, char 39: Unmatched ( or \(
sed: -e expression #1, char 45: Unmatched ( or \(
sed: -e expression #1, char 44: Unmatched ( or \(
sed: -e expression #1, char 43: Unmatched ( or \(
sed: -e expression #1, char 38: Unmatched ( or \(
sed: -e expression #1, char 46: Unmatched ( or \(
…

on centos7, but ok..looks like i have to tweak it a bit

Yeah, centos is terminally old (conservative), I'm on Arch which lags various HEADs by days to weeks

So more adjustments because of that too.

oh the joys of unix portability

@rough-minister-58256 : there must be something in pytest that sanitizes environment variables in the forked process...?

...eh, that doesn't make sense though, because integration tests (which still run in pytest) are passing

yeh dont believe so - the ‘hermetic’ case will do that tho

yea, and those are passing after some edits

i've repro'd locally... iterating now.

is there a preferred pattern/utility approach for constructing and using a temporary buildroot in the context of an integration test?

there are a few, afaik

don't know about preferred.

hrm