[Enhancement] "Runnable" packages that are not installed

[andulv]

This feature has been implemented in my fork of Chocolatey here:
https://github.com/andulv/chocolatey/tree/run-package

I suggest this as a feature in the new upcoming C# rewrite of Chocolatey.

Feature description

'run Packages' are packages that are not "installed", effectively turning them into script-packages. The packages are not installed to lib\ folder, but in every other aspects they are identical to ordinary packages.

When a package has the extension '.run' this happens upon install:

The package is downloaded to lib-run
tools\chocolateyinstall.ps1 script is executed
Package is removed from lib-run

This is useful for scripts that do not install anything, where the concept of uninstalling does not make sense and the script should therefore not appear in Chocolateys list of installed packages.

This also allows for running a script multiple times, without uninstalling and reinstalling the package.

Our use case

We develop and support a POS application for a chain of independent retail stores. The application consists of a server part and a local installation at each store's POS computers. (POS=Point Of Sale).

In addition to supporting our own application we also have a contract for maintenance, support, etc. of the POS computers.

We are in the process of setting up our own Chocolatey repository. The intendended usage is:

• Hosting setup packages for our own software (which is quite frequently updated)
• Hosting setup packages for a small selection of other software that we support and keep updated for the clients (Acrobat Reader, TeamViewer, Microsoft Office, Java runtime, etc.)
• Hosting scripts that we want to be able to run at client computers.

We are also in the process of setting up a client / server solution that gives us a permanent two-way connection between the central server and the clients (using SignalR). An important feature in this solution is the ability to have a "command console" from the server to the clients. This allows for server operators to issue commands which are executed silently at client computer(s) and the commands output is sent back to the server.

A bonus effect of using this in combination with Chcolatey is that we get an easy way to do software inventory. By issuing 'Choco list -lo' from the central server we will get a list of all applications installed at a specific client computer (or all computers or a subset of them).

We also have various scripts / utilities that we occasionally need to run at client computers:

• Defrag local database(s), Clean up temp folders, Shrink/archive log files, etc.
• Various maintenance/upgrades (change computer name, prepare computer for change of storeowner, run SQL to patch error in database, etc.). These might be run 0..n times in the liftetime of a client computer.
• System info type scripts: List available diskspace, List scheduled tasks, Collect SMART info, etc.
• Temporary workarounds for known bugs / problems in applications we support. (e.g. sometimes a customer-display will hang. A permanent fix for this will be part of our next application release. But in the meantime we have made a simple script that we can run at customers POS computer when the display hangs).
• One time installation/upgrades. (e.g. change config file of POS application to work with a new server).

Chocolatey /NuGet Server is a near perfect fit for this.

• A central repository where we can publish scripts and applications.
• Client (Chocolatey install) that allows for downloading and automatically execution of script packages.

Use case vs. existing Chocolatey features

By having our scripts as ordinary Chocolatey packages we can see the following issues:

• Script can only be run once. To run again it has to be installed and uninstalled.
• All scripts that have been run will appear in Chocolateys list of installed packages.
• Some scripts might contain a large payload. Our clients usually have small SSD drives. No reason to fill up the disk with scripts that maybe will never be used again.
• When a new script is published, all installed scripts (read: scripts that have been run atleast once) will be automatically rerun when we do cup all. (And if e.g. we publish a defrag script, it will be quite weird behaviour to have your disk defragged when you update your applications).

We have considered a manual workaround for this:

• Naming convention for packages that are not meant to be installed. We settled for .run as extension.
• When someone install a .run package they are supposed to immediately uninstall it.
• If .run packages show up in 'choco list -lo' they are supposed to be ignored.

But we realised that the workaround could be easily implemented in code. Which led to this issue / pull request.

[andulv]

I am aware that our exact use case is probably a bit off from typical Chocolatey usage. But I believe this feature also opens up for a lot of similar use-cases for example regarding server-management and maintenance.

I can also see some possible use cases for ordinary public Chocolatey packages.

Consider: CleanUp-TeamViewer.run - A package that removes all traces of all TV versions from your computer.

This would probably be useful to have as Chocolatey package.

But without special support for .run packages in Chocolatey, this package will be installed and show up in the list of Installed packages. Uninstalling makes no sense. (Some users will maybe even believe uninstallation will revert the cleanup done).

[ferventcoder]

A chocolatey package != install something

[ferventcoder]

That's my first response. I will want to consider a bit more based on your example.

[andulv]

I am not quite sure how to interpret your reply.

As Chocolatey is today, it appears to me that "running a package" == installing something. I think that is also how most other users perceive it.

This appearance is augmented by the fact that all packages are kept track of, and can be uininstalled or upgraded. Especially the automatic update bite (cup all, possibly scheduled).

If it is your intention that chocolatey package != install something, I think that this feature (or something similar or better) is exactly what is needed. :)

BTW: I updated the original issue-post with an additional point under 'Use case vs. existing Chocolatey features':
..When a new script is published, all installed scripts (read: scripts that have been run atleast once) will ..be automatically rerun when we do cup all. (And if e.g. we publish a defrag script, it will be quite weird ..behaviour to have your disk defragged when you update your applications).

[ferventcoder]

installing a package gets misinterpreted as only "installing" software on a machine, but it can also make configuration changes (which I believe you are defining as .run packages).

[ferventcoder]

The question being, if you applied a configuration, how would you know it happened if you deleted the package?

Update - What I mean is, if you have a large range of computers and you want to know which ones were successful and which ones were not applying a configuration, what would you need to do to see it happened?

Also, how does dpkg/rpm handle this concept now?

[ferventcoder]

Concept of pinning packages prevents automatic upgrade of those packages.

[ferventcoder]

Also, I wouldn't necessarily look at the community feed (chocolatey.org) as the end all be all of how most businesses use choco. The simple fact is that many, many of them NEVER hit the community feed. They are doing things somewhat differently with the packages they create, including binaries much more often and setting up configurations (so they can replace GPO). Sometimes folks couple those configurations with a configuration management tool like Puppet (config management means any change to the configuration of a computer, including settings and software). Chocolatey plugs right in as a package manager provider to Puppet.

[ferventcoder]

I'm not dismissing this one straight off. Just trying to understand how it is different and necessary over just the normal concept of normal packages that do some configuration tasks.

[andulv]

Configuratiion changes might be(by my definition) in a "grey zone" betweeen .run packages and ordinary packages.

In some cases they might qualify for a .run package, but usually it is something you can apply/update/remove and then it is a normal package. And as you say, you want to keep track of it has been done.

I have noticed the business use of Chocolatey. Most (other) business cases I have read about have very much been concerned with configuration and deployment to servers. Puppet and its like very seldom mentions client/desktop management.

One usage I had thought of is systeminfo scripts:
choco install ListDriveInfo.run - Lists all drives with available space.
choco install ListSqlServer.run - Lists all installed SQL Server instances, with all databases

Another is problemfixing:
choco install ResetCustomerDisplay.run - Sends commands to COM port that resets stuck display. This command will only be issued when the display actually is stuck. As soon as we have deployed a version of the POS Application that solves this problem (or replaced the brand of customer displays) we can retire this package.

Or maintenance:
choco install DefragDatabase.run <-connectionstring>

But I see your arguments, and I am starting to get less than 110% convinced that this feature really is necessary.

We might be able to manage with "Configuration packages" and ordinary packages that installs sets of custom utils (which are then executed outside of Chocolatey).

We are starting deployment now. I will come back with actual real-word examples of situations where we see the need for .run scripts if/when we encounter them. :)