Support "sudo -A" so that multiple large cask installs can be scripted

[mtougeron]

When using tools like https://github.com/pivotal-sprout/sprout-wrap or https://github.com/kitchenplan/kitchenplan a large number of casks are defined to be installed via a script. This installation can frequently take longer than the sudo timeout. This means that when homebrew-cask calls sudo (https://github.com/caskroom/homebrew-cask/blob/master/lib/cask/system_command.rb#L49) there is no prompt for the user to enter their password. The error given is "sudo: no tty present and no askpass program specified"

It would be nice if https://github.com/caskroom/homebrew-cask/blob/master/lib/cask/system_command.rb#L49 could also support using "sudo -A" so that the SUDO_ASKPASS environment variable can be used. An example script of this would be something like https://gist.github.com/mtougeron/8dc9cd42c1dd9bd566a3 This would allow the sudo authentication to be handled without user input.

Thanks, Mike

[nanoxd]

@rolandwalker Is there any issues with what you're working on if we switch over to this?

[mtougeron]

I should mention, that it'd need to check for the SUDO_ASKPASS environment variable being set before adding the -A option or you'll get an error "sudo: no askpass program specified, try setting SUDO_ASKPASS"

[rolandwalker]

Thanks for the suggestion, will review.

One workaround is to invoke brew cask or the parent script with sudo.

[mtougeron]

I believe the scripts are not using sudo when running brew cask install because of the casks that should not be installed as root.

Thanks for the quick replies!

[bcg62]

any updates with this? also having the same issue

[rolandwalker]

Thanks for the bump. My notes say I haven't looked into this yet.

[vitorgalvao]

Closing for lack of interest/implementation. This is not urgent and can be revisited at a later date. it concerns homebrew-cask being called by other tools and not homebrew-cask itself, but it should be revisited.

[chino]

Why not mark an issue with a non-critical tag instead of closing a valid concern?

I believe from the initial request all that needs to be done is adding -A to sudo so it can optionally use the $SUDO_ASKPASS env var.

[vitorgalvao]

Why not mark an issue with a non-critical tag instead of closing a valid concern?

Because more tags is not a solution. An over-abundance of issues makes it difficult to go through them and focusing. Having issues open indefinitely is a very poor outcome.

It’s not like issues are deleted. You were still able to find it, and if you really think it’s simple to do, you’re very welcome to submit a PR with a new discussion.

[bcg62]

But closing an unresolved issue is a solution?

Tags exist to make an over-abundance of issues less difficult to go through, focus can be spent on the important ones.

Yes, its not deleted but its less relevant and accessible. Someone may have the same experience and odds are they're not searching though closed issues.

[vitorgalvao]

Keep in mind I tend to be somewhat blunt when writing something so long, and that can make my tone seem confrontational. Nothing could be farther from the truth: this is meant as an explanation, not a defence.

The message is clear. The door is not closed on this issue, and it is very clear it can be revisited at a later date.

Someone may have the same experience and odds are they're not searching though closed issues.

Good. If an issue was closed due to lack of interest and someone opens a new one, it means there’s interest again, and we can form a new issue (backed up by the knowledge of the old one) to try again to tackle it.

Tags exist to make an over-abundance of issues less difficult to go through, focus can be spent on the important ones.

With all due respect¹, you’re not managing the project. I don’t mean this in a “your opinion is irrelevant” way (because it is relevant, just like any other user’s or maintainer’s) but in a “you haven’t experienced how bad it is”. Your solution is all well and good in theory; in practice, that is not what happens. You know why are close to all new issues labeled? Because one day, while managing the open ones I noticed how unbearable it had become and personally spent a stupid amount of hours going through all open issues, reading most in their entirety, and making decisions on labels and open status. We’re now keeping issues well labeled and even document how, but it has not always been like that.

Furthermore, many people don’t decide “let me work on this tag” and only pick that one, they look at every issue and decide what to work on based on the labels it has. In other words, the filtering is done visually after picking an issue, not the reverse.

No, we will not keep decrepit issues no one cares about or wants to work on and have minimal dubious benefit, open indefinitely. Their overhead is not worth it, and once again they can be revisited at a later time. This project was close to stagnation, you just couldn’t tell from the outside because casks were still being merged. Among the many other changes, organising issues is helping us move forward again, and that includes closing unimportant ones.

To put it bluntly, you can theorise all you want about the effectiveness and use of labels, I’ve experienced first hand what this specific project needs at this specific time. Right now, this is it.

---

¹ I’d been wanting to use that, for a while. I just find the scene funny, I mean nothing more by it.

[chino]

This affects ability to use it from tools like chef/puppet to manage workstations which is a big use case.

[vitorgalvao]

This affects ability to use it from tools like chef/puppet to manage workstations which is a big use case.

Irrelevant if no one works on it or shows interest in working on it. It is also absolutely irrelevant for the functioning of homebrew-cask itself, and we have big core functionality issues that need addressing. If the core tool itself has deficiencies, fixing those takes precedence above making it play nicely with other tools. Why wouldn’t it?

Unless, of course, we get a PR. So please either submit one or lets end the conversation here. We’re all volunteers, and you do not get to pick how volunteers spend their time. For the last time, this feature is non-critical, of low importance, and if no one works on it until then we can revisit it in the future.

[adidalal]

Even though this is an old issue, FYI @mattbell87 posted a possible solution in #19180 (comment)