Mark packages pending until install/upgrade completes successfully - transactional operations

[DarwinCSIWindowscom]

It would be nice if Chocolatey had a transactional approach to whether a package is considered installed. Currently if I abort a package shortly after it starts - re running says it is installed.

I know I can use -Force to override - but it is a bit counter intuitive. I assume Chocolatey is using the existence of the package folder for "installed" and that this folder is created at the start of an install.

What if a tag file like InstallCompleted.txt was added to the package folder upon an error free completion?

This simple change would allow chocolatey to have a more "transactional" approach to "installed" marking without too much change or effort.

[ferventcoder]

I could almost swear you or someone already created an issue with this?

[ferventcoder]

But I don't see one, so perhaps it was on chocolatey/chocolatey then prior to chocolatey-archive/chocolatey#698

[ferventcoder]

Found it chocolatey-archive/chocolatey#608 (related but not the same)

[DarwinCSIWindowscom]

I don't think these are the same - I have that CTRL-C behavior as well. So after CTRL-C the powershell prompt where that occured asks if you would like to abort the current batch file y/n - it's exactly the prompt you get when breaking out of a .CMD or .BAT - but it won't go away - it pops up everytime you try another command in that console prompt - you have to close the prompt.

This request is broader => no matter how a package dies (in my case while I'm developing a chocolatey package and my code isn't solid yet and I get a PowerShell error), then the next attempt to install the package say it is already installed and requires either a -Force or a deinstall and reinstall. It seems like Chocolately should only mark a package as complete if it actually completed successfully.

Maybe it's already supposed to work that way but does not work properly when an actual powershell error occurs? I was assuming it uses the presence of the package folder as an "already installed" marker - which would explain this behavior - but definitely and assumption.

[ferventcoder]

Are you using 0.9.9+? This is mostly a curiosity. It should be erroring on posh errors where the older versions may have missed those errors.

[rismoney]

you are not wrong @ferventcoder - #188 I mentioned it 2 days ago...

[mlt]

I think it is not quite an enhancement but a bug. It requires to remember what package is being processed while hitting Ctrl+C to force update it later. Otherwise it leaves an old package installed and you never know when the new version would be available.

[ferventcoder]

@mlt If you do control+c, choco throws a huge warning at you not to do that. It should probably clean up though. Which is sort of what this is about.

[ferventcoder]

@DarwinJS

[timbrown5]

Not sure if this is covered, but just so it's clear I get this behaviour even if I Ctrl + C at the 'Do you want to run the script?' stage:
C:\Users\admin>choco list -l
chocolatey 0.9.9.11
1 packages installed.

C:\Users\admin>choco install orbis-tmserver
Installing the following packages:
orbis-tmserver
By installing you accept licenses for the packages.

orbis-tmserver v3.50.0.12
The package orbis-tmserver wants to run 'chocolateyInstall.ps1'.
Note: If you don't run this script, the installation will fail.
Note: To confirm automatically next time, use '-y' or consider setting
'allowGlobalConfirmation'. Run 'choco feature -h' for more details.
Do you want to run the script?

1. yes
2. no
3. print

C:\Users\admin>choco list -l
chocolatey 0.9.9.11
orbis-tmserver 3.50.0.12
2 packages installed.

At this point no install steps have been done, so it was a surprise to find this :).

[DarwinJS]

Whoops - timbrown5 posted while I was doing the below.

Rob - is this a happenstance that it works now? If not, could you explain the changes that address this?

************** Previous Post **********************

Personally I think the "installed" marker in Choco should be enhanced to use the presence of a file or registry key.

Perhaps a required attribute "existence" resource should be specified in the script or a custom NUSPEC attribute. Maybe that resource can have an optional version check. (uninstall keys and EXEs and DLLs have these)

Perhaps the "uninstall" reg key could be used and checked by default for "auto" support of this when something has not been specified?

A complicating / cool thing (depending on how you look at it) would be automatic indication that a package version is installed if it was installed independent of chocolatey.

[ferventcoder]

I think this can be easily handled by a marker, plus cleaning up any packages that have the presence of this marker.

[DarwinJS]

I agree and that approach benefits from not creating additional package requirements.

However, what I am suggesting takes steps toward making "chocolatey installed" and "OS/Setup.exe installed" represent the same factual data whenever possible.

When I first started using Chocolatey this was my defacto expectation because most software inventory relies on Windows to tell what is installed.

Another way to think of it is "if you compare the inventory of actual software on a computer via Windows" to "the inventory of a package manager managing some of the software", there should not be the opportunity for the package manager to claim something is installed or not installed in it's own data layer"

While it's possible to always try to keep another indicator in sync with the Windows indicators- it seems like a labor intensive and error prone future.

Passing through to Windows for this information (whenever possible) seems like a great way to avoid discrepancies.

This is more of a roadmap thought - not suggesting refactoring code in the near term.
D.

[ferventcoder]

I couldn't find this when #383 was logged (was looking for pending), so I updated that one. I think we will close that one as a dupe and update the title of this one.

[ferventcoder]

Another thing we need to check with this is if the nupkg file is corrupt when checking for existing installs.

If you have a shaky connection it may create the nupkg but it may not get the entire thing downloaded, causing it to corrupt itself. This is #717.

[ferventcoder]

@DarwinJS

[ferventcoder]

This is complete and will go out in the next beta after today.

[ferventcoder]

It will be available in 0.9.10.

[ferventcoder]

Related to #567.