brewdo support?

[alexreg]

Thanks for creating this great little app.

Any chance of adding brewdo support? It would basically just mean being aware of the need to elevate to the _homebrew user and running brewdo instead of brew.

[zkokaja]

Hi, thanks for the suggestion! I'll take a look and see if I can include it in the next release. Can you elaborate on what needs to be done to evaluate the _homebrew user? Switching the commands would be pretty simple.

[alexreg]

Glad to hear!

So basically, the way brewdo is typically used manually is that instead of running brew in your shell, you run brewdo brew. The following arguments just get passed to an elevated instance of brew (running as user _homebrew, group _homebrew, basically). I just alias brewdo brew to brew in my shell configuration, and I recommend other users do the same.

My recommendation is that in the code, wherever you run brew, you simply run brewdo and pass brew as the first argument (all the other arguments the same). Sound reasonable to you too?

[zkokaja]

We can now test the custom path functionality introduced in version 1.5 to support this use case.

[alexreg]

Hmm, maybe I'm missing something obvious, but how does custom path functionality help? This is just about the process user as far as I'm aware (and executing brewdo ... in place of brew ...).

[zkokaja]

The custom path includes the command itself, so you can set it to something like /usr/local/bin/brewdo brew in Preferences. This is where it would end up being set here https://github.com/zkokaja/Brewlet/blob/master/Brewlet/AppDelegate.swift#L506. I'm not positive if it will work because we may need to separate brewdo and brew into elements in the args list. I'll give it a shot this weekend.

[alexreg]

Oh, of course. I wasn't thinking straight. I've tested it for a day now and it seems to be working well. Thank you!

Incidentally, does Brewlet check for outdated packages every when opening the drop-down menu from the system tray? Just curious.

[alexreg]

Maybe it's not working actually. It seems to crash a few seconds after launching now!

[zkokaja]

Oh no! Sorry to hear that. Are you able to see any logs in the Console app to give us some clues? You may also be able to manually revert the brewPath change by editing ~/Library/Preferences/zzada.BrewLet.plist.

Incidentally, does Brewlet check for outdated packages every when opening the drop-down menu from the system tray? Just curious.

No it doesn't. It only checks when the interval timer goes off, and any manual clicks on the Update to force it (in case you don't want to wait).

[alexreg]

Nothing in the Console app. I just tried it again, and funnily enough, it seems to be working. At least, it's been "Updating..." for several minutes. (This is one of the reasons it would be nice to have finer-grained notifications like I mentioned in the other thread.)

No it doesn't. It only checks when the interval timer goes off, and any manual clicks on the Update to force it (in case you don't want to wait).

Thanks for clarifying. What about separate "update" and "upgrade" buttons then, to match the CLI commands?

[alexreg]

(Or maybe not. It was stuck on "Updating..." for well over an hour.)

[zkokaja]

That's true, sometimes the brew upgrade command can take a while to run, especially if it needs to compile anything; (agreed, #17 makes sense in this case) . There is a log file that all stdout goes to, it's a temporary file that is given by the macOS API, this could be useful to debug your situation for now. There are instructions on how to find it in the README. I am also considering making it an absolute path in ~/Library/Logs/ instead of a temporary file.

The update and upgrade buttons are separate, but it depends on the current state. If there are outdated packages, then the button changes to upgrade:

If there are no packages to upgrade, then it will change to update:

I found this strategy to be simpler and more streamlined than having both buttons.

[alexreg]

Ah, that UX makes a lot of sense. Thanks for explaining.

Unfortunately, no Brewlet log is being created (~/Library/Logs/Brewlet to be specific, I suppose?) The app is stuck on "Checking..." and "Updating..." indefinitely, upon launching it.

[zkokaja]

Sorry I completely missed this! If this is still unresolved by the weekend, I'll dedicate time to dive into the issue. In the meantime, you can find the log file as described in the README by running this command: find /var/folders -type f -name 'brewlet*log' 2> /dev/null since that's where the temporary files are created.

[alexreg]

Okay, thanks. No results for any log files, I'm afraid.

[zkokaja]

I tried installing brewdo, I get this error on brewdo install:

Traceback (most recent call last):
	2: from ./brewdo:30:in `<main>'
	1: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require': cannot load such file -- colorize (LoadError)

[alexreg]

Hmm, which macOS are you on?

[zkokaja]

Big Sur. It is a fresh macOS VM but I installed command line tools etc.

[alexreg]

Ah yes, colorize is no longer bundled. I need to update the Makefile. For now just do sudo gem install colorize or something.

[zkokaja]

Ah, I have no experience with Ruby but that worked. Unfortunately I run into another problem installing it:

% sudo ./brewdo install
Traceback (most recent call last):
	4: from ./brewdo:441:in `<main>'
	3: from ./brewdo:325:in `cmd_install'
	2: from ./brewdo:303:in `cmd_mkdirs'
	1: from ./brewdo:208:in `create_homebrew_home'
./brewdo:208:in `chown': Operation not permitted @ apply2files - /usr/local (Errno::EPERM)

I tried multiple ways to try to run chown on /usr/local but there's some ACL/SIP permissions I'm not familiar with (this link helped a bit). I can't do it on the command line either, and I get permission errors if I try something like sudo mv /usr/local /usr/local-old.

If I comment out line 208 I get another error than the directory already exists:

% sudo ./brewdo install
Homebrew owner account exists. Abort (A), ignore (i), or recreate (r)? i
500/usr/localfatal: destination path '/usr/local' already exists and is not an empty directory.
Traceback (most recent call last):
	2: from ./brewdo:443:in `<main>'
	1: from ./brewdo:328:in `cmd_install'
./brewdo:317:in `cmd_clone': Homebrew clone failed (GitCloneError)

This maybe due to the _homebrew user not owning the directory though.

In the next update to Brewlet, I'll include an easier way to access logs so we can see what's happening exactly.

[alexreg]

Okay, this is a bug. Thanks for drawing it to my attention. I'll try to fix it later today. (Are you installing off the master branch, incidentally?)

[zkokaja]

Yea I did install off of your master branch.

By the way, commit 9eae3c9 now logs to ~/Library/Logs/Brewlet/; but you'll have to build the app locally until I release a new version.

[alexreg]

Hi @zkokaja. I just looked into this again, but it seems like no logs are being created... any thoughts?