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

71–80 of 255 posts

Re: Homebrew 1.0.0

#71

Post by davb »

rwl4 wrote: post #40
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…

It's for this very reason that I'm still one of those old-school guys who still uses MacPorts. I was horrified to see this, and in my brief time using it, it actually caused me real problems, so I went back.

I switched to MacPorts following the Google Analytics debacle [1] and how it was handled [2]. I had this expectation that MacPorts would be backwards and full of ancient packages but it's not - it's fantastic! The package repository is really good, the project itself is stable and it doesn't have a default-on analytics component aggregating my package data at Google.

[1] https://news.ycombinator.com/item?id=11566720

[2] https://github.com/Homebrew/brew/issues/142

Re: Homebrew 1.0.0

#72

Post by adrianm »

oefrha wrote: post #47
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…

"everything is fine until YourLib 2.0 comes out, at which point users doing `brew install myapp` will start getting cryptic compiler errors." Sorry, this is just not true, we hold merging YourLib 2.0 into core until all dependents are upgraded or boneyarded. Maybe you're speaking from your outdated experience with brew years ago. Also, we do have plans to support multiple versions of libraries, see https://github.com…

Thanks for trying to support multiple major versions! I run into this problem all of the time with LLVM and its dependencies. I'd love to get have the latest LLVM available for my own work (which depend on the static libraries it builds), but also be able to use tools which depend on older versions of LLVM.

Re: Homebrew 1.0.0

#73

Post by adidalal »

Just wanted to highlight that as of this release, all the core code for Homebrew-Cask (the sister project for GUI apps) has been (re)integrated into the Brew codebase. This should allow for tighter integration between the two and a renewed focus on making installing GUI apps as painless as possible!

From a user/developer perspective, we've created a command line utility (`cask-repair`) to make version bumps as painless as possible. Would love to see more people using it [0], and we welcome suggestions and PRs (we have a few long-standing issues that have gone unaddressed, and fresh eyes are always good!)

[0] https://github.com/caskroom/homebrew-cask/blob/master/CONTRI...

Re: Homebrew 1.0.0

#74

Post by mjhoy »

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…

An argument for this approach is that it keeps the ecosystem healthy. Instead of a lot upper version bounds to keep track of and conflicting dependencies, broken dependents are fixed upstream if they don't build. As I understand it nixpkgs, in general, works this way.

Re: Homebrew 1.0.0

#75

Post by mirekrusin »

Be aware of "update bug"

If Homebrew was updated on Aug 10-11th 2016 and brew update always says "Already up-to-date". you need to run:

``` cd "$(brew --repo)" && git fetch && git reset --hard origin/master && brew update ```

I had to.

Re: Homebrew 1.0.0

#76

Post by rogual »

oefrha wrote: post #50
oefrha wrote: post #47

Earlier quoted context omitted.

"everything is fine until YourLib 2.0 comes out, at which point users doing `brew install myapp` will start getting cryptic compiler errors." Sorry, this is just not true, we hold merging YourLib 2.0 into core until all dependents are upgraded or boneyarded. Maybe you're speaking from your outdated experience with brew years ago. Also, we do have plans to support multiple versions of libraries, see https://github.com…

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.

Re: Homebrew 1.0.0

#77

Post by dcosson »

adidalal wrote: post #73

Just wanted to highlight that as of this release, all the core code for Homebrew-Cask (the sister project for GUI apps) has been (re)integrated into the Brew codebase. This should allow for tighter integration between the two and a renewed focus on making installing GUI apps as painless as possible! From a user/developer perspective, we've created a command line utility (`cask-repair`) to make version bumps as painle…

Looking forward to checking this out. One issue I have run into with homebrew is that due to varying packaging choices as a project grows, I've seen stuff move back and forth from brew core to cask to neither, and the old ones stick around at the outdated version so you have to be careful when you tell people to install the thing (seen this happen with terraform for example, which a month ago when I last checked existed as a year-old version in a cask, a few months old version in core, and the current version wasn't available in either).

It might be cool to also allow some kind of process for marking packages as deprecated and showing a warning or confirmation prompt if you try to install it, for the cases when maintainers start packaging in some different way that can't be supported by homebrew.

Re: Homebrew 1.0.0

#78

Post by RodgerTheGreat »

davb wrote: post #71
rwl4 wrote: post #40

Earlier quoted context omitted.

It's for this very reason that I'm still one of those old-school guys who still uses MacPorts. I was horrified to see this, and in my brief time using it, it actually caused me real problems, so I went back.

I switched to MacPorts following the Google Analytics debacle [1] and how it was handled [2]. I had this expectation that MacPorts would be backwards and full of ancient packages but it's not - it's fantastic! The package repository is really good, the project itself is stable and it doesn't have a default-on analytics component aggregating my package data at Google. [1] https://news.ycombinator.com/item?id=11566720…

Wow. Thanks for bringing this to my attention. I recently got a new mac and I decided to give brew a spin as my package manager. I was unimpressed with many aspects of the experience- for example, getting weird snarky messages and incorrect advice when I attempted to install texlive- but this seals it.

Back to Macports it is. I'll be sure to tell others about this.

Re: Homebrew 1.0.0

#79

Post by rrdharan »

dudul wrote: post #68
adrianN wrote: post #63

Earlier quoted context omitted.

> no more visiting the app store You answered your own question.

True for Cask, but unless I'm mistaken, cask is a plugin for Homebrew. It is not part of the vanilla install.

That has changed - it's now part of the main project.

Re: Homebrew 1.0.0

#80

Post by jwarren »

emdowling wrote: post #7

There has been a lot of talk in HN comments recently about Homebrew installing to `/usr/local`. With macOS Sierra, the user can no longer write to this folder without specifically owning it. Is there a security risk here and if so, whats the best workaround?

I've always installed to ~/.homebrew, and never encountered any problems.
Post reply on HN