Advice on dependency pinning should be different depending on if you're writing a shared library vs a private project

[amontalenti]

In a chat, @ngoldbaum mentioned: "I disagree that libraries should pin their requirements. A library wants to support as wide a range of dependency versions as is practical, so that apps (which should pin dependency versions) don’t get conflicts from libraries that the app depends on. Of course you can go overboard on this and you need to stop supporting old versions at some point."

This is a very good point. Indeed, the entire style guide doesn't really address concerns of shared library writers vs private Python project codebases. It's more geared toward the latter, but there's no reason it shouldn't address the concerns you might have in writing a shared library. Even if not released publicly as open source, a Python module intended to be used as a shared library probably shouldn't pin its requirements. It's only a "deployable artifact" that should do this.

[amontalenti]

This is also getting actively discussed in PR #50.