search

amontalenti / elements-of-python-style

Goes beyond PEP8 to discuss what makes Python code feel great. A Strunk & White for Python.
3.44k stars 260 forks source link

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

Open amontalenti opened 4 years ago

amontalenti commented 4 years ago

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 commented 3 years ago

This is also getting actively discussed in PR #50.