-
Notifications
You must be signed in to change notification settings - Fork 385
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
(chocolatey-core.extension) Added simple wrapper around Install-ChocolateyInstallPackage #612
Conversation
87fc41f
to
f260cf5
Compare
LGTM |
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.
LGTM, other than the small intendation issue
} | ||
|
||
$packageArgs = @{ | ||
packageName = $packageName |
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.
Remove whitespace before =
or intend all of them to the same level
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.
I've indented them this way on purpose, if I were to align them all to the same place as useOnlyPackageSilentArgs
then that would be too much IMO.
Therefore I indented only the first 5 arguments.
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.
It looks fine to me.
Would it be simply better to just add this to 0.10.4? |
I'm just thinking about all of the things, like the package-validator and those similar that would now need to account for this. Not that excited about changing all of those systems so they can see this as well when we can simply fix Chocolatey. |
And yes, I do realize that means it would be a few months before we could account for it on the community repository (about 6 months to allow the community to fully upgrade). As we've seen, folks are still upgrading from 0.9.8.x (over 3 years old now!!!!) so that things will work with latest changes on the community repository. |
@ferventcoder Yeah it would, but that would require the user to run choco v 0.10.4+.
I understand that, the reason I added this script is to have an option when users are running an older version of choco. |
@AdmiringWorm there actually is. It's actually somewhat simple and something we used a long time ago when we were building mocking for Pester. You can look at the version of Chocolatey
If that version is less than version 0.10.4 (flip it to use System.Version I believe and compare the two). Then use that to decide whether to load this or not - if you decide to load the function, capture the original Rename-Item function:Install-ChocolateyInstallPackage Install-ChocolateyInstallPackageActual And rename the $currentChocoVersion = $env:CHOCOLATEY_VERSION
if ($currentChocoVersion -and [Version]$currentChocoVersion -ge [Version]'0.10.4'){
return
}
Write-Debug "Loading Install-ChocolateyInstallPackage override"
Rename-Item function:Install-ChocolateyInstallPackage Install-ChocolateyInstallPackage-Actual
# docs here
function Install-ChocolateyInstallPackage {
# code here
Install-ChocolateyInstallPackage-Actual @packageArgs
} |
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.
Take a look at what has been requested as far as a really good way to handle this.
@ferventcoder awesome, I'll definitely take a look at changing this function to something like that. |
[alias("installerType","installType")][string] $fileType = 'exe', | ||
[parameter(Mandatory=$false, Position=2)][string[]] $silentArgs = '', | ||
[alias("fileFullPath")][parameter(Mandatory=$false, Position=3)][string] $file, | ||
[alias("fileFullPath64","file64Bit")][Parameter(Mandatory=$false, Position=4)][string] $file64, |
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.
Remove position. We are moving away from this. So never add new items with a position.
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.
will do
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.
Also not a fan of $file64bit, can it be removed? I want this to have parity with function updates that will roll back into Chocolatey.
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.
sure, it can be removed. I actually added it because of the use of -Url64bit
in the Install-ChocolateyPackage
[parameter(Mandatory=$false, Position=1)] | ||
[alias("installerType","installType")][string] $fileType = 'exe', | ||
[parameter(Mandatory=$false, Position=2)][string[]] $silentArgs = '', | ||
[alias("fileFullPath")][parameter(Mandatory=$false, Position=3)][string] $file, |
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.
Do you think we should leave this mandatory - This will either be a 64bit file or 32bit if more than one is sent.
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.
I don't really think this should be mandatory, if a package only supports 64-bit the IMO the helper function should throw an exception when trying to install the 32-bit version
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.
My point here is making this as well transitioned as possible.
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.
The documentation leads me to believe this is 32-bit, when in fact I can pass a 64bit installer through $file. Think of how this would be used over time and transition.
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.
Although I see the idea of making it optional so we can fail early if the file is only supported in 64bit scenarios.
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.
The idea was to have it behave somewhat similiar to the Install-ChocolateyPackage
urls parameters (which also gives the impression that Url
parameter is only for 32bit).
I'll definitely need to improve the documentation though.
I don't really see the problem with the transition though, since it will still fail if both file and file64 is not set.
That's fine as well. And likely better. |
Filed chocolatey/choco#1187 |
@ferventcoder I've added the check and renaming of the existing function. |
} | ||
|
||
# We need to force the export of Install-ChocolateyInstall function | ||
Export-ModuleMember -Function Install-ChocolateyInstallPackage |
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.
Will that work from here?
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.
And this is why I had a particular recommendation on letting each function decide whether to load up versus the universal one in the PowerShell module file. Sometimes I have a good reason that I can't always explain at the proper moment. Or it doesn't had those needs like this would have now.
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.
I believe so yes (I did try it on my own computer, although only through importing chocolatey-core.psm1
manually).
Since the chocolatey-core.psm1
is sourcing all of the files, it just don't export it since it had found an existing function with the same name.
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.
Before importing the chocolatey-core.psm1 file manually the following functions was found:
> Get-ChildItem function:\Install*
CommandType Name Version Source
----------- ---- ------- ------
Function Install-BinFile 0.0 chocolateyInstaller
Function Install-ChocolateyDesktopLink 0.0 chocolateyInstaller
Function Install-ChocolateyEnvironmentVariable 0.0 chocolateyInstaller
Function Install-ChocolateyExplorerMenuItem 0.0 chocolateyInstaller
Function Install-ChocolateyFileAssociation 0.0 chocolateyInstaller
Function Install-ChocolateyInstallPackage 0.0 chocolateyInstaller
Function Install-ChocolateyPackage 0.0 chocolateyInstaller
Function Install-ChocolateyPath 0.0 chocolateyInstaller
Function Install-ChocolateyPinnedTaskBarItem 0.0 chocolateyInstaller
Function Install-ChocolateyPowershellCommand 0.0 chocolateyInstaller
Function Install-ChocolateyShortcut 0.0 chocolateyInstaller
Function Install-ChocolateyVsixPackage 0.0 chocolateyInstaller
Function Install-ChocolateyZipPackage 0.0 chocolateyInstaller
Function Install-VisualStudio 0.0 chocolateyInstaller
Function Install-Vsix 0.0 chocolateyInstaller
Function Install-WindowsUpdate 0.0 chocolateyInstaller
After importing:
> Get-ChildItem function:\Install*
CommandType Name Version Source
----------- ---- ------- ------
Function Install-BinFile 0.0 chocolateyInstaller
Function Install-ChocolateyDesktopLink 0.0 chocolateyInstaller
Function Install-ChocolateyEnvironmentVariable 0.0 chocolateyInstaller
Function Install-ChocolateyExplorerMenuItem 0.0 chocolateyInstaller
Function Install-ChocolateyFileAssociation 0.0 chocolateyInstaller
Function Install-ChocolateyInstallPackage 0.0 chocolatey-core
Function Install-ChocolateyPackage 0.0 chocolateyInstaller
Function Install-ChocolateyPath 0.0 chocolateyInstaller
Function Install-ChocolateyPinnedTaskBarItem 0.0 chocolateyInstaller
Function Install-ChocolateyPowershellCommand 0.0 chocolateyInstaller
Function Install-ChocolateyShortcut 0.0 chocolateyInstaller
Function Install-ChocolateyVsixPackage 0.0 chocolateyInstaller
Function Install-ChocolateyZipPackage 0.0 chocolateyInstaller
Function Install-VisualStudio 0.0 chocolateyInstaller
Function Install-Vsix 0.0 chocolateyInstaller
Function Install-WindowsUpdate 0.0 chocolateyInstaller
Function Install-ChocolateyInstallPackageOriginal 0.0 chocolatey-core
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.
Ruhroh - looks like it is not picking up the original one.
Function Install-ChocolateyInstallPackageOriginal 0.0 chocolatey-core
That should probably be
Function Install-ChocolateyInstallPackageOriginal 0.0 chocolateyInstaller
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.
I think it's a drawback of the global import file, and the use of rename-item.
Could be wrong though.
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.
When importing with the latest commits,
the results is now this:
PS C:\Users\Administrator> Get-ChildItem function:\Install*
CommandType Name ModuleName
----------- ---- ----------
Function Install-BinFile chocolateyInstaller
Function Install-ChocolateyDesktopLink chocolateyInstaller
Function Install-ChocolateyEnvironmentVariable chocolateyInstaller
Function Install-ChocolateyExplorerMenuItem chocolateyInstaller
Function Install-ChocolateyFileAssociation chocolateyInstaller
Function Install-ChocolateyInstallPackage chocolateyInstaller
Function Install-ChocolateyInstallPackageOriginal chocolateyInstaller
Function Install-ChocolateyPackage chocolateyInstaller
Function Install-ChocolateyPath chocolateyInstaller
Function Install-ChocolateyPinnedTaskBarItem chocolateyInstaller
Function Install-ChocolateyPowershellCommand chocolateyInstaller
Function Install-ChocolateyShortcut chocolateyInstaller
Function Install-ChocolateyVsixPackage chocolateyInstaller
Function Install-ChocolateyZipPackage chocolateyInstaller
Function Install-Vsix chocolateyInstaller
Function Install-WindowsUpdate chocolateyInstaller
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.
So now the opposite problem.
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.
well, yes and no.
The reason I got chocolatey-core and chocolateyInstaller is becuase previously I imported both chocolateyInstaller.psm1 and chocolatey-core.psm1 separately.
Now I only imported chocolateyInstaller.psm1
return | ||
} | ||
|
||
Write-Debug "Loading Install-ChocolateyInstallPackage override" |
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.
And these debugging messages are necessary for determining issues - it may not be a bad idea to also have a debug message in the function itself.
} | ||
|
||
Install-ChocolateyInstallPackageEx @packageArgs | ||
#> |
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.
Synopsis and docs should be right by function Install-ChocolateyInstallPackage {
.
} else { | ||
Write-Host "Installing $packageName 64-bit" | ||
} | ||
$fileFullPath = $file64 |
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.
This looks incorrect.
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.
This should be captured inside of the else statement above it.
Looks like Rename-Item can't be used as it currently is. |
IIRC - Chocolatey loads its functions first, but it may not export everything until later, which results in a much less deterministic way of knowing what is loaded. |
However, I'm guessing you may be able to search for the function in |
Sorry, that's what I meant.
Yeah it could be, I'll need to have a look at that. |
@AdmiringWorm changed up the logic a bit - Let's ensure we match up on parameter names and aliases - chocolatey/choco@4cf2441 |
@ferventcoder I'll update this one with the same logic. |
@AdmiringWorm note I added chocolatey/choco#1200 to address the non-deterministic load (not that it is going to help here) |
yeah, that probably won't help in this case. |
03932aa
to
89771f5
Compare
@ferventcoder any chance of getting another review on this PR? so it hopefully can be merged.... |
89771f5
to
f1d7368
Compare
@ferventcoder I know I'm nagging, but is this PR acceptable as it currently stands? |
Why do we need it since its added to chocolaty ? If you think older versions of choco, we can add dependency to chocolatey 0.10.5 instead of this ? |
@majkinetor while that is certainly possible, I believe there should be an option to keep backwards compatibility while still using new functions. Hence why this PR, as well as it was started before it was added to choco. Like what is done with the |
Why promote bad behavior (keeping the old choco version) ? This way you force users to transparently update the choco by putting it as dependency. |
…lateyInstallPackage This wrapper makes it easier to embedd both 32-bit and 64-bit installers inside a package, extracting the needed check to decide which installer is meant to be run.
f1d7368
to
821d1e1
Compare
I'm closing this now, as there seem to be no interest in it. |
Apologies I didn't get back to this. Getting the functionality working properly with the same name was my biggest concern. |
I understand that, unfortunately I wasn't able to get it to work with the methods you suggested. However, I've dropped trying to get this into the extension. I haven't removed the branch though, as I'm hoping someone will pick it up and continue the work... /CC @ferventcoder |
The idea behind it wasn't really meant as to promote bad behavior, but rather to provide an alternative to users that can't update chocolatey (be it because of a bug, or company policy or something else). |
If this happens @ferventcoder , it probably shouldn't. Did you try it ? Chocolatey is added as first package during installation, it doesn't make sense it gets ever uninstalled. |
This wrapper makes it easier to embedd both 32-bit and 64-bit
installers inside a package, extracting the needed check
to decide which installer is meant to be run.
I plan to make the same for
Get-ChocolateyUnzip
, but want to see if I'm moving in the right direction first.