Support 'login-items' as a first-class citizen of the CLI

[vraravam]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

1. First cut of moving login_item from under the uninstall block to the top-level
2. Fix issues found when running brew update and brew upgrade
3. Incorporate login_items into info command output (not yet verified)
4. added login_items option for reinstall command

[vraravam]

Could someone please help? I am not sure if I am going in the right direction or not. Would love to get some feedback. This PR is trying to solve the #19333 ticket.

[MikeMcQuaid]

@vraravam Looks good so far! Anything specific you need help with?

[vraravam]

@vraravam Looks good so far! Anything specific you need help with?

Thanks @MikeMcQuaid - I am first trying to cover all scenarios/commands from the CLI perspective, and finally will proceed to the actual implementation of the osascript calls. Hope that's fine with you?

Also, I'm trying to ensure that all code that I write have tests - if I miss something (since this is my first time contributing to this codebase, i don't know the contributing guidelines/rules), please do point me in that direction as well.

Based on the CLI commands, do you recon that I am missing any? I have tried with install, reinstall and uninstall.

[MikeMcQuaid]

@vraravam Sounds good to me! When CI is 🟢 let us know and we can give this a more thorough review. CC @homebrew/cask folks for any thoughts before that, too.

[bevanjkay]

I think the dsl here should be login_item, and repeated if there are multiple.
This will keep it consistent with the other artifacts, that aren't pluralised.

[vraravam]

do you mean like how multiple language blocks are supported in the DSL?

[bevanjkay]

I'm referring to other artifacts such as app, binary, artifact, font, qlplugin, etc..

[vraravam]

If we look at the everything.rb DSL, there are other stanzas that are pluralized as well maybe?

[bevanjkay]

All of the artifact stanzas (which I think a login item will most closely relate to) are not pluralised.

suite
app
pkg
installer
binary
manpage
colorpicker
dictionary
font
input_method
internet_plugin
keyboard_layout
prefpane
qlplugin
mdimporter
screen_saver
service
audio_unit_plugin
vst_plugin
vst3_plugin

For context, where multiple items doc the same type are allowed and provided the stanza is repeated rather than passing an array to the stanza.

[bevanjkay]

I have a concern that there may be side effects of skipping the uninstallation of login_items.
I understand having the option to automatically register a login_item, but is the idea here to be able to skip uninstalling them? The reason we generally aim to remove as much as possible with brew uninstall (which also runs with brew upgrade) is to not leave things behind that aren't connected to the application anymore.

What happens if the login_item changes between versions?

[vraravam]

Agree - I was also facing the same conundrum. This is predominantly for the usecase where the user has chosen to not uninstall by using --no-login-items CLI switch. By default, the registered login items will be uninstalled (I think that's how I have coded it?)

[SMillerDev]

Two things I'm worried about here:

• how will this work on Linux
• more importantly: how can maintainers know the values are correct? The uninstall blocks are tested by CI, but how will this be tested?

[vraravam]

* how will this work on Linux

For now, I'm only thinking of supporting macos. If needed, and if someone else can take up the work for linux, we can collaborate (I don't have a linux box to test this on)

* more importantly: how can maintainers know the values are correct? The uninstall blocks are tested by CI, but how will this be tested?

That's the reason the onus on correctness is envisioned to be with the cask's author and not at the framework/tool maintainer. This is similar to how the uninstall stanza's login-items is currently implemented.

[bevanjkay]

That's the reason the onus on correctness is envisioned to be with the cask's author and not at the framework/tool maintainer. This is similar to how the uninstall stanza's login-items is currently implemented.

If we systematically add a login_item that is incorrect, does that result in a broken login item being added to the system?

[vraravam]

If we systematically add a login_item that is incorrect, does that result in a broken login item being added to the system?

My assumption is the osascript will return an error code / message if an incorrect login item is tried to be added.

[SMillerDev]

That's the reason the onus on correctness is envisioned to be with the cask's author and not at the framework/tool maintainer.

Not sure who the tool maintainer is in this case, but the most common scenario for casks is:

• someone finds a cool new tool
• makes a pull request to add a cask
• PR gets merged
• author is never seen again
• others, mostly maintainers, fix the cask on updates. Often after users report it broken.

So you can see why I'd want to ensure the CI catches faulty entries here like it does for the uninstall step.

[vraravam]

i see your point @SMillerDev . I am only banking on the precedent scenario of how the uninstall handles this scenario. If you have any other suggestions, I'm all ears.

[vraravam]

Would love some help in debugging the broken tests. can someone please point me in the general direction of what's wrong?