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

Pants

<@U051221NF>: we build a pex using a process documented here: <http://pantsbuild.github.io/howto_develop.html>

<@U04S45AHA>, <@U066LC126> : in summary, i'll remove the `target` and `transitive` parameters from all `classpath_products` and `classpath_util` methods, and replace them with a `targets` list which is assumed to be a properly ordered list of targets for which non-transitive deps will be provided. to get `self`, pass target... to get `direct`, pass target.dependencies... to get `transitive`, pass target.closure(bfs=True)

...er, `direct` may or may not be `[target] + target.dependencies`, but yea.

Someone calls add* today in the "right" order - who is that?

<@U04S45AHA>: no enforced ordering for `add` today... except in that each task usually only adds one thing

yea... so it's exactly the ordering we get from ivy

So you're flipping to order determined by reader

but those are attached to one target at a time

how does reader know the trans dep graph "right" order?

we only attach `self` deps at the ivy level

yea, we ignore the classpath it spits out, and apply BFS, basically.

the ivy deps attach order on the write side must be respected

within a jar_library, the order is respected

i don't think so... ivy spits out something that is already conflict resolved

i didn't realize conflict resolution modes influenced ordering, but yes.