@panzer's list above shows that there are several options for third-party non-proprietary application AUMs (Auto-Update Managers) in the market, and an exhaustively comprehensive list could well be much longer.

Yes, I took a look at:

  https://alternativeto.net/software/chocolatey/?platform=windows

while trying out a number of things, and indeed that list was on the long side.

I gave up as I found that they generally tended to have some unavoidable common limitations which, taken together, made them not-so-useful for my purposes.

That had been the case here too, but things seem to have evolved over the years -- of course, my criteria are different.  For example, I'd much prefer something along the lines of:

* Can examine, tweak and extend source code of the system, but also allow creation of 'recipes' for additional software with a reasonable amount of effort
* Can build with tools which I 'can build' / trust
* The system itself being portable
* Not requiring additional components to be installed (or minimal additions if possible -- it turns out that there appears to be a version of Scoop which runs with PowerShell 2 so PowerShell 3 may not have to be installed if one is using Windows 7 SP1)

As we're likely all aware, the installation / deployment step has been abused in recent years so some might say it's prudent to be on the paranoid side regarding tools and systems that aid in such processes

You eventually find it minimised in the small print - e.g., Piriform.com (as at 2015-09-19), where you have to scroll down to the small print (no Big Fat Button, like for the paid version) where it merely says, for example, Piriform.com as an optional site to download from.

[offtopic]
Interestingly, I don't get that at all - if I tell it to check for update I get taken to a page where there's an option to buy the Pro version but there's also a large button that says No thanks.
Clicking that takes me to the normal download page where there is no option to tell it where to download from but you do get the option to go to the Builds page to download the Portable and Slim versions.
[/offtopic]

More info: Gow is a shell, not a package manager.  It's an alternative for windows to Cygwin.  But it was a welcome find for other reasons, even so.  I'd stopped using Cygwin because it was so huge.  Gow is apparently small.

More Cygwin alternatives (at the bottom of the page):
http://alternativeto.net/software/cygwin/

More info: Gow is a shell, not a package manager.  It's an alternative for windows to Cygwin.  But it was a welcome find for other reasons, even so.  I'd stopped using Cygwin because it was so huge.  Gow is apparently small.

I'd come to use Cygwin less over the years as I had difficulty consistently making it portable -- the size was also not a point in its favor.

Gow does look interesting.

Thanks to panzer for pointing it out

IIRC, I'd avoided ZeroInstall earlier because of .NET dependencies and the seeming requirement of having to sign packages (nice to have optionally, but being forced even for my own local purposes seemed too much).

Current impression is that with "local feeds", signing is not necessary (or not done even if desired?):

There are two other differences to note: there is no digital signature at the end (we assume that no attacker could intercept the file between your harddisk and you ;-), and the version number ends in a modifier (-pre in this case), showing that it hasn't been released.

via http://0install.net/local-feeds.html

...Does that sound about right?...
_______________________

Hahaha, well it looks like it could be, but it seems that there's probably a lot more going on - or at least implicit in what is going on - than a simple précis such as yours might be able to do justice to.
For example, one of the implications that stood out for me was the potential usefulness of all the tools that were being used in a linked/sequential fashion. The demo showed it all being done manually (by typing commands into the PowerShell interface), complete with errors and then corrections, at the keyboard. The person at the keyboard probably needs to be something like (say) a Grade A system mechanic in the systems being used with current knowledge all in his head as he types - and he did say he had spent a lot of time getting to that point - so there's a dependency right there.

Could it be done by an inexperienced operator/user? Probably not without further automation.
The challenge would thus seem to be to encapsulate/automate all of what he did, as (say) a batch job or (better) via a stable and robust GUI wizard interface.
The OP for this thread requests opinions/thoughts about Chocolatey and using it as a portable tool. Portability might actually make what already seems to be a powerful and complex toolset even more complex to use, and thus more complex/difficult to automate (e.g., a decision table with too many potential decision branches with unknown exits in the process to be able to easily cater for them all). Furthermore, even if you did manage to automate it, would the potential impermanence of some of the toolset components frustrate the objective of the wizard GUI?

What I mean by that is, looking at it from a theoretical perspective, if:

• (a) the AS-IS process steps to achieve a given outcome are undocumented or poorly documented and liable to be changed at short notice in an uncontrolled fashion, then they are Ad hoc (CMM Level 1) - aka Chaotic. It would be a waste of time trying to automate that as the risk would be that by the time you had automated and tested the automation, the process steps could have been changed without your knowledge, pulling the rug out from underneath you, as it were. So that would not be recommended as a cost-effective action.
  
• (b) the AS-IS process steps to achieve a given outcome are undocumented or poorly documented at best, and used repeatably and are thus more reliable, but still changed in an uncontrolled fashion, then they are Repeatable (CMM Level 2), and though it might seem worthwhile to try to automate that, it still carries the same risk as in (a). So that would not be recommended as a cost-effective action.
  
• (c) the AS-IS process steps to achieve a given outcome are defined and documented and used repeatably and only changed occasionally in a relatively controlled fashion, then they are Defined (CMM Level 3), and reliable to the extent that it would probably be worthwhile putting the effort into trying to automate the process. So that would be recommended as a cost-effective action.

