4 ms·

> What happens if your project needs an update, but it will hose the OS? Whay do you mean by "needs an update"? > Do you expect someone working in Python in W

> What happens if your project needs an update, but it will hose the OS? Whay do you mean by "needs an update"? > Do you expect someone working in Python in Windows who wants to distribute a datetime package should package for RPM and APT? Absolutely not. I expect a serious user of that library on an apt based system to package it and submit the package to their distro.

pfranz 5y ago
This was 10+ years ago, but I remember something like the installed Python package had a caching bug that was affecting production. The update wasn't compatible with some OS scripts so the machine would no longer boot using the updated package. Problems like that came up fairly often, but I remember that was the most egregious. Another scenario is that the OS shipped with Python 2.5 (supported until May 2011), but we had third-party tools that required Python 2.7 (shipped July 2010). Switching OSes (where things like monitor or hardware drivers weren't yet supported) was a ridiculous pain to test and certify. Decoupling OS and Python+package versioning was a huge relief for everyone, but won't make sense for everyone. > Absolutely not. I expect a serious user of that library on an apt based system to package it and submit the package to their distro. I try my best to personally do this and push for a work culture that does this, but even if this was done I can't fathom waiting on an OS update for existing code to percolate down. The risk tolerance, scope of concern, and agility between an OS and whatever project pays the bills are very different.