Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

...are we missing something here about subsets of types? variance?

currently there aren’t any usages of subsets, it’s either one type or the full union

but that was something I’d wondered about

since the current indexing doesn’t handle it

right, which means the union is acting like a distinct type

it's actually the indexing of each type of the union that is strange, maybe. because if the task can output any of the types of the union, and it's indexed for each of them, in some cases it will not be able to produce a value of the type you requested

that’s true, my assumption there was that the selection handling would take care of it

so. i guess i'm wondering which it is here. it sounds like

so, unions in thrift/c/etc are distinct types

...and instances of the type are an instance of the concrete union

union types in typescript/scala etc are instead a type-level union, where a concrete value of the union type has a type == to one of the members of the union

so i think there is something to figure out here in that regard.

...but maybe after the port. i can try to just ignore this issue for now.

My goal was to replace subclassing with something more concrete, and the change did do that, but I think some of the semantics need sharpening

yep. that's approximately what i was thinking

<https://github.com/pantsbuild/pants/issues/4005>

test failure due to an amazing typo: `hits, misses = cache_stats.misses, cache_stats.misses`

rebased <https://rbcommons.com/s/twitter/r/4270/> to master

<@U04S45AHA> : if you were interested in looking at bootstrap, it should be in a reasonable position for that now. i'll be taking a look at what the release process to <https://github.com/pantsbuild/binaries> will look like, because that will likely be the default workflow

K, I already gave it a good start flying yesterday: <https://github.com/pantsbuild/pants/issues/3999>

Probably try to iron out more today and tomorrow

one pattern that has worked well for us internally has been to have a toggle in pants.ini for the expected workflow: namely `source` vs `binary`

Why do you think we'd need a binary flow?

seems likely that the source workflow can actually be tested in <http://travis.ci|travis.ci>

hm. i guess i was thinking that there might be some default that didn't depend on rust being installed on a potential contributor's machine