new pin option for "present"

[rismoney]

Checklist

• [X] I have verified this is the correct repository for opening this issue.
• [X] I have verified no other issues exist related to my request.

Is Your Feature Request Related To A Problem? Please describe.

choco pin allows you to suppress upgrades which is fantastic! I would like to change an installed package version from 1.2.3.4 -> 'present' or 'unmanaged' and not have it represented by a version number.

Describe The Solution. Why is it needed?

Sometimes packages are installed on a system 1x, as sort of a stem cell implementation, and become self updating packages. The choco package no longer properly identifies with the package installed, and in some of these edge cases, it's fine - we don't care what package is installed anymore, just that it is installed.

I would like to be able to simply change a package to 'present' and effectively not report a stale package but leave it dormant. From a choco upgrade, I think it would skip these (as handled by pinning) From a choco upgrade force, maybe it would update them? I am open to behaviorial changes, and not sure I care. I just think reporting them as a stale version is a poor experience, that can be corrected with user intervention.

Additional Context

In these edge cases, I am not concerned about getting the real version by means of ARP, regkey or other inspection methods. Just clarifying what choco list knows, and REALLY knows

It's almost like an additional metadata piece to C:\programdata\chocolatey\lib\package.ver to signal it is obsolete.

Related Issues

No response

[TheCakeIsNaOH]

and become self updating packages.

Can you describe what you mean here in more detail? Do you mean the software self updates but does not change the package?

[gep13]

:wave: @rismoney

I "think" I understand what you are getting at, but let me see if I have it right, by way of an example....

Let's say that you installed the vscode package at version 1.74.0. When you run choco list -l you will see the following output:

PS C:\> choco list -l
Chocolatey v1.2.1 Business

chocolatey 1.2.1
chocolatey.extension 5.0.1
vscode 1.74.0
vscode.install 1.74.0
4 packages installed.

However, due to the fact that VSCode is an automatically updating application, if I go in and look at the properties of the application, I will see the following:

So, what I think you are getting at is that there is a mismatch between the package version (1.74.0) and the installed application version (1.74.2). Do I have that right?

Assuming that is the case, I will continue, otherwise we can discuss in later replies :smile:

Now, if you are "OK" with this application automatically updating itself, as you mentioned, you can pin that package, so that Chocolatey will no longer do anything with that package during an upgrade all operation.

PS C:\> choco pin list
Chocolatey v1.2.1 Business

vscode|1.74.0|
vscode.install|1.74.0|

You can also see this in action when you run the choco outdated command:

PS C:\> choco outdated
Chocolatey v1.2.1 Business

Outdated Packages
 Output is package name | current version | available version | pinned?

vscode|1.74.0|1.74.3|true
vscode.install|1.74.0|1.74.3|true

Chocolatey has determined 2 package(s) are outdated.

As you mentioned, this is useful, as Chocolatey effectively ignores these packages. You can take this command further by passing in the --ignore-pinned option, i.e:

PS C:\> choco outdated --ignore-pinned
Chocolatey v1.2.1 Business
Outdated Packages
 Output is package name | current version | available version | pinned?


Chocolatey has determined 0 package(s) are outdated.

So, now to the actual question that you asked....

The first thing that I will say, and I know that you know this, it is just worth repeating here, Chocolatey is a Package Manager, it manages packages. The fact that the underlying Application is being updated outwith the Package is the actual issue here. This is something that the Automatic Sync feature in the commercial editions of Chocolatey attempts to resolve.

Where I think we can help here is providing additional information in the output from choco list -l similar to what you see in choco outdated, where information about the package being pinned or not is presented, and from there, it can be inferred that an application is present by virtue of the package being installed, but that the version number isn't guaranteed to be valid. So the potential output would be similar to the following:

PS C:\> choco list -l
Chocolatey v1.2.1 Business

chocolatey 1.2.1|false
chocolatey.extension 5.0.1|false
vscode 1.74.0|true
vscode.install 1.74.0|true
4 packages installed.

Would that cover what is being asked for here?

[rismoney]

Yes. You nailed it exactly.

The output example you provided isn't super coherent either. I guess from a clarity perspective it would be slightly better |pinned |unpinned.

I worry that choco list -l modification output would potentially mess with tools that parse the output. https://github.com/puppetlabs/puppetlabs-chocolatey/blob/main/lib/puppet/provider/package/chocolatey.rb#L271-L303

Originally I was hoping to somehow migrate an installed package to a 0.0.0 version by way of a near identical feature of pinning. Not really sure as I have been brainstorming it a bit more.

If this isn't a solvable thing in a sane manner, I could powershell hack something for my use case. Wanted to put it out here, to see if anyone else thought of something interesting on it.

While the vscode thing is a good example, and highlights probably poor practice in an enterprise of updating outside of choco, my use case was for internal developed apps, that are zip files, but self update themselves after an initial deploy, and never need to be choco upgraded. Theoretically there would be no sane way for choco 'learn' about the new version in this scenario without some sort of .exe inspection watcher process (which is an interesting idea actually)

[rismoney]

Ok, so a year passed. Do you think putting the pinning state behind a choco list is doable ?