3 ms·
Not to pile on, but I thought Homebrew handled the Python2 -> Python3 cutover poorly. A routine `brew upgrade` resulted in python being de-syslinked. For me, th
by notafraudster 8y ago
Not to pile on, but I thought Homebrew handled the Python2 -> Python3 cutover poorly. A routine `brew upgrade` resulted in python being de-syslinked. For me, this meant a bunch of tasks broke silently in the background. It took a little while to find out that it was just the case that `python3` became the default interpreter and thus I needed to install some dependencies for scripts running in the background.
It's totally fine as my code was python3 compatible, but I was surprised that they'd apply a breaking change like this silently. Unlike OSes which might do this kind of thing with a major version update, I was surprised, and it took me a little while to diagnose what happened.
When I checked the GitHub discussions about the change, I found two things: 1) The maintainers claimed they had given a soft deprecation message a few months prior -- but brew doesn't stop for user input, it just posts walls and walls of messages, so I had naturally tuned it out. 2) The maintainers were getting ballistic mad at people who didn't think this was handled well.
Of course, open source is open source, and maintainers owe us nothing, but I was surprised that such a critical piece of infrastructure was being managed by people who imho handled a potentially non-trivial transition like this and who clearly didn't have the diplomatic tact to handle their userbase.
- csande17 8y agoYeah, Homebrew tends to not handle upgrades very well, especially around major versions -- I remember when their decision to change the "qt" formula from Qt 4 to Qt 5 broke pretty much everyone who had it installed. Part of the problem is technical--IIRC they don't have any CI infrastructure to test upgrade processes--but mostly they just don't care. They'd rather have the cleanest, most elegant code today, even if it means breaking everyone who installed it yesterday. That philosophy makes sense for a lot of projects (like in SaaS, where you often deploy new versions by creating new virtual machines and installing everything from scratch), but I'm not sure it's the most productive way to run a package manager.
- rmc 8y ago> That philosophy makes sense for a lot of projects (like in SaaS, where you often deploy new versions by creating new virtual machines and installing everything from scratch), Does that ever happen with OSX.....
- kelsolaar 8y agoI have been using Anaconda from Continuum Analytics for years to avoid that kind of issues after being bitten once. It is well isolated, usually installed in /usr/local/anaconda3/, and the environments are typically created in /usr/local/anaconda3/envs/
- rlkf 8y agoAt one point you could set an option to compile Boost using the C++11 runtime, but there was nothing that enforced compiling everything that depended on Boost with similar options, usually resulting in core dumps when different parts tried to use incompatible runtimes. Attempts to start a conversation on how this could be remedied was brushed away as unnecessary.