4 ms·

Meanwhile, I find macOS sticky in part because of the package manager (homebrew). In particular, I've not seen a package selection so good and so consistently

Meanwhile, I find macOS sticky in part because of the package manager (homebrew). In particular, I've not seen a package selection so good and so consistently up-to-date, with so very little fiddling or upkeep to add or maintain 3rd-party repos, since I was on Gentoo—and portage broke (in whole, or just had broken individual packages) a lot more than homebrew does (which is almost never). I can't think of a single thing I use that isn't available and well-maintained on it, open or closed source. Even obscure things often just install on my first guess at the package name, no muss, no fuss. Now, what I don't use it to do is to manage project dependencies, but then I don't like using, say, the "system" PostgreSQL or Nodejs or whatever even on Debian, either, unless I'm using them directly and not making them part of a project that will need to be distributed or deployed elsewhere and worked on by others. I'm entirely fine keeping core OS parts, my personal software I use, and management of individual project dependencies, strictly separate—in fact, having worked this way, I prefer it. I could be tempted away by a similarly-great and high-quality package selection, maybe, but that would be table-stakes before we even get into the rest of how the package manager operates.

smw 5y ago
Just fyi, you can use homebrew on linux.
- handrous 5y ago
  Yeah, but it's got a much smaller set of packages available and, last I checked, had a lot more issues with broken packages and things like that (I assume because there are fewer eyes on it, and way less total time spent on maintenance of it)
  - smoldesu 5y ago
    Are there any packages that exist on Brew, but not, say, APT or pacman?
    - handrous 5y ago
      On macOS brew? Yeah, tons. To even get somewhat close with Ubuntu or Debian you'd have to add a bunch of non-standard package repositories, and because of the way most Linux distros tie up user-facing programs with system releases, you'd have to do similar to stay up-to-date on packages that are in the default repos. Arch does much better, but a quick search of ones I guessed might be missing turned up the following missing, from what I have installed on my Mac: - rolldice - android studio (package name android-studio in homebrew) - tealdeer - heroku (these are the Heroku command line tools) - sublime text (package name: sublime) - postman - slack Maybe you can add other repos to get them on there, but I usually just guess the package name and get what I want. I don't think I have a single thing on my Mac, as far as software I directly use (not project dependencies), that I didn't install with Homebrew, aside from first-party Apple software (Pages, Numbers, Safari, Xcode, Mail, and so on). And that's not bringing up all the Mac-only software I've installed with it, which obviously wouldn't be fair. I haven't added a single extra repo. That's just with the defaults. You used to have to do a one-time invocation to enable binary-only packages (mostly closed-source stuff) and then use a different keyword for operating with them, but that's no longer the case and hasn't been for IIRC at least a year—it's all transparent. "brew install [guess at package name]" works almost every time I need it, and a "brew search" finds the rare failures. I basically never need to open a browser to find & download software, and it's all up-to-date, and it's all totally separate from my base system so is extremely unlikely to ruin my morning because I ran a blanket update-everything-to-latest and didn't pay enough attention.
      - smoldesu 5y ago
        Default repos don't seem to carry a lot of those (no big surprise), but the AUR seems happy to serve them. All of the apps you listed are available there, presumably because it would be a bad idea to force people to build things from the primary repos. It's honestly a nice distinction, considering one of the main complaints I've heard from Homebrew users is that it's painful having binaries and build scripts mixed in.
      - heavyset_go 5y ago
        The AUR[1] has rolldice, Android Studio, tealdeer, Heroku, Sublime Text, Slack and Postman. [1] https://aur.archlinux.org https://aur.archlinux.org
heavyset_go 5y ago
I don't use Arch, but I've been impressed with Pacman and the AUR. It's got everything.
smoldesu 5y ago
Homebrew's repos are pretty lacking compared to most modern distros I've used, but if you haven't tried pacman on Arch, you're missing out. It will blow Homebrew out of the water.
- handrous 5y ago
  Arch's default repos are definitely missing several cross-platform (at least Mac and Linux) programs that I've installed with Homebrew, without having to touch the config or add any extra repositories. I listed a few in another post, above. I've yet to see the opposite, because I simply haven't encountered anything I wanted that wasn't on homebrew. More details in another post elsewhere in the thread. Arch does seem to be about as good as Gentoo's portage, which is the best selection I've yet to see in a Linux package manager. I'm not interested in a rolling-release base system anymore, though, because I just don't have the time or patience for "running update broke X/Wayland/audio/wifi/boot" these days, or fiddling with whatever it takes to keep that from happening. Rolling release applications? That I like.
