Live data from Hacker News

How to Distribute Binaries for OS X Using Homebrew

octavore.com

61–70 of 84 posts

Re: How to Distribute Binaries for OS X Using Homebrew

#61
post #53
post #18

Earlier quoted context omitted.

Homebrew installs in /usr/local, not in /usr, and OS updates never touch /usr/local. And if you're paranoid, you can instruct Homebrew to install somewhere else instead.

It's a good idea to install elsewhere, because there are other packages that install into /usr/local (TeX, for example) that aren't in homebrew. I like having my homebrew installation totally separate -- I feel significantly more comfortable upgrading my software to bleeding edge versions if there's no chance of some non-homebrew brain-dead configure script grabbing them. I install to ~/.homebrew, and everything work…

The reason that Homebrew defaults to /usr/local is because there are a lot of braindead packages out there that hardcode the possible locations for software (e.g. /usr/lib and /usr/local/lib), and if you install Homebrew somewhere else, you can't use Homebrew to satisfy the dependencies of any such braindead software you come across.

However, if everything you're installing that depends on Homebrew-provided software is also installed through Homebrew, then it should work regardless of location (I say "should" because I suspect that not every single Homebrew formula has actually been tested with a non-/usr/local install path).

Personally, I stick with /usr/local both because I've never had a problem with it, and because that makes it easier when working with software that uses a default PATH (since /usr/local is usually put in these default PATHs). But if you have any concerns whatsoever, then by all means use a different install prefix.

Re: How to Distribute Binaries for OS X Using Homebrew

#62

Earlier quoted context omitted.

Using npm to distribute a shell script, seriously? That's not such a good idea. I think what you want is something like the Autotools so your software may be installed with the standard './configure && make && make install'. This way, you make it easy for upstream distributions to package your software.

Wouldn't that have issues with Windows? I'm not a huge fan of NPM but it works really well when you want to be cross platform.

npm only works well for Windows if the program you're distributing is itself in JavaScript using Node. If you're using npm to distribute a shell script, then you still need a Unixy environment for Windows like Cygwin or MSYS, and in that case, autotools is probably no worse.

Re: How to Distribute Binaries for OS X Using Homebrew

#63

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…

I used macports through two or three upgrades before switching to home-brew last year. Switching was one of the best decisions I ever made. In terms of MacOS package managers -- in the grand scheme of things it's not really a big deal. First world problems, right? MacPorts is very, umm, opinionated. And doesn't seem to trust anything outside of itself. And has some weird opinions, too. Example: For some reason, svn i…

Looks like Subversion is required by nmap-update, part of nmap. http://man7.org/linux/man-pages/man1/nmap-update.1.html

Re: How to Distribute Binaries for OS X Using Homebrew

#64

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.

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-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.

Re: How to Distribute Binaries for OS X Using Homebrew

#65

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.

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.

Re: How to Distribute Binaries for OS X Using Homebrew

#66
post #46

Earlier quoted context omitted.

> 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 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_his... , NeXTSTEP was originally forked in 1988, before Linux really had package m…

I think you are underestimating Apple's apathy when it comes to doing anything of real interest anymore. We don't even get Darwin .iso releases or changelogs anymore. [0] We are left in an arguably worse state of affairs. It's not just sad; it's boring.

[0]: https://opensource.apple.com/static/iso/

Re: How to Distribute Binaries for OS X Using Homebrew

#67
post #53
post #18

Earlier quoted context omitted.

Homebrew installs in /usr/local, not in /usr, and OS updates never touch /usr/local. And if you're paranoid, you can instruct Homebrew to install somewhere else instead.

It's a good idea to install elsewhere, because there are other packages that install into /usr/local (TeX, for example) that aren't in homebrew. I like having my homebrew installation totally separate -- I feel significantly more comfortable upgrading my software to bleeding edge versions if there's no chance of some non-homebrew brain-dead configure script grabbing them. I install to ~/.homebrew, and everything work…

TeX, at least from MacTeX, now installs in /Library/TeX.

Re: How to Distribute Binaries for OS X Using Homebrew

#68
post #41

Earlier quoted context omitted.

> What'd be really interesting is if MAS was rebuilt on top of a package manager. That'd solve both the lack of package management, and most of the MAS's woes. I don't see how it'd solve the primary MAS woes of horrible contributor/developer experience, uncaring maintainership and inflexible sandboxing.

> horrible contributor/developer experience, uncaring maintainership I was imagining a package manager with the standard kind of "add whatever sources to your sources list you like" model, as most Linux distros have. If the MAS was rebuilt in terms of this, then presumably adding a custom package source would make custom apps (which, after all, are just packages) show up in the MAS app for selection as well, just as…

Maemo / MeeGo had what you talk about: a store built on top of apt. If I remember correctly, they managed it by adding (on package install through the store gui) package-specific repositories that required authentication. So you could keep using apt-get in the normal way from free repos, receive updates etc.

Re: How to Distribute Binaries for OS X Using Homebrew

#69
post #31

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…

> the core WTF is this: why doesn't OSX integrate a > package manager for its unixy side? They could, but my guess would be that they don't want friendly-looking tutorials (i.e. ones that the average user wouldn't be scared to follow) saying: > Ah, you just need to update your packages; install foo: > macman -Syu && macman -S foo They don't want to 'have to' offer support for average users accidentally doing 'power u…

Except there are lots of other "power user" things that are built in. Where do you draw the line?

It's more likely that they just consider package management out of scope for their part of development-- something that benefits too few people to be worth the cost. Seems to have paid off, too-- package management has been well-handled on OSX for a long time, both through semi-sanctioned projects like MacPorts (which is community-developed but is hosted by Apple) and through community projects like Fink and Homebrew.

Re: How to Distribute Binaries for OS X Using Homebrew

#70
post #40

Earlier quoted context omitted.

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.

We recently shipped a new updater that parallelizes network requests. The speedup is really appreciable; I have 27 taps and `brew update` now runs under 10 seconds.

Awesome! That's great news
Post reply on HN