[Bug] Chocolatey should not stop on error

[Redsandro]

When installing a batch of packages using the packages.conf XML trick, Chocolatey stops on a failing package, and skips the other packages.

You have to remove the finished packages from the XML, including the failed one, and try again. I think Chocolatey should just continue going, and mention the failed packages after everything is done. This way you can leave your computer unattended, knowing at least everything that doesn't fail will be installed once you get back.

Perhaps that last annoyance is what is talked about in issue #154, but I am not sure.

An idea is to have Chocolatey log all output and maybe error output separately, to a log file so you don't have to worry about error messages scrolling out of the viewable area of the command console.

(Filed as separate issue by request)

[ferventcoder]

Thanks for moving this over from #191

[Redsandro]

Today I found out Chocolately is actually called Chocolatey. Why did nobody stop me? :P
I edited the above issue to fix this.

[ferventcoder]

It's all good. Wasn't sure if you were misspelling or not.

[TomOne]

Is there any progress at this issue? It can be very annoying, for example when you do cup all and Chocolatey stops the complete process, even if only one package is broken.

[Redsandro]

@ferventcoder just a thought: Can all packages from cup all be rerouted through the new batch functionality? I see you also implemented this in cup when multiple packages are mentioned individually.

[ferventcoder]

not sure what you mean... new batch functionality...

[Redsandro]

Installing or updating multiple packages at once #304

[Redsandro]

Let me try that again. Personally I don't really care for packages.xml (AKA packages.conf) anymore, since we have batch functionality (e.g. cinst package1 package2 packageN). However, cup all also stops on error, and that one is important.

Finished installing 'ccleaner' and dependencies - if errors not shown in console, none detected. Check log for errors if unsure.
Chocolatey (v0.9.8.21-beta1) is installing 'chocolatey-beta1' and dependencies. By installing you accept the license for 'chocolatey-beta1' and each dependency you are installing.
Unable to find package 'chocolatey-beta1'.

Command 'update' failed (sometimes this indicates a partial failure). Additional info/packages: all
Reading environment variables from registry. Please wait... Done.
C:\Users\Redsandro>

The batch install does not stop on error, right? So can cup all somehow use the same don't-stop-on-error magic?

[TomOne]

This is actually a very important issue to solve. Stopping the entire process only because one package failed is very annoying and reduces UX.

[Redsandro]

I concur, but I lack the knowledge and the knowhow to propose a fix. :) I'm
better at making .bat wrappers. :P
On Nov 5, 2013 12:17 AM, "TomOne" notifications@github.com wrote:

This is actually a very important issue to solve. Stopping the entire
process only because one package failed is very annoying and reduces UX.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/192#issuecomment-27732812
.

[ferventcoder]

Also an issue we hope to resolve soon.

On Monday, November 4, 2013, Redsandro wrote:

I concur, but I lack the knowledge and the knowhow to propose a fix. :)
I'm
better at making .bat wrappers. :P
On Nov 5, 2013 12:17 AM, "TomOne" <notifications@github.com<javascript:_e({}, 'cvml', 'notifications@github.com');>>
wrote:

This is actually a very important issue to solve. Stopping the entire
process only because one package failed is very annoying and reduces UX.

—
Reply to this email directly or view it on GitHub<
https://github.com/chocolatey/chocolatey/issues/192#issuecomment-27732812>

.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/192#issuecomment-27736522
.

---

Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

[rismoney]

interesting... i would have thought people would like to fail early and abort... Personally I have a bunch of packages, and if a pre-req fails the success of post packages is usually botched as well. Otherwise why are they linked?

Personally I'd like to strive for idempotency to address @TomOne "annoying and reduces UX" issue. chocolatey should just "do the needful"...I hate when I get a box of chocolates (that rocks!) - ie when it doesn't stop on error...

Maybe if there are differing opinions there should be a silentlycontinue or similar switches via config file.

[mwrock]

Yeah. I think it really depends on the installation scenario. I can imagine lots of scenarios like yours where you would want it to fail on the first error. Maybe there is something wrong with the underlying environment (memory, storage space, etc.) or you are using chocolatey to deploy app components and one of the early packages is buggy. You are likely to see lots of failures and would prefer to have it simply stop so you can diagnose the root problem earlier.

