3 ms·

It's hard to pinpoint what the problem really is, but me and a few colleagues had corrupted brew installations lately, where various things would just randomly

by ratww 5y ago

It's hard to pinpoint what the problem really is, but me and a few colleagues had corrupted brew installations lately, where various things would just randomly stop working after updating a single package. The trick of disabling auto updates doesn't really work when you do want things to be updated. Sometimes there are conflicts and the usual path was to upgrade everything. Not that it matters: it seems that the usual "upgrade everything" from 2 years ago has changed into "delete every folder and reinstall everything from scratch". Also, a few years ago, updating everything or reinstalling lots of things from scratch was fast. Now, it requires much more time due to the massive number of dependencies every single package has. Also, the maintainers have a super weird aversion to everything that is "too simple". I've seen packages rejected because "the build process was too simple and there are no dependencies". The excuse was that "users can build it themselves". This is not for silly stuff random people wrote on weekend, this is for 20 year old tools used in production written in C. I can't say for certain why or how it got worse for other people, but for me it started when they doubled down on dynamic linking. That's why installing takes 5x the time it used to, takes more disk space, breaks all the time and makes organising your tools a fucking mess. As for me: I've replaced most of my Brew usage with Docker (for most development tools) or with static binaries compiled weekly using Github Actions (for cli tools like youtube-dl, etc). I'm also using download links straight from language websites (Rust, Ruby, Python, DotNet, Haskell).

pxc 5y ago
> Also, the maintainers have a super weird aversion to everything that is "too simple". I've seen packages rejected because "the build process was too simple and there are no dependencies". The excuse was that "users can build it themselves". This is not for silly stuff random people wrote on weekend, this is for 20 year old tools used in production written in C. wtf? What could be the possible motivation for this? Is their build farm really straining or something? Can you point me to this example? > I'm also using download links straight from language websites (Rust, Ruby, Python, DotNet, Haskell). this sounds downright medieval to me, like why even use macOS for development if the software management tools are so bad that that's what you're doing
- ratww 5y ago
  > this sounds downright medieval to me, like why even use macOS for development if the software management tools are so bad that that's what you're doing Because it's only one tool that really sucks: Brew. For the languages I specified, it works quite well. Even using C++ with vendored dependencies works better than average in macOS for me. For most of those languages I mentioned, Brew already offloads the real installation and updating of the language itself to a language manager (via rvm/rbenv, nvm, pyenv, rustup, whatever), so it doesn't make a difference, except without Brew I get a more stable, officially supported, environment. Also, DotNet was a Cask until a few months ago, so they effectively were just downloading something from the official website just like me.
andra_nl 5y ago
Could you give (or point to) a description how compiling binaries using GitHub Actions can be done? Sounds really nice. :)
- ratww 5y ago
  Sure! - Use the workflow_dispatch type so it can be manually triggered. Or schedule if you want it to run periodically. - Install dependencies like automake/cmake and libraries using brew (I cheat here a bit) - Clone the repository - Perform the steps for building a static build - Use actions/upload-artifact@v2 to upload the executable. It's simple, although to get it right with some programs. The advantage is that with one click you can download it, put in your path, and it won't need special paths. Here's an example with jq: https://pastebin.com/gHu8dTgQ https://pastebin.com/gHu8dTgQ Honestly the best option is asking maintainers of each program to add a static build to their projects in order to make their projects able to run without installing dependencies. Problem is, some maintainers are very anti-static-compiling.

by ratww 5y ago

pxc 5y ago

> Also, the maintainers have a super weird aversion to everything that is "too simple". I've seen packages rejected because "the build process was too simple and there are no dependencies". The excuse was that "users can build it themselves". This is not for silly stuff random people wrote on weekend, this is for 20 year old tools used in production written in C. wtf? What could be the possible motivation for this? Is their build farm really straining or something? Can you point me to this example? > I'm also using download links straight from language websites (Rust, Ruby, Python, DotNet, Haskell). this sounds downright medieval to me, like why even use macOS for development if the software management tools are so bad that that's what you're doing

ratww 5y ago
> this sounds downright medieval to me, like why even use macOS for development if the software management tools are so bad that that's what you're doing Because it's only one tool that really sucks: Brew. For the languages I specified, it works quite well. Even using C++ with vendored dependencies works better than average in macOS for me. For most of those languages I mentioned, Brew already offloads the real installation and updating of the language itself to a language manager (via rvm/rbenv, nvm, pyenv, rustup, whatever), so it doesn't make a difference, except without Brew I get a more stable, officially supported, environment. Also, DotNet was a Cask until a few months ago, so they effectively were just downloading something from the official website just like me.

andra_nl 5y ago

Could you give (or point to) a description how compiling binaries using GitHub Actions can be done? Sounds really nice. :)

ratww 5y ago
Sure! - Use the workflow_dispatch type so it can be manually triggered. Or schedule if you want it to run periodically. - Install dependencies like automake/cmake and libraries using brew (I cheat here a bit) - Clone the repository - Perform the steps for building a static build - Use actions/upload-artifact@v2 to upload the executable. It's simple, although to get it right with some programs. The advantage is that with one click you can download it, put in your path, and it won't need special paths. Here's an example with jq: https://pastebin.com/gHu8dTgQ https://pastebin.com/gHu8dTgQ Honestly the best option is asking maintainers of each program to add a static build to their projects in order to make their projects able to run without installing dependencies. Problem is, some maintainers are very anti-static-compiling.