Use the official install.ps1

[docwhat]

This uses the remote_file resource to fetch the install.ps1 from chocolatey.org

This should allow improvements from the "official" copy to be matched in the chocolatey version.

This is an alternative to #112

I would argue that using the official install.ps1 is worth the extra network traffic (which is only a conditional GET anyway).

[docwhat]

This will require #114 to pass.

[docwhat]

Arguments for using the official version:

• conditional GETs aren't a huge deal, traffic wise and shouldn't be a burden for the Node or for chocolatey.org
• Using the official version means we don't have to worry about new features slipping into install.ps1 and having trouble in the future.
• DRY -- Why re-implement the official version?
• We'll always get the latest features without having to update the cookbook.

Cons:

• Even small network traffic can be burdensome.
• Network outages prevent converge succeeding.
• The chocolatey.org version may add/remove environment variables and break things.

[mwrock]

Have a look at https://github.com/chocolatey/chocolatey-cookbook/pull/81. We used to pull from chocolatey.org but had reliability issues and switched to keeping it local.

[ferventcoder]

Cons:

• Can't use in offline scenarios.
• Harder to customize the location to install Chocolatey from.
• Can't pass along other ruby variables.

[docwhat]

I looked at #81 and I don't see a huge issue there, other than the chocolatey.org being down.

I made the remote_file use ignore_failure so that it won't break a converge if chocolatey.org is down. However, it'll fail the next step which tries to run it if it was never downloaded.

The ['install_vars']['chocolateyDownloadUrl'] attribute is still honored, because the default install.ps1 honors it.

I added a new [install_ps1_url] attribute so that the install.ps1 can be fetched from a local source if someone is running in an environment with no internet.

[docwhat]

Replying to @ferventcoder's objections:

Can't use in offline scenarios.

You can, but you have to set two variables now:

• ['install_vars']['chocolateyDownloadUrl']
• ['install_ps1_url']

Harder to customize the location to install Chocolatey from.

It uses the same attribute as before: [install_vars][chocolateyDownloadUrl]

Instead of using a template, it is passed as an environment variable: $env:chocolateyDownloadUrl

Can't pass along other ruby variables.

I'm not sure what you mean. The only variable passed to the template was download_url which was just [install_vars][chocolateyDownloadUrl] and available as an environment variable anyway.

[ferventcoder]

I'm not sure what you mean. The only variable passed to the template was download_url which was just [install_vars][chocolateyDownloadUrl] and available as an environment variable anyway.

This is my attempt to state things should be more consistent with the Chef cookbook. This is what is found in the Puppet template:

$url = '<%= @download_url %>'
$unzipMethod = '<%= @unzip_type %>'

Although that is all that is there now, if you go and look at the one from Chocolatey.org, you will see it adds more options that could be parameterized (although some may not apply):

# Environment Variables, specified as $env:NAME in PowerShell.exe and %NAME% in cmd.exe.
# For explicit proxy, please set $env:chocolateyProxyLocation and optionally $env:chocolateyProxyUser and $env:chocolateyProxyPassword
# For an explicit version of Chocolatey, please set $env:chocolateyVersion = 'versionnumber'
# To target a different url for chocolatey.nupkg, please set $env:chocolateyDownloadUrl = 'full url to nupkg file'
# NOTE: $env:chocolateyDownloadUrl does not work with $env:chocolateyVersion.
# To use built-in compression instead of 7zip (requires additional download), please set $env:chocolateyUseWindowsCompression = 'true'
# To bypass the use of any proxy, please set $env:chocolateyIgnoreProxy = 'true'

[docwhat]

@ferventcoder I must be dense, because I still don't understand...

The node['chocolatey']['install_vars'] cover all the variables that the chocolatey.org install.ps1 has at the moment...

From attributes/default.rb:

# Chocolatey install.ps1 env vars. See https://chocolatey.org/install.ps1
default['chocolatey']['install_vars'].tap do |env|
  env['chocolateyProxyLocation'] = Chef::Config['https_proxy'] || ENV['https_proxy']
  env['chocolateyProxyUser'] = nil
  env['chocolateyProxyPassword'] = nil
  env['chocolateyVersion'] = nil
  env['chocolateyDownloadUrl'] = 'https://chocolatey.org/api/v2/package/chocolatey'
  env['chocolateyUseWindowsCompression'] = nil
end

Feature-wise, that's more than the puppet one handles.

If at some point in the future the https://chocolatey.org/install.ps1 script takes a new environment variable (e.g. $env:chocolateyPreferVanilla) then an end-user can configure it via the node['chocolatey']['install_vars'] (e.g. node['chocolately']['install_vars']['chocolateyPreferVanilla'] = true).

Thanks for sticking with me, here... what am I missing?

[ferventcoder]

This wasn't an argument on how fully featured one is over another.

It's about the default means of internet but configurable (and more work) to use a local script. Defaulting to internet and backing up to local use seems different than what I am used to for organizations building reliable solutions.

[ferventcoder]

I don't know, maybe it's better to try for a bit.

[mwrock]

I really appreciate this PR, but I do want to make clear that for now we want to keep the installer script local. Prior to #81 we did have alot of issues with download reliability and things have been much smoother since. So I'd prefer to see improvements focus on refreshing the local script. Thanks!

[docwhat]

Fair enough!

I dropped the stock install.ps1 from chocolatey.org into the files section. This should make updating in the future much easier (just curl the official one).

How's that?

[mwrock]

This is going to break people using the chocolateyDownloadUrl node attrubute and host their own choco distro. Ideally I think this pr should just change the template.

[docwhat]

This is one of the bits I don't understand...

Is that behaving differently in the old template version than with the chocolate.org version? Because there is a matching $env: var there that I thought did the same thing.

If they are different then I have to reread the powershell scripts to figure out the differences.

[mwrock]

Yes the powershell in the chocolatey.org version allows an environment variable to override the default. The template in this cookbook goes one step further and allows a node attribute to override it. This is part of the public interface of the cookbook so to speak so we don't want to change it.

[docwhat]

@mwrock:

Yes the powershell in the chocolatey.org version allows an environment variable to override the default. The template in this cookbook goes one step further and allows a node attribute to override it. This is part of the public interface of the cookbook so to speak so we don't want to change it.

This isn't changed by using the upstream version of install.ps1. Here's the powershell_script resources:

powershell_script 'Install Chocolatey' do
  environment node['chocolatey']['install_vars']
  cwd Chef::Config['file_cache_path']
  code install_ps1
  not_if { chocolatey_installed? && (node['chocolatey']['upgrade'] == false) }
end

The environment node['chocolatey']['install_vars'] line means that all the node attributes will be passed in as environment variables.

One of node install_vars is "chocolateyDownloadUrl", which in powershell becomes $env: chocolateyDownloadUrl.

So there is no change in cookbook features.

[mwrock]

Oh I totally didn't see that. Thanks!

[mwrock]

Released to supermarket as v1.1.0.

[docwhat]

W00T!