Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Homebrew 1.0.0

brew.sh

Post reply on HN
Print view View original

121–130 of 255 posts

Re: Homebrew 1.0.0

#121

Post by oefrha »

Keyframe wrote: post #116

I have a stupid question. Is there a dogmatic way of listing installed things and sharing that with other brew? For example, I now list with brew list into a file and edit the file so that whole list is a big brew install. That way if I reinstall OS or go to another I can have same things.

You can use brew-bundle for that. https://github.com/Homebrew/homebrew-bundle

On one machine:

  brew bundle dump
On another machine:

  brew bundle

Re: Homebrew 1.0.0

#123

Post by mikemcquaid »

s_kilk wrote: post #110
mikemcquaid wrote: post #92

Earlier quoted context omitted.

That's an exaggeration. We definitely do dependency management, we just don't allow formulae in core to pin against arbitrary versions of software because it often means security updates are never tracked. We are going to loosen this slightly but not dramatically: https://github.com/Homebrew/brew/issues/620

Thanks for the clarification. However, if Foo depends on Bar, will homebrew track the dependency so that I can't upgrade Bar to a version incompatible with the existing installation of Foo? I recall running into that issue a while back, and it gave the impression of version tracking being an install-time-only deal.

In homebrew/core and within taps we ensure those cases are handled by `revision`s and CI checks. Across taps this is harder and we're working on it.

Re: Homebrew 1.0.0

#124

Post by mikemcquaid »

mikepurvis wrote: post #48
rogual wrote: post #35

As a user, Homebrew is a great experience. As a package maintainer, though, one thing surprised me: you can't make your package depend on a specific version -- even a major version -- of a library. So if MyApp uses YourLib 1.0, everything is fine until YourLib 2.0 comes out, at which point users doing `brew install myapp` will start getting cryptic compiler errors. I have no choice but to drop whatever I'm doing and…

As someone who maintain a ROS installation scheme for Mac based on homebrew ( https://github.com/mikepurvis/ros-install-osx ), this is a constant source of frustration. Even a fairly vanilla ROS installation has a deep dependency tree— there are any of several dozen major packages which can at any moment release a new major version and break us.

If you rely heavily on Homebrew in this way you should instead vendor all the formulae you depend on so that updates do not happen without your manual intervention.

Re: Homebrew 1.0.0

#125

Post by Keyframe »

oefrha wrote: post #121
Keyframe wrote: post #116

I have a stupid question. Is there a dogmatic way of listing installed things and sharing that with other brew? For example, I now list with brew list into a file and edit the file so that whole list is a big brew install. That way if I reinstall OS or go to another I can have same things.

You can use brew-bundle for that. https://github.com/Homebrew/homebrew-bundle On one machine: brew bundle dump On another machine: brew bundle

Well, that's a neat approach!

Re: Homebrew 1.0.0

#126

Post by mikemcquaid »

FabHK wrote: post #94

Brew is awesome. Note though that it gathers anonymous aggregate user behaviour analytics and reports to Google Analytics, see https://git.io/brew-analytics . You can opt out with brew analytics off

That's obviously fine for you to do but it's worth noting that we remove software that no-one uses where "no-one" is defined by "no-one using analytics". That's actually our main use-case for analytics.

Re: Homebrew 1.0.0

#127

Post by tbrock »

I've worked with mike to maintain formula for years and he is always pleasant and on top of things in what is a very hectic job.

Homebrew is such a good package manager (and not for the reasons any package manager is classically considered good). It's great because the community is so vibrant, the user experience is so well thought out, and the formula dsl makes so much logical sense. It's actually both a GitHub and Ruby showcase.

Thanks homebrew team! Here to many more years of accessible packages on the Mac.

Re: Homebrew 1.0.0

#128

Post by mikemcquaid »

_RPM wrote: post #104
laurent123456 wrote: post #31

Homebrew is quite an achievement, it grew in complexity over the years, yet remained reliable and kept a user-friendly interface. It's also very simple to create packages, it took me less 30 min to learn how to create a package and to deploy it. In comparison last time I checked, creating deb packages is absurdly complex, and I usually just give up and provide a Bash file instead.

I find your statement laughable. Brew and Debian's package manager aren't even comparable.

It's easier to create packages for Homebrew but, as I'd be the first to admit, `apt-get` has far more advanced dependency management and resolution. They both have their strengths and weaknesses.

Re: Homebrew 1.0.0

#129

Post by mikemcquaid »

Flimm wrote: post #21
pcr0 wrote: post #20

Earlier quoted context omitted.

Isn't it there already? https://github.com/Linuxbrew/brew

I don't know much about Linuxbrew, but that looks like a fork, not Homebrew officially supporting Linux.

We're attempting to merge the two projects so eventually Linuxbrew/brew can go away. It's a relatively slow process, though.

Re: Homebrew 1.0.0

#130

Post by oefrha »

rogual wrote: post #76
oefrha wrote: post #50

Earlier quoted context omitted.

To be clear: I'm only talking about core here. If you try to compile external software against brewed libraries, of course you may run into problems, but we do have the homebrew/versions tap, and you can always host your own taps for outdated libraries.

Thanks for responding. Yeah, my package isn't in core, although it seems I would just have a different problem if it were (upgrade to YourLib 2.0 or get boneyarded) I get that it's all a tradeoff, and it must to help keep complexity down if brew is latest-everything. New versions stuff looks good. I'll look into the versions tap too.

> I would just have a different problem if it were (upgrade to YourLib 2.0 or get boneyarded)

In core this is true. In your own tap you can vendor your dependencies however you want.

Post reply on HN