4 ms·

The fact that homebrew is awful is one of the huge reasons I don’t use MacOS for development like all my co-workers. Instead I use Windows with WSL because the

The fact that homebrew is awful is one of the huge reasons I don’t use MacOS for development like all my co-workers. Instead I use Windows with WSL because the company won’t allow me a Linux laptop. If I had to use a Mac my solutions would be to alway use Docker, a virtual machine, or a remote dev environment of some kind.

da39a3ee 5y ago
What’s an actual concrete example of a problem you have with homebrew?
zzbzq 5y ago
Funny, I use Windows with WSL and the first thing I do when I set up a new WSL instance is get homebrew (linuxbrew) and install everything else through that if available. apt/dpkg and any other package manager that scatters files all over the filesystem is just an absolute disaster that--if you do a lot of R&D tinkering--eventually renders a computer unusable after a few years. That's what happened to my first WSL instance; no apt command would work anymore because it had broken its own dependencies.
- encryptluks2 5y ago
  IMO this is so cringe and far from the truth. If you want a slow non-standard package manager they litters your computer and breaks things then that is Homebrew. If you want standardized installs then use apt/pacman/APK and just don't install a lot of user packages not in default repos. Homebrew is one of the slowest package managers I've ever used.
- Zababa 5y ago
  > apt/dpkg and any other package manager that scatters files all over the filesystem is just an absolute disaster that--if you do a lot of R&D tinkering--eventually renders a computer unusable after a few years. That was your experience. Mine is that after using apt for a lot of R&D tinkering for 3 years, everything runs fine. apt is global. Sometimes that's great and that's what you want. Sometimes it's not. Another way to keep that in mind is to think as apt as "bad at doing cleanup". The thing is that you have to have a separation between things that you want on your system all the time, and things that you use for one or more projects. For the first, apt is perfect. For the second, usually that's where I use tools like nvm for node versions, languages package managers like npm, and also docker (which I use a lot for development databases). For a backend JS project, I would install nvm, npm and docker globally, and then for the project I would use node through nvm with a .nvmrc, install packages locally with npm and use a package.json and package-lock.json, and run the development database with docker through a npm command, usually the latest PostgreSQL version. The link between the backend and database would be made with environment variables, because that's also what I use in production. The difference between the global (apt) scope and the project (the rest) scope might seem like a failure of apt, but I personally see it as the difference between global and local scope in programming: both have their use, we separate them for a reason and we don't put the same things in them.
- pxc 5y ago
  > apt/dpkg and any other package manager that scatters files all over the filesystem is just an absolute disaster that--if you do a lot of R&D tinkering--eventually renders a computer unusable after a few years. That's what happened to my first WSL instance; no apt command would work anymore because it had broken its own dependencies. This is the craziest claim that I've ever heard about package management, I think I would love to hear a more complete story
nullwarp 5y ago
I hate that you are forced to sign up for an Apple account just to install XCode which is required for Homebrew which pretty much makes the machine useless.
- st3fan 5y ago
  This is not correct. All you need is the command line tools, which brew tells you to install with `xcode-select --install`. No account needed.
  - nullwarp 5y ago
    Oh shoot thank you, for some reason when I last looked it seemed it was implied you needed the whole Xcode package. Guess I'll give that machine another go now.
snek_case 5y ago
I feel the same way. I've had a very good experience running xubuntu.
tored 5y ago
I don't even bother with WSL anymore, most dev packages I use comes as prebuilt Windows binaries bundled as zip-packages that you can unzip anywhere and run. No dependency management, no magic updates, no PPAs, run how many versions of the same software you like, delete folder when don't need it anymore. Super easy. Granted I don't work much with compiled languages anymore so I don't need to setup some complicated tool chain, but when I need to do that I usually go for MSYS2 or WSL when it has to be Linux.
dadarecit 5y ago
Can't tell if trolling, but either way, this is hilarious. Almost better than the OP, who's looking to switch the best (i.e. easiest to use) package manager on macos because of one fuckup which was 90% his fault (a) there's a cli flag you can disable auto upgrades with and b) who tf installs and runs postgres natively, what are you, from 1995?) I mean, using Linux through Windows because you don't like homebrew? What the fuck dude. I have no clue how you people stay productive, because if a package manager gets your panties in such a twist, I can't even imagine what your opinions on text editors would be, not to mention actual code & system design.

