Prior to this commit, the puppet provisioner would not properly set its
environment variables, if any were configured in the Vagrantfile. This
commit separates those properly with semicolons when calling out to
puppet apply.
Prior to this commit, the puppet provisioner would use the manifest dir
flag when running `puppet apply`. Not only is this flag redundant due to
how puppet apply works, but it is also deprecated in Puppet 4 and
removed in Puppet 5. This commit simply removes the flag when invoking
`puppet apply`.
The rationale here is to make it so existing Vagrantfile
configurations remain unchanged.
While benh57's solution worked for me, I had to add a
".to_yaml" to the VagrantFile line that implemented puppet.facter
and this would mean existing Vagrant configurations that use Puppet
would produce an error if that was not present.
Additionally, without this change, the Vagrant file also needed a
"require('yaml')" declaration to make the ".to_yaml" conversion
possible.
Starting with vagrant 1.7.3
(commit 1152b4e1df97fb5f468491954932d4f0c09875b1) we don't
save the command to be executed in the file anymore, but we send
it as a parameter, thus the back tick makes things worse.
puppet_server provisioner fails with Puppet Collection 1 with the
following error:
```bash
==> default: Running provisioner: puppet_server...
The `puppet` binary appears not to be in the PATH of the guest. This
could be because the PATH is not properly setup or perhaps Puppet is not
installed on this guest. Puppet provisioning can not continue without
Puppet properly installed.
```
As this is nested in a powershell variable $command, it must be escaped
otherwise it is evaluated when the variable is created, giving an error that
"The term 'True' is not recognized as the name of a cmdlet, function,
script". This prevented using a puppet.working_directory on Windows.
Powershell doesn't understand the unix-style ENV=thing command syntax, the old vagrant-windows plugin monkey patched the provisioner to put semicolons between statements to set the variables before running puppet - this fixes the issue inside a windows? block leaving the normal non-windows code path working - therefore works for me on both unix and windows provisions with a facter block in place