Things get even better at CMM Levels above that, but - and I could be wrong, of course - I get the impression from the video that the CMM Level in this case was likely to be 1 or 2, but not 3 for some/most of the toolset components - in which case, from a risk-avoidance perspective - you take the lowest CMM Level of any part of the AS-IS process as your LCD (Lowest Common Denominator) and overall CMM level (it's the weakest link). That could be termed as being "Not yet ready for Prime Time", or something.

Therefore, overall, I'd not be too optimistic about the process being something that could be fully automated with (say) a GUI wizard on the front. However, if one had the resources, an experimental approach might still be interesting. Try to do an exploratory "suck-it-and-see" - i.e., build a prototype of the automation Wizard - and see how long it lasts before a change (or successive changes) in the toolset breaks it. The trick then would be to see if you could obtain advance warning of any impending changes, so as to have a fix in place for the Wizard in sufficiently timely fashion as to avoid the Wizard failing.

A bit of a rant:
A current example of an update process with an LCD at CMM Level 1 (Ad hoc/Chaotic) could be the process for releasing Mozilla Firefox Beta versions. I subscribe to the Beta release channel, and I have to put up with releases coming out like water sputtering out of a hosepipe with air-locks. Just about every release screws something or other up, typically breaking one or several FF add-ons/extensions, and usually for no other better reason than that the probably overworked add-on developers don't have the time/resources to jump when FF says "Jump!" and so don't manage to get the add-on verified in time for the uncontrolled release schedule.
So the add-ons tab is spattered with disabled add-ons, because some wag at Mozilla has issued a bureaucratic mandate that all add-ons must be verified by Mozilla for each new FF release or the add-on will be disabled, or something.

Wherever you get CMM Level 1 or 2, you can usually identify cost inefficiencies and waste. The above Beta release process is what is often referred to by the euphemism "uncontrolled release management" in ITIL-speak, and is simply nothing more than just bad IT service management practice where the use of the term "management" could be a moot point.
The amount of work it creates (a lot of which may be unnecessary/unproductive) for the add-on developers must be rather like an iceberg, and Mozilla probably isn't paying these third-party developers to dance to their tune either, so it seems to be a cynical cost-transfer or economic externalisation exercise with "all care and no responsibility" on Mozilla's part, and with the developers footing the bill.
Quite a lot of pundits seem to be saying that Mozilla might have had a "cultural collapse" and lost sight of their original objectives, and that this verification dance is likely one of the outcomes from that collapse - and they may be right, but I couldn't possibly comment.

With no English documentation, I didn't feel I wanted to go in that direction.  Superficial... maybe?  But definitely a breaking point for me.

Being able to learn and then continue to do so about a topic seems an important criteria (especially for things that keep changing like software), so if the info is in a language one does not know, then that doesn't sound superficial to me

...I'd guess it's quite normal for something of this nature to not have documentation that's spelled out tidily -- but apart from docs, who knows how well the software behaves in practice (it might be fine, just haven't tested)!  Single programmer working for fun in spare time and all
_________________________

Yes, sure, but I wasn't suggesting that the AS-IS process had to be covered by "documentation that's spelled out tidily", but that the documentation should always  - at any point in time - accurately reflect the AS-IS process (regardless of the form that the documentation took).
I wasn't trying to denigrate the efforts of the people who got the video to that state, I was trying to show a line of reasoning, based on general theory, that the likelihood of being able to automate the relevant AS-IS processes seemed potentially low. I put the video link there because I reckon it was fantastic - I mean, it seemed really impressive in what it showed could be done there. It's just that, if you have that dependency - i.e., that you need to be a Grade A systems mechanic, or something, or drag one around with you to get it all working - then it's unlikely to be of much use to the general public/user. Only the techos would really be able to take advantage of all that good technology. So that could probably be quite a severe a limitation as to practical usage/applicability.

A key realisation to the understanding of the CMM and its implications is that, to all practical intents and purposes, if a process is generally likely to be in a perpetual or semi-perpetual state of dynamic change - e.g., as in CMM Level 1 (Ad hoc/Chaotic) or Level 2 (Repeatable) - then it is impermanent, and, try as one might to define it and automate it, it would be likely to keep changing whilst one was doing that, thus invalidating the definition/automation.  A bit like trying to pin down a blob of mercury. It would be a process that was probably outside of one's control, and would almost certainly be out of statistical control (Shewhart, Deming et al), so it would be unpredictable, by definition.

Automation necessarily carries the prerequisite of predictability of the AS-IS process and its outcomes.

Interestingly, and as an aside, the characteristics of organisations whose processes are generally at CMM Level 1 or 2 can typically include:

• (a) the working environment is chaotic,
• (b) there is a low level of general knowledge/understanding as to how the core business processes operate,
• (c) there is a lack of mutual professional respect,
• (d) there is frustration with the seeming inability to manage projects in a consistent, orderly and planned fashion,
• (e) there is a persistent culture of blame,
• (f) the rate of staff turnover is relatively high.

- so if that seems somewhat déjà vu, then that could be the the explanation as to why.

Not familiar with CMM, so am scanning a Wikipedia page for it (perhaps that's not too awful ).
___________________

Try this. I think it will still work: CMM - Capability Maturity Model

More info: Gow is a shell, not a package manager.  It's an alternative for windows to Cygwin.  But it was a welcome find for other reasons, even so.  I'd stopped using Cygwin because it was so huge.  Gow is apparently small.

Looking at Gow now.  Looks nice, glad to hear of it. 
Also, if all you need are the tools, not the environment, look at GNUWin32:
http://gnuwin32.sourceforge.net/

Pint - a minimalistic command line package manager for Windows:
https://github.com/vensko/pint