Another reason my file-based deps proposal makes the world more sane. A Python tool depending on a shell script depending on a PEX Binary is erroring about multiple resolves since my py tool uses resolve A and my pex uses resolve B. We're inheriting the PEXs deps, even though we're using a built artifacts 💀 😭

A change we might be able to make today is to have our dependency walker stop when hitting a packageable artifact.

Or something along those lines 🤔

yea, that would be possible. it depends on having an API to filter dependencies (by type, etc) while computing

TransitiveTargets

Gentoo builds everything from source. So, portage, its package manager, has to understand many different kinds of deps. We might want to look at how they do that, because they have to manage deps in all sorts of languages (C, Python, Java, Go, Haskell, Ruby, and plenty of others I can’t think of atm). Gentoo’s package manager also has to manage cross compilation because it supports using

distcc

for distributed package builds. So, that’s something else that might be interesting prior art. So, Gentoo has these kinds of deps: https://devmanual.gentoo.org/general-concepts/dependencies/#dependency-types •

BDEPEND

(Build Dependencies) is for dependencies that are needed on the build host (aka CBUILD host) •

DEPEND

(also for Build Dependencies) is for dependencies on libraries/headers that are needed on the target host (aka CHOST - the machine that runs the built package) •

RDEPEND

(Runtime Dependencies) is for dependencies required at runtime like dynamically linked libs, data packages, and the relevant runtime interpreter (if applicable). •

PDEPEND

(Post Dependencies) is for runtime dependencies that can be satisfied after the package is installed - used to resolve circular dependencies.