<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>adamckay</author><text>If you want to stick with using `pip` over any of the newer tools that build on top of it (Poetry - my favourite, pdm, pipenv, rye, ...) the simplest way I used in the past was to use a `requirements.human.txt` to set my dependencies, then install them in a venv and do `pip freeze &amp;gt; requirements.txt` to lock all of the transitive dependencies.</text><parent_chain><item><author>davedx</author><text>The problem is `requirements.txt` doesn&amp;#x27;t do anything with downstream dependencies. There&amp;#x27;s nothing like a shinkwrap&amp;#x2F;lockfile in python. Even if you pin dependencies to exact versions, if you check your project out in a new environment and run pip install -r requirements.txt, you can end up with different, broken downstream dependencies.&lt;p&gt;This happens &lt;i&gt;a lot&lt;/i&gt; for me.</text></item><item><author>pdonis</author><text>&lt;i&gt;&amp;gt; There is constant breaking changes with it (both runtime and tooling).&lt;/i&gt;&lt;p&gt;I&amp;#x27;m not sure what you mean. Python 2 to 3 was a breaking change, but that was just one change, not &amp;quot;constant breaking changes&amp;quot;.&lt;p&gt;If you stick with one major version no old code breaks with a new minor version (e.g., you can run old 2.x code under 2.7 just fine, and you can run old 3.x code under 3.12 just fine). The minor version changes can add new features that your old code won&amp;#x27;t make use of (for example, old 3.x code won&amp;#x27;t use the &amp;quot;async&amp;quot; keyword or type annotations), but that doesn&amp;#x27;t make the old code break.</text></item><item><author>imran-iq</author><text>Python is a really bad example of cold blooded software. There is constant breaking changes with it (both runtime and tooling). So much so that the author still has to use python2 which has been EOL&amp;#x27;d for quite a while.&lt;p&gt;A much better example would be something like go or java where 10 year old code still runs fine with their modern tooling. Or an even better example, perl, where 30 year old code still runs fine to this day</text></item></parent_chain></comment><story><title>Cold-blooded software</title><url>https://dubroy.com/blog/cold-blooded-software/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>baq</author><text>That&amp;#x27;s an awareness problem. requirements.txt was invented... a long time ago, I think before the much more sane (but still not perfect) dependencies&amp;#x2F;lockfile split got popular. requirements.txt tries to be both - and it can be both, just not at the same time.&lt;p&gt;In short, you want your deployed software to use pip freeze &amp;gt; requirements.txt and libraries to only specify dependencies with minimal version conditions.</text><parent_chain><item><author>davedx</author><text>The problem is `requirements.txt` doesn&amp;#x27;t do anything with downstream dependencies. There&amp;#x27;s nothing like a shinkwrap&amp;#x2F;lockfile in python. Even if you pin dependencies to exact versions, if you check your project out in a new environment and run pip install -r requirements.txt, you can end up with different, broken downstream dependencies.&lt;p&gt;This happens &lt;i&gt;a lot&lt;/i&gt; for me.</text></item><item><author>pdonis</author><text>&lt;i&gt;&amp;gt; There is constant breaking changes with it (both runtime and tooling).&lt;/i&gt;&lt;p&gt;I&amp;#x27;m not sure what you mean. Python 2 to 3 was a breaking change, but that was just one change, not &amp;quot;constant breaking changes&amp;quot;.&lt;p&gt;If you stick with one major version no old code breaks with a new minor version (e.g., you can run old 2.x code under 2.7 just fine, and you can run old 3.x code under 3.12 just fine). The minor version changes can add new features that your old code won&amp;#x27;t make use of (for example, old 3.x code won&amp;#x27;t use the &amp;quot;async&amp;quot; keyword or type annotations), but that doesn&amp;#x27;t make the old code break.</text></item><item><author>imran-iq</author><text>Python is a really bad example of cold blooded software. There is constant breaking changes with it (both runtime and tooling). So much so that the author still has to use python2 which has been EOL&amp;#x27;d for quite a while.&lt;p&gt;A much better example would be something like go or java where 10 year old code still runs fine with their modern tooling. Or an even better example, perl, where 30 year old code still runs fine to this day</text></item></parent_chain></comment><story><title>Cold-blooded software</title><url>https://dubroy.com/blog/cold-blooded-software/</url></story>