Removal of "localonly" parameter in v2.0 has broken many machine setup scripts

[tfabris]

Checklist

• I have verified this is the correct repository for opening this issue.
• I have verified no other issues exist related to my problem.
• I have verified this is not an issue for a specific package.
• I have verified this issue is not security related.

What You Are Seeing?

Chocolatey v2.0 removed the parameter "list --localonly" which is the way that many of my machine setups scripts detected whether a certain package was installed or not.

This removal has caused race conditions in my machine setups, starting today. I am including example code in the "how did you get this to happen" section.

What is Expected?

Expected: The "--localonly" command should still work, preventing race conditions in existing setup scripts.

How Did You Get This To Happen?

Example powershell code:

# Ensure we are running the latest chocolatey
& choco upgrade chocolatey -y

# Start with this value set to false and it will change to true later if needed.
$rebootNeeded = $false

# Check for Chocolatey packages which will need a reboot if installing for the first time.
Write-Host "Scanning for an existing installation of javaruntime"
$scanInstallOutput = $null

# ERROR IS HERE:
# This command produces no output because its new output says "Invalid
# argument --localonly. This argument has been removed from the list command
# and cannot be used."
$scanInstallOutput =  choco list --localonly | Select-String "javaruntime"

if (-not $scanInstallOutput)
{
    Write-Host "A reboot will be needed during this script because javaruntime will be installed for the first time."
    $rebootNeeded = $true
}
else
{
    Write-Host "Existing installation found: $($scanInstallOutput)"
}


# Install or upgrade the package. Note: Package may be already installed, even
# if the code above thinks it is not.
& choco upgrade javaruntime -y


# Reboot if needed
if ($rebootNeeded)
{
    Write-Host 'Reboot is needed due to installation requirements. Restarting...'
    $wait = 30
    Write-Host "Rebooting in $wait seconds..."
    
    Write-Host "-----------------------------------------------------------------"
    Write-Host "$((Get-Date).ToString()) - $($env:computername) - Rebooting"
    Write-Host "-----------------------------------------------------------------"

    Start-Sleep -Seconds $wait
    Restart-Computer -Force
}

The code above puts the machine into an infinite reboot loop, when it used to work fine before the 2.0 version of Chocolatey.

System Details

• Operating System: Windows Server 2016
• Windows PowerShell version: 4.6
• Chocolatey CLI Version: 2.0
• Chocolatey Licensed Extension version: 2.0
• Chocolatey License type: Unknown
• Terminal/Emulator: N/A

Installed Packages

Chocolatey v2.0.0

Output Log

choco list --localonly
Chocolatey v2.0.0
Invalid argument --localonly. This argument has been removed from the list command and cannot be used.

Additional Context

No response

[tfabris]

By the way, your documentation here still mentions "localonly", like this:
https://docs.chocolatey.org/en-us/choco/commands/list

 -i, --includeprograms, --include-programs
     IncludePrograms - Used in conjunction with LocalOnly, filters out apps 
       chocolatey has listed as packages and includes those in the list. 
       Defaults to false.

What is the alternative to "--localonly" now? How do we list programs which are installed on the system?

[tfabris]

Here is another code example which fails due to this change to the "localonly" parameter:

  LogStart "Configure SQL Server."
  $PackageName = "sql-server-express"
  Write-Host
  Write-Host "Checking for prior Chocolatey installation of $packageName"
  $result = $( choco list -lo | Where-object { $_.ToLower().StartsWith($packageName.ToLower()) } )
  if($result -ne $null)
  {
    # DEVOPS-2243 - Work around SQL installation probblem without needing to install SQL
    # during machine bootup. This faster script "fixes" the existing SQL installation that
    # was installed during Packer build image creation. This script was originally a
    # Microsoft utility, later preserved at https://gist.github.com/wadewegner/1677788.
    # This script takes the current logged-in user (expecting it to be "adminuser") and
    # adds that person to the SQL administrators. This allows our DatabaseBootstrap.exe
    # program to work without encountering the error message "CREATE DATABASE permission
    # denied in database 'master'."
    Write-Host "$packageName is already installed by Chocolatey."
    Write-Host "-----------------------------------------------------------------"
    Write-Host "$((Get-Date).ToString()) - $($env:computername) - $($env:username)"
    Write-Host "Adding current user $($env:username) to SQL express as admin."
    Write-Host "Start-Process -FilePath `"C:\Windows\System32\cmd.exe`" -ArgumentList `"/c`",`"c:\scripts\addselftosqlsysadmin.cmd`" -Verb RunAs -Wait"
                Start-Process -FilePath "C:\Windows\System32\cmd.exe" -ArgumentList "/c","c:\scripts\addselftosqlsysadmin.cmd" -Verb RunAs -Wait
    Write-Host "$((Get-Date).ToString()) - $($env:computername) - $($env:username)"
    Write-Host "Done adding current user $($env:username) to SQL express."
    Write-Host "-----------------------------------------------------------------"
  }

[pauby]

Please see the upgrade guide for information around the changes to the choco list command.

