> Unpredictable command times. I never know if running brew install or brew upgrade is going to take 5 seconds or 20 minutes. This usually means knowing if a program or dependency is being downloaded as a prebuilt binary or compiled on the spot.
Wait, does Nix solve this? And how? The author never mentions how Nix does.
I've never encountered a package manager with this capability, so just curious how such a "global progress bar" even gets implemented.
When I issue a `brew install package` command, I expect it to either install the package or fail installing the package, and not do something else entirely. Sometimes I need to do something quick, nix-shell has never given me any issues with that. Brew has taken 10 minutes before getting to the install process. It's severely annoying.
It wants to update a few times a day by default when you call it, so running a simple brew install anything normally takes about 30 seconds (I'm in a MB Pro), even if it's just to say the package you want wasn't found.
If you don't run it daily, it takes about a minute or two to update.
But even when it doesn't update, it is extremely slow compared to any other package managers. It is disruptively slow and it takes a lot of resources, even in a powerful machine (and I'm not talking about compilation here).
The slowness is mostly due to Ruby and the git pull. I contributed in the past and reimplemented it in bash, and there isn't much going on, honestly.
99% of the time, installing a package consists of downloading a few zips from their CDN, decompressing and linking. For those cases Brew could just be checking an API instead of constantly cloning the git repository.
I'm quite surprised nobody has reimplemented it in Rust or Go. The architecture is quite simple compared to a normal package manager. Maybe it's just superstition: people see "package manager" and assume it's complicated instead of digging into the code and finding out how it works.
I wasn't trying to be deceptive. I quoted silently to not be deceptive.
I was being liberal in the meaning, not intent -- silently there meant "you do not know whether `brew install foo`" will take 2 seconds or 2 minutes when you run it, and yes I think that's poor UX.
Do you have a package being built from source instead of bottle?
Brew upgrade takes less than ten minutes or so for me. Things that influence this will be the amount and size of your installed packages and whether they have prebuilt binaries ("bottles") or if you need to build them from source. The latter is on your package maintainers.
> To do otherwise is to suffer a whole day trying to install ImageMagick
Sure, you could do that, or issue [pkg-manager] install imagemagick. It took me yesterday around 15 seconds to install imagemagick without even leaving iTerm. Even brew knows that.
It makes sense semantically to me, and would be fine/preferable if `brew update` only took a few seconds to complete.
Cause otherwise I'm not necessarily going to remember to brew update ever, and am going to be getting old formulae. I think I'm not alone, I suspect this was done because too many users were never updating.
I am not super familair with how apt works, but I think the "workflows" of brew are already different than typical apt uses, with continuous incremental releases, and users expected to stay up to date with them -- things aren't necessarily going to keep working (installing properly) if you never run `brew update`, and I think many users were not.
I do want `brew install` to get me the latest formula for the thing I'm installing.
The problem is when it can add several minutes to a `brew install` invocation, interupting my ability to get on with my business.
But good to know about the env variable so at least I can choose which tradeoff I want!
Homebrew now runs `brew update` before every `brew install`, no? That's how it gets in the way, you just wanted to install a thing, and now you are stuck waiting for `brew update` -- which I feel takes longer than it used to?
(You also may be confused between `brew update` and `brew upgrade`. I know I often am!)
apt-get update just took 15s on my Debian to finish. The thing is, I actually never run apt-get update, I just have a cron job which runs it before installing security upgrades.
Ideally homebrew would be faster, but in the meantime you could run updates in the background regularly enough so that you never have to do it while running a brew command interactively (if you use the parameter that has been suggested).
Would it, though? Almost all the time during installation is spent downloading and extracting the tarballs and running compilers if necessary. Even updating Brew itself is almost all git.
Wait, does Nix solve this? And how? The author never mentions how Nix does.
I've never encountered a package manager with this capability, so just curious how such a "global progress bar" even gets implemented.
reply