My hunch is that the majority of users land on the other side (myself included) and want the installation to continue. I see alot of failures happen that are not related. Like one package's url is temporarily down or some other network glich. The full test package I use for boxstarter takes 1 to 4 hours to run depending on the OS and network conditions. It would be frustrating for it to stop 75% of the way in. As long as I have a log of what failed I'm good.

I think it would be important to have control over this with some kind of a SilentlyContinue or StopOnError switch.

[Redsandro]

i would have thought people would like to fail early and abort...

Typical use case: You have 20 hand-picked applications installed through Chocolatey. You care about these applications. You want to update them all: cup all

After 4 packages it breaks because the 5th package maintainer made a mistake. You now have 15 packages that are not updated. You have to remember them all, figure out their Chocolatey IDs, and specify each of them manually. This is a show stopper and is bad for business.

Now that package 5 cannot update because of some error, that does not mean you suddenly changed your mind about updating the rest of your system.

This together with the single-install-only limitation (fixed in #191 ) were my biggest annoyances with Chocolatey, and the stopping on error annoyance is the feedback I hear the most. (I install Chocolatey on other peoples laptops, and sometimes I even tell them how it works. ;)) (The other feedback is that packages often don't work, but that's a different problem.)

Sure, when a dependency no one (read: typical user) knows or cares about fails, the parent package should fail, obviously. But the rest of the independent packages are still supposed to be updated.

You are likely to see lots of failures and would prefer to have it simply stop so you can diagnose the root problem earlier.

I can imagine this too, but it's more of an advanced use-case. There should be a command line option for that.

"1.0" takeoff point:

• Do not stop on error. When client says he wants to update all, he wants to update all.

Ideally:

• Skip packages who's dependencies have errors, continue with the rest.

Advanced:

• Command line option for users who want specific behavior: cup --stop-on-error all

[rismoney]

I like determinism. I would need stop on error. The systems i manage are critical and must not leave things in barney.

[TomOne]

@Redsandro, I agree with you.

@rismoney, it’s OK if you want it to stop on error, but it should not be the default behaviour. I think Redsandro already explained the reasons clearly enough.

Another reason: packages are usually separate and independent objects (except dependencies). Why would you like to stop the entire process, only because a package failed to install, but has nothing to do with the other packages?

For comparison: A program on your computer has a small, but not serious bug that affects a certain functionality of that program. And only because of this bug you want that this program stops working completely and terminate with an error message? I think there’s only a minority of users who would want such a behaviour. It’s useful for debugging, but not for normal work. We can’t always have an everything or nothing philosophy. 😄

And by the way, nobody prevents you from stopping the process manually if you encounter an error.

[Redsandro]

I'd like to see Chocolatey introduced to the masses. I think Chocolatey is meant for the masses in the end. Meant for easy software management.

A famous developer once said about Chocolatey:

I want to see Windows be as automatable and awesome as other operating systems that are out there.

The Windows audience doesn't really mix well with something that breaks and spits out 20 red lines of error. It just wants to see a (final) message: "19 out of 20 packages updated. See error.log for details."

A single independent (in Linux we call this top-level) package should not rely on another top-level (TL) package, and neither should be the order in which they are installed or updated relevant. Hence it should not stop on error.

When one failing TL package leaves the system in barney for another TL package, said package is in conflict with both logic and the packaging guidelines, and should be hosted somewhere else:

A package creator should consider whether his package is also useful for others. If that is not the case, it shouldn’t be published on Chocolatey.org. Reasons for that can be if the package would require a very special configuration that is unacceptable for other users or that would lead to serious vulnerabilities.

[TomOne]

@Redsandro good arguments. 👍

@rismoney:

The systems i manage are critical and must not leave things in barney.

Nothing prevents you from investigating possible errors after the working packages have been installed/updated. This would also save time for you: If for example multiple packages you want to install/update are broken, with the current behaviour you will only notice the first error. Then you have to fix it, run cup all again, fix the next broken package, run cup all again, fix the next broken package and so on. This is not something I call comfortable. Therefore it reduces UX like I wrote before.

[Redsandro]

Let's strife for flawless UX and command line options for specifics. 😄

[ferventcoder]

Is this fixed in vCurrent?

[ferventcoder]

@rismoney oldie but a goodie. Now we have a ticket for ensuring full stop if there is a failure in the chain - chocolatey/choco#1151