LinXitoW 5y ago
How do you manage project dependencies? Say, a certain Java/Python version and maybe a running Postgres?
- llimllib 5y ago
  Not OP, but I have a similar setup and I use asdf or javaenv or pyenv or docker
- handrous 5y ago
  Databases and other 3rd-party daemons go in Docker because I can install the same version with the same tools pretty much anywhere. Even if it's not being deployed with Docker, the docker-compose file documents exactly the version and config the project expects, and is guaranteed to be correct assuming everyone developing uses it. This also means it's trivial to run several versions, and to add/remove/update/start/stop them independently, including any data or "cruft" files. If Docker were to vanish, the answer would become Vagrant running some very common and stable Linux distro with either a config shell-script or ansible yaml, for similar reasons. Documentation, consistency, and isolation. Some people use the above for their projects themselves, for similar reasons, but I just use the now-ubiquitous env and version-manager programs for that (nvm, rvm, that kind of thing). Again: documentation, consistency, and isolation. Even if your dev set-up isn't used for deployment, if it's scripted then it's also accurately documented. As for language-specific libraries and tools, even if a few are in some package manager, I wouldn't rely on them. The language's own package manager will work everywhere, will probably be more (maybe much more) up-to-date, and you're going to need it for some stuff, inevitably, so you may as well use it for everything the project needs from that language. [EDIT] notably, this way of working means none of my/our projects give a shit what OS or package manager anyone is using. Prefer macports to homebrew? Running Void Linux? Slackware? Probably even Windows (I dunno, who cares, it's Windows, but probably it works)? Go nuts with that, live your best life or whatever, the projects don't care. You'll likely need to manually create a Linux VM for Docker if you're on a BSD, but if you're on a BSD that will be the least inconvenience you face this week. I truly don't get why anyone would just "brew install postgresql" or "apt install postgresql" and use whatever happens to come down as an implicit project dependency in this, the year 2021. Because you actually want to directly use a local database to do database things? Sure. For a project that will be distributed or deployed elsewhere? No no no no no. Not even if you're running the same OS as your servers. Or Ruby, or Node, or even your compilers if you can help it. You have to be more specific and keep your shit tidier than that if you don't want a bunch of pain, both now and later, and almost all of that's very easy to do now.

smw 5y ago

Just fyi, you can use homebrew on linux.

handrous 5y ago
Yeah, but it's got a much smaller set of packages available and, last I checked, had a lot more issues with broken packages and things like that (I assume because there are fewer eyes on it, and way less total time spent on maintenance of it)
- smoldesu 5y ago
  Are there any packages that exist on Brew, but not, say, APT or pacman?
  - handrous 5y ago
    On macOS brew? Yeah, tons. To even get somewhat close with Ubuntu or Debian you'd have to add a bunch of non-standard package repositories, and because of the way most Linux distros tie up user-facing programs with system releases, you'd have to do similar to stay up-to-date on packages that are in the default repos. Arch does much better, but a quick search of ones I guessed might be missing turned up the following missing, from what I have installed on my Mac: - rolldice - android studio (package name android-studio in homebrew) - tealdeer - heroku (these are the Heroku command line tools) - sublime text (package name: sublime) - postman - slack Maybe you can add other repos to get them on there, but I usually just guess the package name and get what I want. I don't think I have a single thing on my Mac, as far as software I directly use (not project dependencies), that I didn't install with Homebrew, aside from first-party Apple software (Pages, Numbers, Safari, Xcode, Mail, and so on). And that's not bringing up all the Mac-only software I've installed with it, which obviously wouldn't be fair. I haven't added a single extra repo. That's just with the defaults. You used to have to do a one-time invocation to enable binary-only packages (mostly closed-source stuff) and then use a different keyword for operating with them, but that's no longer the case and hasn't been for IIRC at least a year—it's all transparent. "brew install [guess at package name]" works almost every time I need it, and a "brew search" finds the rare failures. I basically never need to open a browser to find & download software, and it's all up-to-date, and it's all totally separate from my base system so is extremely unlikely to ruin my morning because I ran a blanket update-everything-to-latest and didn't pay enough attention.
    - smoldesu 5y ago
      Default repos don't seem to carry a lot of those (no big surprise), but the AUR seems happy to serve them. All of the apps you listed are available there, presumably because it would be a bad idea to force people to build things from the primary repos. It's honestly a nice distinction, considering one of the main complaints I've heard from Homebrew users is that it's painful having binaries and build scripts mixed in.
    - heavyset_go 5y ago
      The AUR[1] has rolldice, Android Studio, tealdeer, Heroku, Sublime Text, Slack and Postman. [1] https://aur.archlinux.org https://aur.archlinux.org

heavyset_go 5y ago

I don't use Arch, but I've been impressed with Pacman and the AUR. It's got everything.

smoldesu 5y ago

Homebrew's repos are pretty lacking compared to most modern distros I've used, but if you haven't tried pacman on Arch, you're missing out. It will blow Homebrew out of the water.

handrous 5y ago
Arch's default repos are definitely missing several cross-platform (at least Mac and Linux) programs that I've installed with Homebrew, without having to touch the config or add any extra repositories. I listed a few in another post, above. I've yet to see the opposite, because I simply haven't encountered anything I wanted that wasn't on homebrew. More details in another post elsewhere in the thread. Arch does seem to be about as good as Gentoo's portage, which is the best selection I've yet to see in a Linux package manager. I'm not interested in a rolling-release base system anymore, though, because I just don't have the time or patience for "running update broke X/Wayland/audio/wifi/boot" these days, or fiddling with whatever it takes to keep that from happening. Rolling release applications? That I like.

LinXitoW 5y ago

How do you manage project dependencies? Say, a certain Java/Python version and maybe a running Postgres?

llimllib 5y ago
Not OP, but I have a similar setup and I use asdf or javaenv or pyenv or docker
handrous 5y ago
Databases and other 3rd-party daemons go in Docker because I can install the same version with the same tools pretty much anywhere. Even if it's not being deployed with Docker, the docker-compose file documents exactly the version and config the project expects, and is guaranteed to be correct assuming everyone developing uses it. This also means it's trivial to run several versions, and to add/remove/update/start/stop them independently, including any data or "cruft" files. If Docker were to vanish, the answer would become Vagrant running some very common and stable Linux distro with either a config shell-script or ansible yaml, for similar reasons. Documentation, consistency, and isolation. Some people use the above for their projects themselves, for similar reasons, but I just use the now-ubiquitous env and version-manager programs for that (nvm, rvm, that kind of thing). Again: documentation, consistency, and isolation. Even if your dev set-up isn't used for deployment, if it's scripted then it's also accurately documented. As for language-specific libraries and tools, even if a few are in some package manager, I wouldn't rely on them. The language's own package manager will work everywhere, will probably be more (maybe much more) up-to-date, and you're going to need it for some stuff, inevitably, so you may as well use it for everything the project needs from that language. [EDIT] notably, this way of working means none of my/our projects give a shit what OS or package manager anyone is using. Prefer macports to homebrew? Running Void Linux? Slackware? Probably even Windows (I dunno, who cares, it's Windows, but probably it works)? Go nuts with that, live your best life or whatever, the projects don't care. You'll likely need to manually create a Linux VM for Docker if you're on a BSD, but if you're on a BSD that will be the least inconvenience you face this week. I truly don't get why anyone would just "brew install postgresql" or "apt install postgresql" and use whatever happens to come down as an implicit project dependency in this, the year 2021. Because you actually want to directly use a local database to do database things? Sure. For a project that will be distributed or deployed elsewhere? No no no no no. Not even if you're running the same OS as your servers. Or Ruby, or Node, or even your compilers if you can help it. You have to be more specific and keep your shit tidier than that if you don't want a bunch of pain, both now and later, and almost all of that's very easy to do now.