8 ms·

How to Distribute Binaries for OS X Using Homebrew

218 points by tpwong 11y ago

0942v8653 11y ago
Rate limit exceeded. http://archive.is/Zp8IQ http://archive.is/Zp8IQ works.
- tpwong 11y ago
  Whoops, thanks for the heads up! Should be fixed now.
Isn0gud 11y ago
Its a bit off topic but is there a good alternative for windows? chocolatey doesn't seem to be a good solution.
- josteink 11y ago
  Scoop? http://scoop.sh/ http://scoop.sh/
- solipsism 11y ago
  What don't you like about Chocolatey?
vayan 11y ago
>Cross-platform app distribution is a hard problem! [...] At least on OS X, things are a little easier with Homebrew well.. yeah.. Every OS has an easy way to distribute binaries, the hard part is having something that work on each of them.
- m_mueller 11y ago
  Every OS ... except Windows?
  - provemewrong 11y ago
    Didn't Windows 10 get PackageManagement FKA OneGet? I mean I haven't upgraded because of privacy, but at least it exists.
    - m_mueller 11y ago
      Interesting, TIL. I wonder how complete it is. E.g. how much work until you have python and pip? gcc? An SMTP Server? A web server?
  - EvanPlaice 11y ago
    Well, there's Chocolatey but that comes with its own set of quirks.
  - SmellyGeekBoy 11y ago
    Windows Store?
    - m_mueller 11y ago
      From a user's perspective maybe (although I find the usefulness of that thing highly questionable on a current Windows 10 computer, it doesn't even have a touch friendly official youtube app last time I checked). But from a dev's perspective, i.e. getting the tools to develop something? Nah, not even close.