da39a3ee 5y ago

What’s an actual concrete example of a problem you have with homebrew?

zzbzq 5y ago

Funny, I use Windows with WSL and the first thing I do when I set up a new WSL instance is get homebrew (linuxbrew) and install everything else through that if available. apt/dpkg and any other package manager that scatters files all over the filesystem is just an absolute disaster that--if you do a lot of R&D tinkering--eventually renders a computer unusable after a few years. That's what happened to my first WSL instance; no apt command would work anymore because it had broken its own dependencies.

encryptluks2 5y ago
IMO this is so cringe and far from the truth. If you want a slow non-standard package manager they litters your computer and breaks things then that is Homebrew. If you want standardized installs then use apt/pacman/APK and just don't install a lot of user packages not in default repos. Homebrew is one of the slowest package managers I've ever used.
Zababa 5y ago
> apt/dpkg and any other package manager that scatters files all over the filesystem is just an absolute disaster that--if you do a lot of R&D tinkering--eventually renders a computer unusable after a few years. That was your experience. Mine is that after using apt for a lot of R&D tinkering for 3 years, everything runs fine. apt is global. Sometimes that's great and that's what you want. Sometimes it's not. Another way to keep that in mind is to think as apt as "bad at doing cleanup". The thing is that you have to have a separation between things that you want on your system all the time, and things that you use for one or more projects. For the first, apt is perfect. For the second, usually that's where I use tools like nvm for node versions, languages package managers like npm, and also docker (which I use a lot for development databases). For a backend JS project, I would install nvm, npm and docker globally, and then for the project I would use node through nvm with a .nvmrc, install packages locally with npm and use a package.json and package-lock.json, and run the development database with docker through a npm command, usually the latest PostgreSQL version. The link between the backend and database would be made with environment variables, because that's also what I use in production. The difference between the global (apt) scope and the project (the rest) scope might seem like a failure of apt, but I personally see it as the difference between global and local scope in programming: both have their use, we separate them for a reason and we don't put the same things in them.
pxc 5y ago
> apt/dpkg and any other package manager that scatters files all over the filesystem is just an absolute disaster that--if you do a lot of R&D tinkering--eventually renders a computer unusable after a few years. That's what happened to my first WSL instance; no apt command would work anymore because it had broken its own dependencies. This is the craziest claim that I've ever heard about package management, I think I would love to hear a more complete story

nullwarp 5y ago

I hate that you are forced to sign up for an Apple account just to install XCode which is required for Homebrew which pretty much makes the machine useless.

st3fan 5y ago
This is not correct. All you need is the command line tools, which brew tells you to install with `xcode-select --install`. No account needed.
- nullwarp 5y ago
  Oh shoot thank you, for some reason when I last looked it seemed it was implied you needed the whole Xcode package. Guess I'll give that machine another go now.

snek_case 5y ago

I feel the same way. I've had a very good experience running xubuntu.

tored 5y ago

I don't even bother with WSL anymore, most dev packages I use comes as prebuilt Windows binaries bundled as zip-packages that you can unzip anywhere and run. No dependency management, no magic updates, no PPAs, run how many versions of the same software you like, delete folder when don't need it anymore. Super easy. Granted I don't work much with compiled languages anymore so I don't need to setup some complicated tool chain, but when I need to do that I usually go for MSYS2 or WSL when it has to be Linux.

dadarecit 5y ago

Can't tell if trolling, but either way, this is hilarious. Almost better than the OP, who's looking to switch the best (i.e. easiest to use) package manager on macos because of one fuckup which was 90% his fault (a) there's a cli flag you can disable auto upgrades with and b) who tf installs and runs postgres natively, what are you, from 1995?) I mean, using Linux through Windows because you don't like homebrew? What the fuck dude. I have no clue how you people stay productive, because if a package manager gets your panties in such a twist, I can't even imagine what your opinions on text editors would be, not to mention actual code & system design.