Hacker News Reader

Comment by mikemcquaid | Hacker News Reader

We're unlikely to do that because end-users shouldn't care what language a tool is written in in order to install it.

I'm not talking about CLI tools. I'm talking about Python libraries, like Pandas and Numpy.

Homebrew is a package manager for macOS, not language libraries. I know there is a bottle for Numpy (and I'm sure other libraries as well) but I'd suggest not co-mingling your OS and Python package managers.

Homebrew really shouldn't ship libraries in the first place, for that we have our own language's package management (and for cases where we have difficult to install binary dependencies, we have our own language's mechanism for dealing with them).

Language package managers are for developers. End users should use their platform's package manager to install whatever libraries their application needs. E.g. Apt knows what version of numpy easypaint works with, while pip simply gives you the most recent.

I think most users should and would add python libraries with pip3.

Downside: numpy, h5py and others use an embedded libhdf5 which is quite outdated. Meanwhile, homebrew has the current version, but they ignore it. In contrast, the Debian/Ubuntu/FreeBSD ports have python packages built against the packaged libhdf5. The pip packaging is inferior to the properly packaged stuff, which is what you get when language-specific packaging exists in its own isolated bubble.

I feel like the correct move here is to push the library maintainers to update to the new version. Distribution package mods should really be seen as temporary.

I have already opened an issue for this. However, it doesn't resolve the underlying and rather harder to fix problem of different language-specific package managers embedding copies of C and C++ libraries which can end up in a horrible incompatible mess. It's not specific to pip/pypy, it also applies to Java jars with embedded libraries and other systems which also embed.

Sometimes, this embedded copy can be more up to date than the system copy, but the convenience of embedding is often outweighed by the binary compatibility problems and being neglected and out of date.

Is what `end-users should care about` any business of yours? I don't mean that insultingly, I mean genuinely.

I think renaming a bunch of packages with a prefix is probably silly, but your response also strikes me as incredibly prescriptive.

I like brew, but I don't like that attitude.

Given we're a tool that exists primarily to save time for our end-users I'd like it to be optimised so they don't need to care or think about things like what language a tool is written in to be able to install it.

> Is what `end-users should care about` any business of yours?

I only wish more software held a laser focus on what end users wanted, and thought about their needs as a top priority when evaluating proposals.

Brew is a really awesome piece of software to use, and it's that way because the authors are clearly constantly thinking about their users when they make decisions.

>Is what `end-users should care about` any business of yours?

Of course it’s his business! It’s his product and he gets to decide what he thinks people care about.

That’s like saying, “Why did Steve Jobs think it was his business to support mp3 and not OGG on the iPod?”

Reply on news.ycombinator.com