guptaneil 11y ago
This is awesome. I was _just_ looking a few days ago for a good tutorial on how to distribute some bash scripts via homebrew and could not find a great resource. Thanks for the writeup.
stepanhruda 11y ago
You don't even need to maintain a separate custom tap repo. Keep the formula in the same repo in a Formula directory, and include the repo URL when tapping (gets rid of the homebrew- restriction) The brew command for users would be: brew tap octavore/delta https://github.com/octavore/delta.git https://github.com/octavore/delta.git brew install delta --- Example above of course doesn't currently work because the formula is not there (I successfully use it in my repo: https://github.com/stepanhruda/ios-simulator-app-installer https://github.com/stepanhruda/ios-simulator-app-installer)
- tpwong 11y ago
  That's awesome, I didn't know about that. I'll update the post with your tip. Thank you!
- guptaneil 11y ago
  I find the method described in the post to be cleaner UX. Sure, it requires a little extra work on your part to setup, but running a single `brew install octavore/tools/delta` is much nicer and easier to remember than brew tap octavore/delta https://github.com/octavore/delta.git https://github.com/octavore/delta.git brew install delta
  - stepanhruda 11y ago
    You're definitely right, just wanted to provide an alternative I found useful. 95% of the time I copy & paste brew commands for custom taps from the repo, I wouldn't remember the 3-part path anyway. This is probably asking for a PR to hombrew, the ideal command would be brew install delta https://github.com/octavore/delta.git https://github.com/octavore/delta.git
- paulirish 11y ago
  A downside of using a tap is that your users subsequent `brew update`s will also have to pull from your repo each time. My current `brew update` has to check 12 separate repos, and takes almost a minute to complete. As a heavy brew user, I'd prefer a packaging convention with less performance impact.
alviria 11y ago
I find OS X's package/dependency management system to be as cobbled together as Windows'. Linux got it right: https://en.wikipedia.org/wiki/Package_manager https://en.wikipedia.org/wiki/Package_manager It drives me crazy that Apple removed one the most amazing features of *nix systems: a unified software repository. Brew/brew cask doesn't come close to AUR.
- masklinn 11y ago
  > It drives me crazy that Apple removed one the most amazing features of *nix systems: a unified software repository. It's not a feature of unices, it's a feature of _Linux_ (Ian Murdoch called it "the single biggest advancement Linux has brought to the industry"[0]). The vast majority of unices never had a "unified software repository", and BSDs (probably the least indirect ancestor of OSX) have port trees, which at the time OSX was born (ignoring the NeXTSTEP ancestry which predates "modern" BSDs and builds directly from 4.3BSD) were a very different beast and not something suitable proprietary unices (because Apple wasn't going to give the OSX commit bit to randos). And hell, both apt and rpm were busy _being born_, the premier package managers at the time were raw dpkg and pms(1). And pkgtool[1] I guess? [0] http://ianmurdock.com/solaris/how-package-management-changed-everything/ http://ianmurdock.com/solaris/how-package-management-changed... [1] http://www.slackware.com/config/packages.php http://www.slackware.com/config/packages.php
  - alviria 11y ago
    The problem I'm seeing is that what OS X has isn't a unified system, and what Apple promotes isn't want developers want to/can use. So you see time and effort going into tools like this that only last a few years. It results in more fracturing in the end. In this popular diagram, https://upload.wikimedia.org/wikipedia/commons/7/77/Unix_history-simple.svg https://upload.wikimedia.org/wikipedia/commons/7/77/Unix_his..., NeXTSTEP was originally forked in 1988, before Linux really had package management put together. Darwin is from 2001. Is 14 years not enough time to establish a proprietor supported unified package management system? My expectations may just be set too high.
    - 11y ago
ricardobeat 11y ago
This is still quite a bit more work than publishing to npm: 1. Jump to separate repository 2. Create a .tar.gz with sensitive filename 3. "upload somewhere" 4. Manually update formula, sha, version 4. Push Versus: 1. npm bump && npm publish I ended up automating the formula updating after getting tired of doing that every other day, for a private tap.
- tpwong 11y ago
  I feel your pain, part of the motivation for writing this was that yesterday I wanted to set up a new project, and realized I'd forgotten half the steps. Been thinking that something like https://github.com/aktau/github-release https://github.com/aktau/github-release could be helpful for automating the release process, or maybe adding it as a step in a CI workflow.
AceJohnny2 11y ago
I've been forcefully switched to OS X recently because work, and overall it's been pretty great (I view it as a well-integrated UI over FreeBSD). A couple of things drive me nuts though: * (the window manager sucks, but that's not the topic. I had to get it out) * it needs a good package manager For us ol' bearded folk (at least spiritually), OS X comes with a slew of unix tools we love. It already includes both vim AND emacs! However, these tools are hopelessly outdated: Despite OS X 10.11 "El Capitan" coming out last fall, Vim is still 7.3 (that's from August 2010. 2010!), and Emacs 22 (2007. That's right.) So some enterprising folk come to the rescue: Fink, Homebrew, Macports... Homebrew installs over /usr, so come the next OS update, all that gets squashed. Macports installs into /opt/local, but somehow doesn't survive an OS update. Also, when I tried installing SciPy it went and recompiled GCC4 from source. Guys, the 90s called, and it's been shown that recompiling from source for each user isn't worth the effort. Apple gave MacPorts some support in the form of equipment, so there's some hints of their preferred method. But the core WTF is this: why doesn't OSX integrate a package manager for its unixy side?
- wlesieutre 11y ago
  Given both the outdated vim/emacs/etc. releases and they've handled the Mac App Store, would you want Apple to be running the platform's main package manager? Do I wish the 3rd party ones could be better integrated with the OS? Sure. But I'm definitely thankful it isn't Apple calling the shots (or more likely, releasing it and then refusing to call any shots at all for 8 years).
- cdbattags 11y ago
  They've actually separated out usr/local from all the security stuff leaving Homebrew free and clear for the next OS update
- masklinn 11y ago
  > For us ol' bearded folk (at least spiritually), OS X comes with a slew of unix tools we love. It already includes both vim AND emacs! However, these tools are hopelessly outdated: Despite OS X 10.11 "El Capitan" coming out last fall, Vim is still 7.3 (that's from August 2010. 2010!), and Emacs 22 (2007. That's right.) And that's way more up to date than it used to be. > Apple gave MacPorts some support in the form of equipment, so there's some hints of their preferred method. But the core WTF is this: why doesn't OSX integrate a package manager for its unixy side? Yeah who hasn't dreamt of a package manager handled like MAS. I'd be happy if Apple helped package managers more, contributed (financially) to them and better took them in account or discussed stuff with them wrt major releases (see: Yosemite homebew woes), but I'm really quite glad the community is completely in charge of macports or homebrew or nix.
chris_st 11y ago
I guess you have to do this to avoid the name clash with Tigris's delta[0], which is the default if you do `brew install delta`? I'm not sure this is the best solution. [0] http://delta.tigris.org http://delta.tigris.org
mschuster91 11y ago
Homebrew sucks on multi-user systems (especially if the Mac in question has previously been single-user) or after the Mac changes its owner/becomes a shared one (company laptop). Macports handles this usecase far, far better. Give your users sudo rights and be done. Only thing it desperately lacks is allowing third-party additional repositories like Debian's apt does.
- matt_wulfeck 11y ago
  It always bugs me when people don't wipe laptops before handing them off.
  - mschuster91 11y ago
    In a company environment with shared machines?
- draebek 11y ago
  You can have additional MacPorts repositories, though I'm sure they're not nearly as configurable as in APT. See, for example, https://guide.macports.org/chunked/development.local-repositories.html https://guide.macports.org/chunked/development.local-reposit.... Instead of local, the repository you add could be remote. That said, I don't believe I've ever seen a third-party MacPorts repository in the wild.
- mook 11y ago
  It's not the default thing to do, but I've found that installing Homebrew under your home directory to work well. Everything's owned by that user, and there are no issues with shared machines (since other users don't see it at all). The downside is that casks (i.e. pre-built installers) might still end up installing things outside, but that would have been the same without Homebrew existing in the first place.
OJFord 11y ago
> when a post on better diffs showed up on Hacker News > last week ... people below are asking why a bash script > (that depends on a perl script) is being recommended to > install via NPM? [cont. about using Homebrew] This post is useful in general, but just to circle back on its motivation, for anyone wanting a non-npm (brew) install of the aforementioned diff tool (diff-so-fancy, not made by me) - I've a PR pending merge - Homebrew/homebrew#49040 [0]. In the mean time, you can tap it: % brew tap OJFord/formulae % brew install diff-so-fancy [0](https://github.com/Homebrew/homebrew/pull/49040 https://github.com/Homebrew/homebrew/pull/49040)
paulirish 11y ago
> At least on OS X, things are a little easier with Homebrew. Absolutely. I adore Homebrew and it's ecosystem. Cask, in particular, is quite satisfying; gotta love installing a swath of neccessary fonts from the terminal. And, fwiw, the project is about to be on Homebrew, with no tap required: https://github.com/Homebrew/homebrew/pull/49040 https://github.com/Homebrew/homebrew/pull/49040 Though getting it up was not quite as pain-free than our initial publishes to NPM. The thing is: Homebrew solves the problem for just a portion of your audience. In diff-so-fancy's case, we've supported Linux and Windows from the get-go, the only hard part is getting it installed. NPM solves that problem really well, and I can't imagine any other installation technique being our recommendation for Windows/Linux going forward.
- joshmanders 11y ago
  Linux Homebrew[0] can cover it for linux. Just need Windows Homebrew. [0]: https://github.com/Linuxbrew/linuxbrew https://github.com/Linuxbrew/linuxbrew
  - alviria 11y ago
    Wait, what problem is this solving?
    - idle_zealot 11y ago
      > Can install software to a home directory and so does not require sudo > Install software not packaged by the native distribution > Install up-to-date versions of software when the native distribution is old > Use the same package manager to manage both your Mac and Linux machines From the "Features" section of the Github. It could also likely be used so make a "safe" Linux distro, where the base system is mounted read only, with a writable home partition.
- rubiquity 11y ago
  This only makes sense if you believe all Homebrew packages are written in JavaScript... which they aren't. Also I've been using Homebrew for about 4x as long as NPM and I have about 1/10th of the issues, so I'll just stick to the package manager that works.
hk__2 11y ago
You don’t even need to check the SHA256 by hand, just use `brew create <tarball URL>`. It’ll create a formula with a sensible name, fetch its URL, populate the SHA256, and open the file in your editor. However note it’ll create it in the core formula directory instead of your tap; you’ll need to move it yourself.
rdl 11y ago
I still use macports; what's the current state of opinion of homebrew vs. fink vs. macports?
- knodi123 11y ago
  the current trend, based on what I've seen open-source projects using, seems to be strongly towards homebrew. Not sure if I've seen a project recommending install via fink in quite a few years.
mongosucks 11y ago
Interesting
shiftoutbox 11y ago
Step 1 use pkgsrc . Not joyent's pkgsrc , but real pkgsrc . Step 2 see step 1.
- shiftoutbox 11y ago
  Step 0 don't use homebrew .
ksherlock 11y ago
I stumbled across this idea a few weeks ago to install some build software on an os x travis ci build machine (using OS X is the easiest way for travis ci to use a C++ compiler that isn't obsolete). Anyhow, it's nice and simple approach that works.
zwetan 11y ago
>Cross-platform app distribution is a hard problem! indeed, but couple of things specific to Mac OS X: there are homebrew, macports, fink and probably more distributing with homebrew to someone who already going with macports is problematic for example as it is advised to not have both installed. One alternative is to distribute a pkg and so use PackageMaker to build one. A pkg has the pros to be native to Apple, but the cons to not work for other systems like Windows and Linux. So here another alternative: Debian packages (deb). Wether with macports, homebrew or fink you can install the command line utility dpkg, and using dpkg-deb you can build deb supporting the darwin-amd64 arch. For Windows, you can use the utility wpkg, http://windowspackager.org/ http://windowspackager.org/ and with it you can build deb packages for win32 and win64 architectures. Ultimately if you distribute command-line tools (not GUI app), you can use deb packages for Windows, Mac OS X and Linux Debian (Ubuntu etc.) Here an example (one of my tools that I need to distrib/install on servers): https://github.com/Corsaair/as3shebang/releases/tag/1.0.0 https://github.com/Corsaair/as3shebang/releases/tag/1.0.0 Debian packages for everyone :) Linux and Mac OS X install: dpkg -i as3shebang_1.0.0_amd64.deb Windows install: wpkg -i as3shebang_1.0.0_win64.deb You can see the build scripts at the root of the repo, they are pretty similar. Also, once you have deb packages you can also convert them to rpm and other nix-like packages usinga tool like alien, see https://en.wikipedia.org/wiki/Alien_(software) https://en.wikipedia.org/wiki/Alien_(software).

218 points by tpwong 11y ago

0942v8653 11y ago

Rate limit exceeded. http://archive.is/Zp8IQ http://archive.is/Zp8IQ works.

tpwong 11y ago
Whoops, thanks for the heads up! Should be fixed now.

Isn0gud 11y ago

Its a bit off topic but is there a good alternative for windows? chocolatey doesn't seem to be a good solution.

josteink 11y ago
Scoop? http://scoop.sh/ http://scoop.sh/
solipsism 11y ago
What don't you like about Chocolatey?

vayan 11y ago

>Cross-platform app distribution is a hard problem! [...] At least on OS X, things are a little easier with Homebrew well.. yeah.. Every OS has an easy way to distribute binaries, the hard part is having something that work on each of them.

m_mueller 11y ago
Every OS ... except Windows?
- provemewrong 11y ago
  Didn't Windows 10 get PackageManagement FKA OneGet? I mean I haven't upgraded because of privacy, but at least it exists.
  - m_mueller 11y ago
    Interesting, TIL. I wonder how complete it is. E.g. how much work until you have python and pip? gcc? An SMTP Server? A web server?
- EvanPlaice 11y ago
  Well, there's Chocolatey but that comes with its own set of quirks.
- SmellyGeekBoy 11y ago
  Windows Store?
  - m_mueller 11y ago
    From a user's perspective maybe (although I find the usefulness of that thing highly questionable on a current Windows 10 computer, it doesn't even have a touch friendly official youtube app last time I checked). But from a dev's perspective, i.e. getting the tools to develop something? Nah, not even close.

guptaneil 11y ago

This is awesome. I was _just_ looking a few days ago for a good tutorial on how to distribute some bash scripts via homebrew and could not find a great resource. Thanks for the writeup.

stepanhruda 11y ago

You don't even need to maintain a separate custom tap repo. Keep the formula in the same repo in a Formula directory, and include the repo URL when tapping (gets rid of the homebrew- restriction) The brew command for users would be: brew tap octavore/delta https://github.com/octavore/delta.git https://github.com/octavore/delta.git brew install delta --- Example above of course doesn't currently work because the formula is not there (I successfully use it in my repo: https://github.com/stepanhruda/ios-simulator-app-installer https://github.com/stepanhruda/ios-simulator-app-installer)

tpwong 11y ago
That's awesome, I didn't know about that. I'll update the post with your tip. Thank you!
guptaneil 11y ago
I find the method described in the post to be cleaner UX. Sure, it requires a little extra work on your part to setup, but running a single `brew install octavore/tools/delta` is much nicer and easier to remember than brew tap octavore/delta https://github.com/octavore/delta.git https://github.com/octavore/delta.git brew install delta
- stepanhruda 11y ago
  You're definitely right, just wanted to provide an alternative I found useful. 95% of the time I copy & paste brew commands for custom taps from the repo, I wouldn't remember the 3-part path anyway. This is probably asking for a PR to hombrew, the ideal command would be brew install delta https://github.com/octavore/delta.git https://github.com/octavore/delta.git
paulirish 11y ago
A downside of using a tap is that your users subsequent `brew update`s will also have to pull from your repo each time. My current `brew update` has to check 12 separate repos, and takes almost a minute to complete. As a heavy brew user, I'd prefer a packaging convention with less performance impact.

alviria 11y ago

I find OS X's package/dependency management system to be as cobbled together as Windows'. Linux got it right: https://en.wikipedia.org/wiki/Package_manager https://en.wikipedia.org/wiki/Package_manager It drives me crazy that Apple removed one the most amazing features of *nix systems: a unified software repository. Brew/brew cask doesn't come close to AUR.

masklinn 11y ago
> It drives me crazy that Apple removed one the most amazing features of *nix systems: a unified software repository. It's not a feature of unices, it's a feature of _Linux_ (Ian Murdoch called it "the single biggest advancement Linux has brought to the industry"[0]). The vast majority of unices never had a "unified software repository", and BSDs (probably the least indirect ancestor of OSX) have port trees, which at the time OSX was born (ignoring the NeXTSTEP ancestry which predates "modern" BSDs and builds directly from 4.3BSD) were a very different beast and not something suitable proprietary unices (because Apple wasn't going to give the OSX commit bit to randos). And hell, both apt and rpm were busy _being born_, the premier package managers at the time were raw dpkg and pms(1). And pkgtool[1] I guess? [0] http://ianmurdock.com/solaris/how-package-management-changed-everything/ http://ianmurdock.com/solaris/how-package-management-changed... [1] http://www.slackware.com/config/packages.php http://www.slackware.com/config/packages.php
- alviria 11y ago
  The problem I'm seeing is that what OS X has isn't a unified system, and what Apple promotes isn't want developers want to/can use. So you see time and effort going into tools like this that only last a few years. It results in more fracturing in the end. In this popular diagram, https://upload.wikimedia.org/wikipedia/commons/7/77/Unix_history-simple.svg https://upload.wikimedia.org/wikipedia/commons/7/77/Unix_his..., NeXTSTEP was originally forked in 1988, before Linux really had package management put together. Darwin is from 2001. Is 14 years not enough time to establish a proprietor supported unified package management system? My expectations may just be set too high.
  - 11y ago

ricardobeat 11y ago

This is still quite a bit more work than publishing to npm: 1. Jump to separate repository 2. Create a .tar.gz with sensitive filename 3. "upload somewhere" 4. Manually update formula, sha, version 4. Push Versus: 1. npm bump && npm publish I ended up automating the formula updating after getting tired of doing that every other day, for a private tap.

tpwong 11y ago
I feel your pain, part of the motivation for writing this was that yesterday I wanted to set up a new project, and realized I'd forgotten half the steps. Been thinking that something like https://github.com/aktau/github-release https://github.com/aktau/github-release could be helpful for automating the release process, or maybe adding it as a step in a CI workflow.

AceJohnny2 11y ago

I've been forcefully switched to OS X recently because work, and overall it's been pretty great (I view it as a well-integrated UI over FreeBSD). A couple of things drive me nuts though: * (the window manager sucks, but that's not the topic. I had to get it out) * it needs a good package manager For us ol' bearded folk (at least spiritually), OS X comes with a slew of unix tools we love. It already includes both vim AND emacs! However, these tools are hopelessly outdated: Despite OS X 10.11 "El Capitan" coming out last fall, Vim is still 7.3 (that's from August 2010. 2010!), and Emacs 22 (2007. That's right.) So some enterprising folk come to the rescue: Fink, Homebrew, Macports... Homebrew installs over /usr, so come the next OS update, all that gets squashed. Macports installs into /opt/local, but somehow doesn't survive an OS update. Also, when I tried installing SciPy it went and recompiled GCC4 from source. Guys, the 90s called, and it's been shown that recompiling from source for each user isn't worth the effort. Apple gave MacPorts some support in the form of equipment, so there's some hints of their preferred method. But the core WTF is this: why doesn't OSX integrate a package manager for its unixy side?

wlesieutre 11y ago
Given both the outdated vim/emacs/etc. releases and they've handled the Mac App Store, would you want Apple to be running the platform's main package manager? Do I wish the 3rd party ones could be better integrated with the OS? Sure. But I'm definitely thankful it isn't Apple calling the shots (or more likely, releasing it and then refusing to call any shots at all for 8 years).
cdbattags 11y ago
They've actually separated out usr/local from all the security stuff leaving Homebrew free and clear for the next OS update
masklinn 11y ago
> For us ol' bearded folk (at least spiritually), OS X comes with a slew of unix tools we love. It already includes both vim AND emacs! However, these tools are hopelessly outdated: Despite OS X 10.11 "El Capitan" coming out last fall, Vim is still 7.3 (that's from August 2010. 2010!), and Emacs 22 (2007. That's right.) And that's way more up to date than it used to be. > Apple gave MacPorts some support in the form of equipment, so there's some hints of their preferred method. But the core WTF is this: why doesn't OSX integrate a package manager for its unixy side? Yeah who hasn't dreamt of a package manager handled like MAS. I'd be happy if Apple helped package managers more, contributed (financially) to them and better took them in account or discussed stuff with them wrt major releases (see: Yosemite homebew woes), but I'm really quite glad the community is completely in charge of macports or homebrew or nix.

chris_st 11y ago

I guess you have to do this to avoid the name clash with Tigris's delta[0], which is the default if you do `brew install delta`? I'm not sure this is the best solution. [0] http://delta.tigris.org http://delta.tigris.org

mschuster91 11y ago

Homebrew sucks on multi-user systems (especially if the Mac in question has previously been single-user) or after the Mac changes its owner/becomes a shared one (company laptop). Macports handles this usecase far, far better. Give your users sudo rights and be done. Only thing it desperately lacks is allowing third-party additional repositories like Debian's apt does.

matt_wulfeck 11y ago
It always bugs me when people don't wipe laptops before handing them off.
- mschuster91 11y ago
  In a company environment with shared machines?
draebek 11y ago
You can have additional MacPorts repositories, though I'm sure they're not nearly as configurable as in APT. See, for example, https://guide.macports.org/chunked/development.local-repositories.html https://guide.macports.org/chunked/development.local-reposit.... Instead of local, the repository you add could be remote. That said, I don't believe I've ever seen a third-party MacPorts repository in the wild.
mook 11y ago
It's not the default thing to do, but I've found that installing Homebrew under your home directory to work well. Everything's owned by that user, and there are no issues with shared machines (since other users don't see it at all). The downside is that casks (i.e. pre-built installers) might still end up installing things outside, but that would have been the same without Homebrew existing in the first place.

OJFord 11y ago

> when a post on better diffs showed up on Hacker News > last week ... people below are asking why a bash script > (that depends on a perl script) is being recommended to > install via NPM? [cont. about using Homebrew] This post is useful in general, but just to circle back on its motivation, for anyone wanting a non-npm (brew) install of the aforementioned diff tool (diff-so-fancy, not made by me) - I've a PR pending merge - Homebrew/homebrew#49040 [0]. In the mean time, you can tap it: % brew tap OJFord/formulae % brew install diff-so-fancy [0](https://github.com/Homebrew/homebrew/pull/49040 https://github.com/Homebrew/homebrew/pull/49040)

paulirish 11y ago

> At least on OS X, things are a little easier with Homebrew. Absolutely. I adore Homebrew and it's ecosystem. Cask, in particular, is quite satisfying; gotta love installing a swath of neccessary fonts from the terminal. And, fwiw, the project is about to be on Homebrew, with no tap required: https://github.com/Homebrew/homebrew/pull/49040 https://github.com/Homebrew/homebrew/pull/49040 Though getting it up was not quite as pain-free than our initial publishes to NPM. The thing is: Homebrew solves the problem for just a portion of your audience. In diff-so-fancy's case, we've supported Linux and Windows from the get-go, the only hard part is getting it installed. NPM solves that problem really well, and I can't imagine any other installation technique being our recommendation for Windows/Linux going forward.

joshmanders 11y ago
Linux Homebrew[0] can cover it for linux. Just need Windows Homebrew. [0]: https://github.com/Linuxbrew/linuxbrew https://github.com/Linuxbrew/linuxbrew
- alviria 11y ago
  Wait, what problem is this solving?
  - idle_zealot 11y ago
    > Can install software to a home directory and so does not require sudo > Install software not packaged by the native distribution > Install up-to-date versions of software when the native distribution is old > Use the same package manager to manage both your Mac and Linux machines From the "Features" section of the Github. It could also likely be used so make a "safe" Linux distro, where the base system is mounted read only, with a writable home partition.
rubiquity 11y ago
This only makes sense if you believe all Homebrew packages are written in JavaScript... which they aren't. Also I've been using Homebrew for about 4x as long as NPM and I have about 1/10th of the issues, so I'll just stick to the package manager that works.

hk__2 11y ago

You don’t even need to check the SHA256 by hand, just use `brew create <tarball URL>`. It’ll create a formula with a sensible name, fetch its URL, populate the SHA256, and open the file in your editor. However note it’ll create it in the core formula directory instead of your tap; you’ll need to move it yourself.

rdl 11y ago

I still use macports; what's the current state of opinion of homebrew vs. fink vs. macports?

knodi123 11y ago
the current trend, based on what I've seen open-source projects using, seems to be strongly towards homebrew. Not sure if I've seen a project recommending install via fink in quite a few years.

mongosucks 11y ago

Interesting

shiftoutbox 11y ago

Step 1 use pkgsrc . Not joyent's pkgsrc , but real pkgsrc . Step 2 see step 1.

shiftoutbox 11y ago
Step 0 don't use homebrew .

ksherlock 11y ago

I stumbled across this idea a few weeks ago to install some build software on an os x travis ci build machine (using OS X is the easiest way for travis ci to use a C++ compiler that isn't obsolete). Anyhow, it's nice and simple approach that works.

zwetan 11y ago

>Cross-platform app distribution is a hard problem! indeed, but couple of things specific to Mac OS X: there are homebrew, macports, fink and probably more distributing with homebrew to someone who already going with macports is problematic for example as it is advised to not have both installed. One alternative is to distribute a pkg and so use PackageMaker to build one. A pkg has the pros to be native to Apple, but the cons to not work for other systems like Windows and Linux. So here another alternative: Debian packages (deb). Wether with macports, homebrew or fink you can install the command line utility dpkg, and using dpkg-deb you can build deb supporting the darwin-amd64 arch. For Windows, you can use the utility wpkg, http://windowspackager.org/ http://windowspackager.org/ and with it you can build deb packages for win32 and win64 architectures. Ultimately if you distribute command-line tools (not GUI app), you can use deb packages for Windows, Mac OS X and Linux Debian (Ubuntu etc.) Here an example (one of my tools that I need to distrib/install on servers): https://github.com/Corsaair/as3shebang/releases/tag/1.0.0 https://github.com/Corsaair/as3shebang/releases/tag/1.0.0 Debian packages for everyone :) Linux and Mac OS X install: dpkg -i as3shebang_1.0.0_amd64.deb Windows install: wpkg -i as3shebang_1.0.0_win64.deb You can see the build scripts at the root of the repo, they are pretty similar. Also, once you have deb packages you can also convert them to rpm and other nix-like packages usinga tool like alien, see https://en.wikipedia.org/wiki/Alien_(software) https://en.wikipedia.org/wiki/Alien_(software).