-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(PUP-1691) Install Chocolatey #76
(PUP-1691) Install Chocolatey #76
Conversation
To install Chocolatey, we need to take a dependency on the powershell module. To be able to validate user input, it's best to take a dependency on stdlib as it has quite a bit of built-in validation.
This is the same script found at https://chocolatey.org/install.ps1.
cd184cc
to
e0f09c5
Compare
Allow installing chocolatey with a custom package location. Also allow using the built-in windows shell to unzip the package. The original request for this had the ability to use the built-in Windows shell to perform the unzipping and it keeps folks from having to download an external executable by default. Allow 25 minutes for it to finish.
e0f09c5
to
114b131
Compare
Depend on the windows_env module for path update changes. This is to ensure they are propagated on the same run you install Chocolatey in.
For spec testing, ensure that the `.fixtures.yml` has all modules that are dependencies listed.
Allow install timeout to be configurable. Move all variables to params.pp.
Ensure that the windows environment variables are set and are present. This should also allow Chocolatey to be installed and used on the first run of Puppet as it will refresh the PATH environment variable so that suitability is redetermined[1]. This stems from an original conversation[2] with a few community members and @joshcooper about suitability determination not being cached in newer versions of Puppet. [1] https://docs.puppetlabs.com/guides/provider_development.html#suitability [2] https://groups.google.com/d/topic/chocolatey/0hPNtAMmhNM/discussion
This includes a custom fact for chocolatey's installpath. It will attempt to read the environment variable for ChocolateyInstall from the registry and default to 'C:\ProgramData\Chocolatey' if it is not found. This allows Chocolatey to look at an existing installation by defaut. The `$chocolatey::params::install_location` variable will default to this custom fact, but can be overridden when declaring the class.
Super excited to see this being worked on. Any reason there isn't an init.pp file? It's very Puppet-paradigm aligned to want to |
@reidmv What would you like to see in an init.pp? :) |
I will mod this too. |
What does that mean @rismoney ? |
@ferventcoder what the current |
Not change functionality, just refactoring a little. Add rspec, not use erb, and some tweaks. |
@reidmv the install of a thing I've seen in install.pp files as a puppet convention, whereas the init.pp I've seen typically manages execution of the thing. Since choco is a custom type/provider, execution is relegated to the provider. Am I off on this? |
this is what i was thinking for the erb- |
@ferventcoder using an install.pp is part of a module internals pattern most formally described by R.I. Pienaar in 2009 and redux'd in 2012. It's typically used to break apart an overall configuration into sub-classes for ease of implementation. When the pattern is used, the If you wanted to use that pattern, an init.pp might be created that looked like the following, and the existing class chocolatey (
$chocolatey_download_url = $chocolatey::params::download_url,
$use_7zip = $chocolatey::params::use_7zip,
$choco_install_location = $chocolatey::params::install_location,
$choco_install_timeout = $chocolatey::params::install_timeout,
) {
contain chocolatey::install
} Given that this is not an overly complex module yet, that pattern make not make sense yet. It might be clearer and more straightforward just to have a single The issue description in PUP-4638 talks a little bit about class names too and is loosely analogous. |
@reidmv thanks! I read those articles, and TIL. I will add in an init.pp - it all makes perfect sense in the way that it was written. :) |
@rismoney I left comments, but overall, I like that approach. |
Introduce init.pp and set install.pp as a private class. This allows the benefit of `include chocolatey` without needing to think about how to install Chocolatey and do any additional setup steps. This was suggested by @reidmv at chocolatey-archive#76 (comment). As an artifact of this change, move stdlib requirement to at least 4.6.0. At some point in the future, it may be wise to work around using both `private()` and `assert_private()` with a custom function that determines what version of Puppet and what version of stdlib.
00ba7d4
to
3999916
Compare
Introduce init.pp and set install.pp as a private class. This allows the benefit of `include chocolatey` without needing to think about how to install Chocolatey and do any additional setup steps. This was suggested by @reidmv at chocolatey-archive#76 (comment). As an artifact of adding `assert_private()`, move stdlib requirement to at least 4.6.0.
3999916
to
21b2e8b
Compare
95cc6be
to
125491f
Compare
Set autouninstaller to true by default.
Validate that the parameters being passed in meet the expectations.
Similar to Facter for Puppet versions less than 3.5.0, if Hiera version hasn't been set, use a version that was released with older Puppet versions. Additionally ensure that both facter and hiera are treated this way no matter if the Puppet is on Windows or on *nix.
125491f
to
b59807a
Compare
begin | ||
old_choco_message = 'Please run chocolatey /? or chocolatey help - chocolatey v' | ||
#Facter::Core::Execution.exec is 2.0.1 forward | ||
value = Facter::Util::Resolution.exec("#{choco_path} -v").gsub(old_choco_message,'').strip |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this will need to support checking Facter.version
after all based on the api that is available in v3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this was left in v3 so we don't need to do this.
Contain is not a supported keyword prior to Puppet 3.4.0. If less than 3.4.0, use the anchor pattern instead.
Add examples of usage surrounding the installation of Chocolatey to the readme and document the classes/parameters.
Confine boundaries on upper versions of dependencies. This allows better compatibility as the major version barrier is a known semantic versioning boundary for incompatible changes.
Expose a custom fact about Chocolatey's version. Do not attempt to do configuration in versions of choco less than 0.9.9. This does mean a second convergence will be required to apply the configuration settings.
b59807a
to
d5e4ce8
Compare
Add documentation for the new facts this module produces.
d5e4ce8
to
6396bb6
Compare
…ll-chocolatey (PUP-1691) Install Chocolatey
well done-woot!!! |
Release train is rolling right now :) |
…ster/MODULES-4678_fix_config (MODULES-4678) Explicitly close config on read
$::serverversion
, then$::clientversion
[] Fix facter check for version 3 to public apiThis is related to #61. This supersedes #24.