Chocolatey-coreteampackages: (vagrant) Fails to fully install

[TonyApuzzo]

Vagrant 2.1.2 package install fails, but Vagrant is in fact installed.

Expected Behavior

choco install vagrant should complete succesfully.

Current Behavior

choco install vagrant fails with an error message and the package is moved to lib-bad even though the package installs.

Error messages in the log are not super helpful to me, but the installation runs correctly, and exits with code 3010. Around that time the rest of the install package fails.

Relevant portions of the chocolately log can be viewed here: https://gist.github.com/TonyApuzzo/1ed140ad5a257afa1bd874acd5ee8090

Possible Solution

Steps to Reproduce (for bugs)

1. uninstall vagrant from machine
2. choco install vagrant
3. ... failure ...
4. vagrant --version returns "Vagrant 2.1.2"

Context

Your Environment

• Package Version used: Vagrant 2.1.2.20180731
• Operating System and version:

λ   [System.Environment]::OSVersion.Version
Major  Minor  Build  Revision
-----  -----  -----  --------
10     0      17134  0

• Chocolatey version:

λ  choco --version
0.10.11

• Install/uninstall gist: https://gist.github.com/TonyApuzzo/1ed140ad5a257afa1bd874acd5ee8090

[AdmiringWorm]

hmm, from the looks of it in the log the installation actually succeeded, but it's rather the call to vagrant plugin repair (I think that was what we're calling) that failed.

I'm thinking we perhaps take that portion out of the package, and perhaps write out a warning instead to remind users to call it themself.

/cc @majkinetor

[TonyApuzzo]

That's what I thought too, but the call to "shutdown" returning 1116 threw me off. Is maybe the plugin repair failing because the system was not rebooted?

[AdmiringWorm]

@TonyApuzzo That's a call from choco itself, to try to prevent a reboot (or was it to detect if a reboot is necessary, can't remember).

[AdmiringWorm]

Not familiar with the exit code of 1116 though

[majkinetor]

I'm thinking we perhaps take that portion out of the package, and perhaps write out a warning instead to remind users to call it themself.

This is intentional and shouldn't be removed, see #1024.

It could be made more robust, to not fail on err because it affects only some of the users having vagrant plugins.

[TonyApuzzo]

Maybe just putting:

$ErrorActionPreference = "Continue"

Before the vagrant plugin repair line would be enough??

[majkinetor]

I doubt that will help. Vagrant is like native app and posh preference isn't relevant. $LastExitCode = 0 might do the trick. I suggest you to try it on your system and let us know the results.

[TonyApuzzo]

I would be happy to try it out and/or create a pull-request but I don't know how to modify a package and run it locally, it always seems to get overwritten by the downloaded package.

Any pointers to docs or suggested search would be appreciated. My google-fu is apparently lacking for finding developer info for chocolatey.

[TonyApuzzo]

I read "https://github.com/chocolatey/choco/wiki/PackageMantainerHandover" but I don't understand the "add link to repository to your chocolatey profile" what does that mean? I looked in "C:ProgramDatachocolateyhelperschocolateyProfile.psm1" but there is nothing about setting a git repo URL.

[majkinetor]

I would be happy to try it out and/or create a pull-request but I don't know how to modify a package and run it locally, it always seems to get overwritten by the downloaded package.

The simplest way (in admin shell):

• cinst au
• git clone https://github.com/your-adr/your-fork-of-chocolatey-coreteampackages
• change the code
• cd .../automatic/vagrant
• Test-Package

If it works, you can submit PR with the change.

I believe something like

vagrant plugin repair
$LastExitCode = 0

[TonyApuzzo]

I apologize for my ignorance, but I cannot figure out how to get the "AU" module loaded.

I have tried cinst au as well as Install-Module au (and permutations like Install-Module AU) but nothing works.

I searched and found some prior issues where the functions were not exported, but this does not seem to be my problem currently. I have default folders for all scripts and module paths as far as I know.

> import-module -Name AU -Verbose
VERBOSE: Loading module from path 'C:\Program Files\WindowsPowerShell\Modules\AU\2018.5.18\AU.psd1'.

> gmo au -ListAvailable


    Directory: C:\Program Files\WindowsPowerShell\Modules


ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     2018.5.18  AU                                  {Get-AUPackages, Get-RemoteChecksum, Get-RemoteFiles, Get-...


> Get-Command Test-Package
Get-Command : The term 'Test-Package' is not recognized as the name of a cmdlet, function, script file, or operable
program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ Get-Command Test-Package
+ ~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Test-Package:String) [Get-Command], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException,Microsoft.PowerShell.Commands.GetCommandCommand

I don't know if this is relevant, but if I leave the -ListAvailable argument off, it shows nothing exported.

> gmo au

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     2018.5.18  AU

[majkinetor]

Have you tried to call import-module au and then Test-Package ?

[TonyApuzzo]

Yes, as is in the screen capture above. It doesn't seem to import anything when I run import-module au even though it shows no errors. I'm on Windows 10:

λ  [environment]::OSVersion.Version
Major  Minor  Build  Revision
-----  -----  -----  --------
10     0      17134  0

λ   $PSVersionTable.PSVersion
Major  Minor  Build  Revision
-----  -----  -----  --------
5      1      17134  228

[TonyApuzzo]

OK, The AU package failed to import because my PowerShell profile removes all the fake unix aliases (specifically "ls"). I will eventually get around to logging cases against AU :-)

Trying to test the changes now, but the first pass didn't work. If/when I figure it out I will make a pull-request. -- Had to learn to manually delete the *.nupkg file since Test-Package doesn't seem to rebuild it if it already exists. PR created.

[majkinetor]

OK, The AU package failed to import because my PowerShell profile removes all the fake unix aliases (specifically "ls"). I will eventually get around to logging cases against AU :-)

You deserve this, really :) I actually keep aliases as a way to identify craziness in the wild.

Test-Package doesn't seem to rebuild it if it already exists.

cpack; Test-Package