Interesting topic of discussion: We've talked previously about "should Pants expose the transitive dep graph for 3rdparty things?". (this usually applies to Python). The answer is that although it is "neat" and would help you understand how a 3rdparty dep exists in an environment, it also involves parsing lockfiles or other extra work (which @enough-analyst-54434 rightfully reserves the right to change for PEX). I just ran into an interesting and slightly compelling case: I'm assigning system packages to targets and just hit where a transitive, but not direct, 3rdparty req requires

libfoo

. The only way to surface that is to declare each direct 3rdparty dep which transitively relies on the offending 3rdparty req has the dependency on

libfoo

instead of just the one transitive req. Not the end of the world by any stretch, but I don't like encoding assumptions that might change over time. Also not a compelling enough reason to tackle the Pants request, but an interesting discussion nonetheless

I'll just note again here that as soon as Pants defines a dependency graph format, Pex will add support for exporting that.

That's because Pants and PEX are BFFs. I don't assume any other tool is as Pants-friendly 🙂

Sure, but you also have to start somewhere.

there wouldn’t need to be a standardized format, as long “something” could dump adjacency lists for target generation.

Well, an adjacency list ... is a format. Not a well specified one! JSON? plain text, etc.

my point is just that Pants doesn’t need to define one, or for it to be standardized. PEX could output ~anything

Ok. And I'm not willing to choose, so who budges 1st?

yea.

That's a standard with a doc.

the nitty gritty would probably be in things like “how are extras encoded”, and etc. but yea.

Ok, well that doesn't apply for JVM, but I can make up something, sure.

JVM isn’t relevant here though: that’s why i say this doesn’t need to be (/ shouldn’t be) a cross-language* standard