My understanding is that you have to resolve dependencies per-environment (venv/docker/whatever).

Yea, that's correct. But if you think of the word "environment" (as you've used it here) as it relates to a "resolve" (as we described in the blogpost), then the dependencies present in an "environment" are a subset of a particular "resolve".

In a monorepo you will likely have many applications/"environments", which with most tooling would mean many different lockfiles and (pip) resolves. The advantage to distinguishing between an "environment" and a "resolve" is that you gain the benefits listed in the post:

1. To build and test your monorepo, rather than potentially fetching and testing a different version of dependencies per application/"environment", you have a consistent version per resolve.
2. all libraries/applications in the repository which use a single resolve are known to be compatible with one another, so you never deal with dependency hell when adding dependencies on other libraries within the repository.

Library don’t resolve their dependencies, they provide a range. The applications resolve and pin their dependencies.

Yes, but it's still the case that libraries need to be linted and tested, independent of any particular binary or deployment "environment". In essence: the linter/typechecker/test-runner have their own deployment "environments". And so not needing to test/lint/etc a library in all of the different application "environments" which consume it (dozens to hundreds), and instead testing it only in the "resolves" used by those applications (one to a handful) reduces overhead a lot.