It's definitely not equivalent to "apt-get" -- I tried it out recently and it's a scripted installer for many things, but lacks a functional package manager backend like apt-get requires (dpkg, rpm for apt-rpm, etc).
Further, it doesn't have a repository of the packages themselves -- it tries to pull them from upstream, which sometimes means it will try to fetch a version that has been removed, moved, or is otherwise unavailable for reasons outside of the script's control and the people manually updating the database have not updated this packages URL. That is, without action this database will "rot" very quickly.
Because it lacks a functional package manager which understands that packages are just a collection of files on disk and plonks them down and instead tries to automate the install of every changing upstream package, which requires lots of testing. They seem to have automated test suites based on their webpage's green/red "dots" indicating a package passed/failed, however even installing software that was "passing" didn't always work for me.
Additionally, installing packages then tries to configure them based on command-line arguments... which are not the same for every package and are poorly documented for most packages...
A package manager can be made to work on Microsoft Windows, but this isn't "it" -- it might be an improvement. I haven't used Microsoft Windows in years and recently wanted to test out OpenSSH on Microsoft Windows (also terrible quality) so I tried Chocolatey and was quite disappointed.
The largest hurdle, I suspect, and the one that causes all of the design decisions in Chocolatey to be made the way they are is the prevalence of software with onerous distribution licensing such that they are not legally able to make a central repository under their control, and are not able to disassemble the installer packages and make sane packages with pre/post install scripts that operate consistently... But for something like OpenSSH it could have been made to work.
Something that has more of a "true" package manager feel for windows is scoop: https://scoop.sh
It's not quite a full package manager either - but it works well enough, should be easy to add package/manifests for, and does allow one to update installed packages:
Actually it depends on the package type. Chocolatey doesn't require an admin shell nor does it require PowerShell for packages that have the runtime executables embedded in the package. Those are known as portable packages.
The problem with a blanket statement for admin shell is that for almost everything you want to do with Windows, it requires administrative permissions to actually install things. So it's more that Windows requires admin permissions to run native installers like MSIs, InstallShield, InnoSetup, etc.
PowerShell is also been moved down to just an automated script install provider in choco. It will become optional once ScriptCS and others are supported as alternative automated script providers.
You are correct about the distribution licensing, however that really only applies to the packages on the community feed. When Chocolatey is used internally, I think you will see it is more about files on disk versus dealing with things changing and the non-deterministic nature of the internet.
Further, it doesn't have a repository of the packages themselves -- it tries to pull them from upstream, which sometimes means it will try to fetch a version that has been removed, moved, or is otherwise unavailable for reasons outside of the script's control and the people manually updating the database have not updated this packages URL. That is, without action this database will "rot" very quickly.
Because it lacks a functional package manager which understands that packages are just a collection of files on disk and plonks them down and instead tries to automate the install of every changing upstream package, which requires lots of testing. They seem to have automated test suites based on their webpage's green/red "dots" indicating a package passed/failed, however even installing software that was "passing" didn't always work for me.
Additionally, installing packages then tries to configure them based on command-line arguments... which are not the same for every package and are poorly documented for most packages...
A package manager can be made to work on Microsoft Windows, but this isn't "it" -- it might be an improvement. I haven't used Microsoft Windows in years and recently wanted to test out OpenSSH on Microsoft Windows (also terrible quality) so I tried Chocolatey and was quite disappointed.
The largest hurdle, I suspect, and the one that causes all of the design decisions in Chocolatey to be made the way they are is the prevalence of software with onerous distribution licensing such that they are not legally able to make a central repository under their control, and are not able to disassemble the installer packages and make sane packages with pre/post install scripts that operate consistently... But for something like OpenSSH it could have been made to work.