4 ms·

After years of dealing with it I just run most of the software from docker containers and use homebrew for random cli tools.

jamil7 5y ago
This was also going to be my comment, homebrew for cli tools and casks for some gui apps, all other environments in docker containers.
- geerlingguy 5y ago
  Ditto. Anything mission critical runs in Docker via Docker-compose, so I can manage every aspect. And for any cli tool that's also mission-critical, it can be run within Docker so I can pin it or keep it bleeding edge more easily. For the important stuff, performance and ease of installation can take a side seat to stability.
handrous 5y ago
Homebrew needs to do a better job of communicating that you shouldn't use it for project dependencies, because every time there's a Brew thread on here, a bunch of people come out complaining about this kind of thing. "Homebrew broke my build by updating PostgreSQL and Redis". They shouldn't need to communicate that, but clearly, they do. Use Docker, probably. Homebrew is for your tools, not your dependencies. Is the system you're deploying to a Mac with Homebrew? Do all your collaborators use Macs with Homebrew? If the answer to either is no, why were you trying to use Homebrew for that in the first place, even if it were otherwise good for that? Would you use Homebrew to install Node modules for your project? Python packages? No? When why are you letting it define which version of PostgreSQL this project depends on?
- Doctor_Fegg 5y ago
  Genuinely, is this attested as the project philosophy anywhere? Because right now https://brew.sh https://brew.sh leads with "The Missing Package Manager for macOS", which would lead anyone to think it does the same as a package manager for Linux, and they're _full_ of developer dependency packages.
  - handrous 5y ago
    The thing is, you also shouldn't be using apt or whatever for managing project dependencies, unless you and all your fellow devs match Prod exactly, both with distro and exact versions of everything. People do it anyway, but it's bad practice for exactly the same reason that using Brew for it is bad practice, and it's barely easier than doing things right (and, very early in the life of a project, it'll become less easy than doing it right). It's not about project philosophy, it's about using the right tool for the job. Now, since people keep running into this problem, maybe they ought to put a warning about that right up top in a big banner on the site, I dunno, but it's not specific to Homebrew.
  - pxc 5y ago
    Imo you shouldn't use a typical Linux distro package manager for project dependencies either, unless you're only ever gonna deploy every app you're developing on that machine to the same version of the same distro. This is not because there's anything really wrong with them for what they're designed to do, but they install packages globally, and different projects may want different versions of the same thing.

jamil7 5y ago

This was also going to be my comment, homebrew for cli tools and casks for some gui apps, all other environments in docker containers.

geerlingguy 5y ago
Ditto. Anything mission critical runs in Docker via Docker-compose, so I can manage every aspect. And for any cli tool that's also mission-critical, it can be run within Docker so I can pin it or keep it bleeding edge more easily. For the important stuff, performance and ease of installation can take a side seat to stability.

handrous 5y ago

Homebrew needs to do a better job of communicating that you shouldn't use it for project dependencies, because every time there's a Brew thread on here, a bunch of people come out complaining about this kind of thing. "Homebrew broke my build by updating PostgreSQL and Redis". They shouldn't need to communicate that, but clearly, they do. Use Docker, probably. Homebrew is for your tools, not your dependencies. Is the system you're deploying to a Mac with Homebrew? Do all your collaborators use Macs with Homebrew? If the answer to either is no, why were you trying to use Homebrew for that in the first place, even if it were otherwise good for that? Would you use Homebrew to install Node modules for your project? Python packages? No? When why are you letting it define which version of PostgreSQL this project depends on?

Doctor_Fegg 5y ago
Genuinely, is this attested as the project philosophy anywhere? Because right now https://brew.sh https://brew.sh leads with "The Missing Package Manager for macOS", which would lead anyone to think it does the same as a package manager for Linux, and they're _full_ of developer dependency packages.
- handrous 5y ago
  The thing is, you also shouldn't be using apt or whatever for managing project dependencies, unless you and all your fellow devs match Prod exactly, both with distro and exact versions of everything. People do it anyway, but it's bad practice for exactly the same reason that using Brew for it is bad practice, and it's barely easier than doing things right (and, very early in the life of a project, it'll become less easy than doing it right). It's not about project philosophy, it's about using the right tool for the job. Now, since people keep running into this problem, maybe they ought to put a warning about that right up top in a big banner on the site, I dunno, but it's not specific to Homebrew.
- pxc 5y ago
  Imo you shouldn't use a typical Linux distro package manager for project dependencies either, unless you're only ever gonna deploy every app you're developing on that machine to the same version of the same distro. This is not because there's anything really wrong with them for what they're designed to do, but they install packages globally, and different projects may want different versions of the same thing.