> If you publish a Python library without pinned dependencies, your code is broken. > you will be unable to today publish an end-to-end set of commands that wi

> If you publish a Python library without pinned dependencies, your code is broken. > you will be unable to today publish an end-to-end set of commands that will work in 2025 Not necessarily. Since ~2010 I maintain an application with an unpinned requirements.txt; it doesn't even have version constraints at all. The only breakages I had were either: 1. when switching from Python 2 to Python 3 (obviously) 2. when a new Python version introduces a bug (but Python is not pinnable anyway) 3. once, when a dependency released a new major version and removed an internal attribute I was using in my tests out of laziness (so that one is entirely on me) The trick is to only use good libraries, that care about not breaking other people's code. --- It's also worth noting that it's not your job as a developer to make sure your application can be installed anywhere; it's the packager's job to make sure your app can be installed in their distribution. And if your users want to use pip (which is kind of the Python equivalent of wget + ./configure + make install) instead of apt/yum/... to get the very latest version of your software, then they should be able to figure out how to fix those issues.