<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>yjftsjthsd-h</author><text>IMHO the problem with python package management isn&amp;#x27;t python package management. The biggest problem I&amp;#x27;ve hit is when python depends on non-python - `pip install` failing because I need to `apt install libsomething-dev` is the big one, but also managing multiple versions of python itself (I count this as a dependency on non-python because the python3 binary isn&amp;#x27;t written in python - if it was, then pip+virtualenv could manage it like everything else). And also as you note there&amp;#x27;s just ecosystem churn.</text><parent_chain><item><author>lexicality</author><text>I do a lot of maintenance work and every time I&amp;#x27;ve encountered a (complex) project set up in this way that&amp;#x27;s older than ~6 months, it&amp;#x27;s bitrotted from breaking changes in the dependencies.&lt;p&gt;The python ecosystem does not stand still and seems quite happy to introduce breaking changes in non-major versions.&lt;p&gt;To my mind, there are 3 ways to make sure your python project of today will work in 2 years time:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  1. Have no dependencies 
  2. Destroy your virtual environment and reinstall it every day for the next 2 years and fix anything that breaks
  3. Freeze your entire dependency tree where it stands and occasionally do large breaking change updates
&lt;/code&gt;&lt;/pre&gt;
All 3 options suck but #3 is the least worst</text></item><item><author>slt2021</author><text>I see a lot of package managers I never head of, am a happy venv &amp;amp; pip user.&lt;p&gt;&lt;pre&gt;&lt;code&gt;  One of the key faults of pip is what happens when you decide to remove a dependency. Removing a dependency does not actually remove the sub-dependencies that were brought in by the original dependency, leaving a lot of potential cruft.

&lt;/code&gt;&lt;/pre&gt;
This is not really an issue if your virtual environments are disposable. Just nuke and recreate venv from scratch using only what you need.&lt;p&gt;This is similar approach to “zero-based budgeting”. It forces you to carefully pick your dependencies and think about what you carry.&lt;p&gt;I never mention transitive dependencies in my requirements.txt file, just direct dependencies and rely on pip to install all transitive libs.&lt;p&gt;You dont even have to freeze the version, just list the name and pull up latest version whenever you run pip upgrade&lt;p&gt;If you dont do that, you can quickly go down the javascript’s path of bloated node_modules.&lt;p&gt;Can people explain why venv&amp;amp;pip is a bad solution that doesnt work for them they have to resort to other package managers?&lt;p&gt;Even venv is not really required if you dockerize your python apps, which you will have to do anyways at deploy time</text></item></parent_chain></comment><story><title>Python Has Too Many Package Managers</title><url>https://dublog.net/blog/so-many-python-package-managers/</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>GenerocUsername</author><text>I work in JS and the issues are the same.&lt;p&gt;It&amp;#x27;s why NPM creates lockfiles that can freeze the version of direct and indirect deps.</text><parent_chain><item><author>lexicality</author><text>I do a lot of maintenance work and every time I&amp;#x27;ve encountered a (complex) project set up in this way that&amp;#x27;s older than ~6 months, it&amp;#x27;s bitrotted from breaking changes in the dependencies.&lt;p&gt;The python ecosystem does not stand still and seems quite happy to introduce breaking changes in non-major versions.&lt;p&gt;To my mind, there are 3 ways to make sure your python project of today will work in 2 years time:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  1. Have no dependencies 
  2. Destroy your virtual environment and reinstall it every day for the next 2 years and fix anything that breaks
  3. Freeze your entire dependency tree where it stands and occasionally do large breaking change updates
&lt;/code&gt;&lt;/pre&gt;
All 3 options suck but #3 is the least worst</text></item><item><author>slt2021</author><text>I see a lot of package managers I never head of, am a happy venv &amp;amp; pip user.&lt;p&gt;&lt;pre&gt;&lt;code&gt;  One of the key faults of pip is what happens when you decide to remove a dependency. Removing a dependency does not actually remove the sub-dependencies that were brought in by the original dependency, leaving a lot of potential cruft.

&lt;/code&gt;&lt;/pre&gt;
This is not really an issue if your virtual environments are disposable. Just nuke and recreate venv from scratch using only what you need.&lt;p&gt;This is similar approach to “zero-based budgeting”. It forces you to carefully pick your dependencies and think about what you carry.&lt;p&gt;I never mention transitive dependencies in my requirements.txt file, just direct dependencies and rely on pip to install all transitive libs.&lt;p&gt;You dont even have to freeze the version, just list the name and pull up latest version whenever you run pip upgrade&lt;p&gt;If you dont do that, you can quickly go down the javascript’s path of bloated node_modules.&lt;p&gt;Can people explain why venv&amp;amp;pip is a bad solution that doesnt work for them they have to resort to other package managers?&lt;p&gt;Even venv is not really required if you dockerize your python apps, which you will have to do anyways at deploy time</text></item></parent_chain></comment><story><title>Python Has Too Many Package Managers</title><url>https://dublog.net/blog/so-many-python-package-managers/</url></story>