Chocolatey v2.0 removed the parameter "list --localonly" which is the way that many of my machine setups scripts detected whether a certain package was installed or not.

I would suggest you use choco list --limit-output for machine readable output.

[tfabris]

I have found another command which broke due to this same set of changes, this also causes problems in automation scripts. These scripts look for a package in a private source repository of artifacts:

choco list -s Artifacts --pre -a MyPackage
Chocolatey v2.0.0
Invalid argument -a. This argument has been removed from the list command and cannot be used.

[pauby]

As indicated by the upgrade guide the list command only lists locally installed packages. -a lists all versions of a package and as you can only have one version of a package installed locally, it does not make sense for it to be an option for the list command. I will, however be explicit in the upgrade guide to call that out. Thanks for pointing it out.

The command choco list -s Artifacts --pre -a MyPackage should now look like choco search -s Artifacts --pre -a MyPackage. The search command is used to search remote sources.

[tfabris]

Here is something interesting that this change has caused. Originally I had a script that updated itself as a chocolatey package. It used "choco list MyPackage" to find which version of that package was on the server. Then it tried to update itself if a new version was on the server.

Now "choco list MyPackage" only lists the local package, so it always thinks it has the same version, and it never upgrades itself.

The only way to get it to change on the various machines (which run the script at bootup) is for the scripts to think a new version is available. It has just now become a chicken-and-egg problem where the scripts can't ever get the new version (with the chocolatey parameter corrections) because they can never see whether there is a new version available.

This is a seriously bad change to the command line parameters. The differences between local and remote package queries just flipped on us, and now the scripts are all chicken-and-egged.

[pauby]

Now "choco list MyPackage" only lists the local package

Change that to choco search MyPackage instead.

This has been deprecated since version 1.0 (released on March 21 2022) alongside other items. Every time that choco list has been run since that time, a message similar to this has been shown in the output:

And this message would be added to the logs

Being direct, what more would you want us to do? We have deprecated it over a year ago and added a message to the screen and the logs every time the choco list command was run. We have released a major version of Chocolatey CLI that includes breaking changes. We must have a process to make breaking changes that allow us to move the products forward, and we only do that in a major release after deprecating the issue in a previous release.

It is not good practice to upgrade any software to the latest version automatically. Particularly major versions. Breaking changes are going to hit you at some point. You should only use known working versions of software and when new versions are released, test them and upgrade to them in a managed way. If you do not do that, you will have a bad time at some point.

The solution to your issue is to downgrade to version 1.4.0 and not to upgrade to the latest version. This will resolve your issue now, and then when you have made changes and are ready to upgrade to a major release, you can do so in a managed way.

I have raised two PR's to amend the help text that you identified and update the documentation for the -a option.

[tfabris]

Regarding those deprecation messages: We don't see them when chocolatey is run inside a script. The scripts blithely cruise along and do their job until one day they break catastrophically.

Regarding what you could do: Since this is already a done deal, there's nothing you can do, it seems. However, in the future, consider the karmic ramifications before introducing breaking changes to command line parameters. By that I mean: Because of the amount of manual labor this is causing me, I'm seriously considering quitting my job today.

Alternatively, I suppose, you could have done same thing that they did when they broke Nunit's command line parameters in version 3.0, and actually change the product name and the executable name from "nunit" to "nunit3" so that the old version still worked for everyone. That was a much smoother transition.

[pauby]

@tfabris I'm not sure I have anything to add beyond what I've said above. I will answer your questions in the last comment.

Regarding those deprecation messages: We don't see them when chocolatey is run inside a script. The scripts blithely cruise along and do their job until one day they break catastrophically.

The messages are also added to the logs. If you don't read those, then I don't think we could have got that information to whatever we would have done.

Regarding what you could do: Since this is already a done deal, there's nothing you can do, it seems. However, in the future, consider the karmic ramifications before introducing breaking changes to command line parameters.

As I mentioned above, we did that and added deprecations in March 2022 and removed them, in a major release. That's when we can break things, only in a major release. My advice remains the same in this area, don't automatically upgrade to the latest version for any software.

By that I mean: Because of the amount of manual labor this is causing me, I'm seriously considering quitting my job today.

I'm sorry that you're having a bad time. As somebody who has worked in IT for 32 years now, primarily in an Operations / Infrastructure role, I understand the stress of everything going wrong at the one time. You do have my genuine sympathy.

Alternatively, I suppose, you could have done same thing that they did when they broke Nunit's command line parameters in version 3.0, and actually change the product name and the executable name from "nunit" to "nunit3" so that the old version still worked for everyone. That was a much smoother transition.

This would result in everybody who wanted to use the new Chocolatey CLI 2.0.0 release having to update their scripts to use the new choco2.exe (had we called it that).

My suggestion for you remains downgrading to 1.4.0 and pinning to that version until you have the opportunity to amend your scripts. I agree that's not ideal, but it is the only option I can see that would help just now.

I am going to go ahead and close this issue now, as I don't feel there is anything more for us to do. If I'm wrong, please let me know and we can always reopen it again.

[tfabris]

@pauby - Thanks so much for responding in detail. Indeed, we're pinning at 1.4.0 for now.