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

241–250 of 255 posts

Re: Homebrew 1.0.0

#241

Post by mikemcquaid »

a-no-n wrote: post #238
mikemcquaid wrote: post #178

Earlier quoted context omitted.

In short: we generally only remove things when they break, break other things or the projects are dead. How hard we try to fix these things generally come down to how used our analytics say they are.

How did the "royal we" arrive at this "reasoning?" If popularity were a valid signal of importance, people should only express their eternal love for PHP and Javascript, and ignore computer science, functional programming languages, computer engineering and little-known-but-really-fucking-important packages. Call me ageist, but code churn and labeling projects "dead" adds nothing in the context of portable code which…

If projects are portable and continue to work without patching indefinitely: we don't consider them dead. What we're unwilling to do is to apply patch after patch to unmaintained and undeveloped projects to keep them working on macOS; at that point we're forking the project and lack either the desire nor people power to do so.

Re: Homebrew 1.0.0

#242

Post by mikemcquaid »

kawsper wrote: post #236
mikemcquaid wrote: post #126

Earlier quoted context omitted.

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.

Couldn't you just look at the download numbers instead?

We don't host any non-binary downloads so: no.

Re: Homebrew 1.0.0

#243

Post by mikemcquaid »

heuermh wrote: post #229
mikemcquaid wrote: post #178

Earlier quoted context omitted.

In short: we generally only remove things when they break, break other things or the projects are dead. How hard we try to fix these things generally come down to how used our analytics say they are.

Are the usage analytics available to package maintainers? What about in downstream taps such as Homebrew-Versions and Homebrew-Science? Would be nice to know when it comes to grant writing time.

We can make them available on request. Email me.

Re: Homebrew 1.0.0

#244

Post by mikemcquaid »

mikepurvis wrote: post #234
mikemcquaid wrote: post #124

Earlier quoted context omitted.

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.

That's basically what is done, on a piecemeal basis as things break, but it would be untenable to do it for the dozens of system dependencies, especially when I don't have the resources to set up a whole parallel bottling infrastructure. In the end, most ROS Mac users still choose an Ubuntu, Debian, or Fedora VM— having a stable set of underlying packages is worth the tradeoff in convenience and performance.

As I've mentioned before: I'm afraid that's a problem for ROS to solve, not Homebrew. We make these options available to you regardless of whether you choose them. Sorry!

Re: Homebrew 1.0.0

#245

Post by mikemcquaid »

pikachu_is_cool wrote: post #198
mikemcquaid wrote: post #17

Earlier quoted context omitted.

Which is why for certain things like `brew --prefix` we now do it purely in Bash rather than using Ruby ;)

I guess it's a start. But even still, the most basic of commands take a good 1+ seconds on my machine. What about Ruby makes it necessary to use? What is stopping you guys from moving to something like LuaJIT?

Rewriting the entire project in non-Ruby would require a lot of time and create a lot of bugs for little benefit for most users.

Re: Homebrew 1.0.0

#246

Post by mikemcquaid »

mikeash wrote: post #220
sotojuan wrote: post #214

Earlier quoted context omitted.

I've found that a lot of people here in HN and Reddit are really passionate about not being tracked, so even if it was as easy as one command, the fact that Homebrew did it at all is enough to make some people not want to use it. Nothing wrong with that viewpoint, but I just disabled it and moved on to enjoying pretty good software.

It has nothing to do with how easy or hard it is to disable. The problem is that it doesn't ask first, or even tell you what it's doing. OK, now that I know about it, I can turn it off, but how do I know they won't do something similarly ugly in a future version?

We do tell you about it before we start recording any analytics.

Re: Homebrew 1.0.0

#247

Post by mikemcquaid »

gmisra wrote: post #166

If Mike is still here in the comments, can you talk a little bit about versioning support? Is this something that's on the roadmap at all, or something that Homebrew has a strong opinion about? In general, it's a very useful (and pleasant to use!) tool - except for when trying to manage different versions of the same dependency on the same system. Since this is such a big deviation from most package managers, and fee…

We're working on it: https://github.com/Homebrew/brew/issues/620

Re: Homebrew 1.0.0

#248

Post by bangonkeyboard »

mikemcquaid wrote: post #246
mikeash wrote: post #220

Earlier quoted context omitted.

It has nothing to do with how easy or hard it is to disable. The problem is that it doesn't ask first, or even tell you what it's doing. OK, now that I know about it, I can turn it off, but how do I know they won't do something similarly ugly in a future version?

We do tell you about it before we start recording any analytics.

You do now, after people noticed what you were doing. You didn't then, when the GA integration was originally snuck in.

Re: Homebrew 1.0.0

#249

Post by guitarbill »

xapata wrote: post #173
guitarbill wrote: post #154

Earlier quoted context omitted.

pip is atrocious/dangerous on any system without virtualenv. I've managed to sort this by using virtualenvs where I can and homebrew Python + packages when I can't (numpy, etc.). Two things really help: pipsi ( https://github.com/mitsuhiko/pipsi ), which installs tools inside their own virtualenv and PIP_REQUIRE_VIRTUALENV, which stops pip from working outside a virtualenv.

You could try conda. It's basically a pip and virtualenv that works on non-Python dependencies.

That's actually awesome, thanks!

Re: Homebrew 1.0.0

#250

Post by DeadBabyOrgasm »

mikemcquaid wrote: post #240
DeadBabyOrgasm wrote: post #222

Earlier quoted context omitted.

What about chromebrew [0] (homebrew for chrome os)? [0]: https://github.com/skycocker/chromebrew

It doesn't appear related so would be hard to merge.

Really? From a user standpoint it seemed very similar.

Either way, I'd definitely be interested in something like homebrew for ChromeOS. Guides for cross-platform capabilities would be most welcome!

Post reply on HN