-
Notifications
You must be signed in to change notification settings - Fork 903
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
Add option to include install-args in the choco export
command
#2503
Comments
I investigated a little further and found that installation arguments are stored under the path: Therefore, to implement the proposed enhancement above to the Add-Type -AssemblyName System.Security
$entropyBytes = [System.Text.UTF8Encoding]::UTF8.GetBytes("Chocolatey")
Function Unprotect-Arguments {
param([string]$data)
$encryptedByteArray = [System.Convert]::FromBase64String($data)
$decryptedByteArray = [System.Security.Cryptography.ProtectedData]::Unprotect(
$encryptedByteArray,
$entropyBytes,
[System.Security.Cryptography.DataProtectionScope]::LocalMachine
)
return [System.Text.UTF8Encoding]::UTF8.GetString($decryptedByteArray)
}
Function Read-Arguments {
param([string]$packageName)
$directory = Get-ChildItem $env:ChocolateyInstall\.chocolatey -Directory -Filter "$packageName*" | `
Where-Object { $_.Name -match ("$packageName" + "\.[\d\.]+") } | Select-Object -Last 1
If (!($directory)) { return }
$argsFile = Join-Path $directory.fullname ".arguments"
If (Test-Path $argsFile) {
$argsData = Get-Content $argsFile
#Implicitly return result from Unprotect-Arguments
Unprotect-Arguments -data $argsData
}
}
Function Get-LocalPackageInfo {
& choco list -lo -r -y
}
Function Get-PackagesConfigBody($SaveArguments = $false) {
Get-LocalPackageInfo | ForEach-Object {
$packageName = $($_.SubString(0, $_.IndexOf("|")))
$line = ' <package id="' + $packageName + '" '
If ($SaveArguments) {
$line = $line + 'arguments="' + [System.Security.SecurityElement]::Escape($(Read-Arguments $packageName)) + '" '
}
$line = $line + '/>'
$line
}
}
Function Write-PackagesConfig($OutputFile, $SaveArguments = $false) {
$header = "<?xml version=`"1.0`" encoding=`"utf-8`"?>`n<packages>"
$footer = "</packages>"
$body = Get-PackagesConfigBody -SaveArguments $SaveArguments
Write-Output $header $body $footer | Out-File $OutputFile -Encoding ASCII
} and Write-PackagesConfig -OutputFile "choco-packages.config" -SaveArguments $true Resulting in XML like this: <?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="gh" arguments=" --cache-location="'C:\Users\jimmy\AppData\Local\Temp\chocolatey'"" />
<package id="git.install" arguments=" --cache-location="'C:\Users\jimmy\AppData\Local\Temp\chocolatey'" --install-arguments="'/COMPONENTS=icons,assoc,assoc_sh,autoupdate,windowsterminal,scalar'" --package-parameters="'/GitAndUnixToolsOnPath /NoAutoCrlf /WindowsTerminal /NoShellIntegration /NoGuiHereIntegration /NoShellHereIntegration /WindowsTerminalProfile /DefaultBranchName:main /Editor:VisualStudioCode'"" />
</packages> I tested this suite of functions locally and it worked exactly as mentioned above. Only potentially undesired aspect of the result is the Here's the script I used (as .txt due to GitHub limitations): |
Thanks for adding this issue, I had thought that there already was one posted for this feature request. This is definitely something that is planned to be added at some point, but it would be in the C# code, not in the PowerShell helper functions. See #1825 for where it would go in. Also, I discussed this with @gep13, and it is likely that the other install argument would be added with individual elements, instead of via a single |
Changes the set_package_config_for_upgrade method in the nuget service to be public so it can be accessed for purposes of parsing the saved arguments so they can be exported.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. This reuses the set_package_config_for_upgrade method in the NugetService to read and parse the saved arguments.
Will this add the state of pinned-packages like stated here?
Wasn't quite sure if I should open a new issue, but would find it quite useful to export this with choco export |
@Cyber1000 In this case, a new issue would be appropriate. The information about whether a package is pinned or not is stored separately from the saved arguments, and there is not currently a way to pin a package during installation (although I do have a PR open to add that). |
Changes the set_package_config_for_upgrade method in the nuget service to be public so it can be accessed for purposes of parsing the saved arguments so they can be exported.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. This reuses the set_package_config_for_upgrade method in the NugetService to read and parse the saved arguments.
Changes the set_package_config_for_upgrade method in the nuget service to be public so it can be accessed for purposes of parsing the saved arguments so they can be exported.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. This reuses the set_package_config_for_upgrade method in the NugetService to read and parse the saved arguments.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. This reuses the set_package_config_for_upgrade method in the NugetService to read and parse the saved arguments.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. This reuses the set_package_config_for_upgrade method in the NugetService to read and parse the saved arguments.
Changes the set_package_config_for_upgrade method in the nuget service to be public so it can be accessed for purposes of parsing the saved arguments so they can be exported.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. This reuses the set_package_config_for_upgrade method in the NugetService to read and parse the saved arguments.
Changes the set_package_config_for_upgrade method in the nuget service to be public so it can be accessed for purposes of parsing the saved arguments so they can be exported.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. This reuses the set_package_config_for_upgrade method in the NugetService to read and parse the saved arguments.
Changes the set_package_config_for_upgrade method in the nuget service to be public so it can be accessed for purposes of parsing the saved arguments so they can be exported.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. This reuses the set_package_config_for_upgrade method in the NugetService to read and parse the saved arguments.
Changes the set_package_config_for_upgrade method in the nuget service to be public so it can be accessed for purposes of parsing the saved arguments so they can be exported.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. This reuses the set_package_config_for_upgrade method in the NugetService to read and parse the saved arguments.
Changes the set_package_config_for_upgrade method in the nuget service to be public so it can be accessed for purposes of parsing the saved arguments so they can be exported.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. This reuses the set_package_config_for_upgrade method in the NugetService to read and parse the saved arguments.
Changes the set_package_config_for_upgrade method in the nuget service to be public so it can be accessed for purposes of parsing the saved arguments so they can be exported.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. This reuses the set_package_config_for_upgrade method in the NugetService to read and parse the saved arguments.
Instead of exporting via building an xml document manually, this creates a PackagesConfigFilePackageSetting and serializes that to create the xml document that is saved. This allows for usage of the same class as is used to read in packages.config files to export those files. The reason the "bool *Specified" members are added to the PackagesConfigFilePackageSetting class is so if an element is not set during export, it will not show up at all in the resulting serialized packages.config file.
Changes the set_package_config_for_upgrade method in the nuget service to be public so it can be accessed for purposes of parsing the saved arguments so they can be exported.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. It reuses the set_package_config_for_upgrade method in the NugetService to read and parse the remembered arguments.
Instead of exporting via building an xml document manually, this creates a PackagesConfigFilePackageSetting and serializes that to create the xml document that is saved. This allows for usage of the same class as is used to read in packages.config files to export those files. The reason the "bool *Specified" members are added to the PackagesConfigFilePackageSetting class is so if an element is not set during export, it will not show up at all in the resulting serialized packages.config file.
Changes the set_package_config_for_upgrade method in the nuget service to be public so it can be accessed for purposes of parsing the saved arguments so they can be exported.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. It reuses the set_package_config_for_upgrade method in the NugetService to read and parse the remembered arguments.
Instead of exporting via building an xml document manually, this creates a PackagesConfigFilePackageSetting and serializes that to create the xml document that is saved. This allows for usage of the same class as is used to read in packages.config files to export those files. The reason the "bool *Specified" members are added to the PackagesConfigFilePackageSetting class is so if an element is not set during export, it will not show up at all in the resulting serialized packages.config file.
Changes the set_package_config_for_upgrade method in the nuget service to be public so it can be accessed for purposes of parsing the saved arguments so they can be exported.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. It reuses the set_package_config_for_upgrade method in the NugetService to read and parse the remembered arguments.
Instead of exporting via building an xml document manually, this creates a PackagesConfigFilePackageSetting and serializes that to create the xml document that is saved. This allows for usage of the same class as is used to read in packages.config files to export those files. The reason the "bool *Specified" members are added to the PackagesConfigFilePackageSetting class is so if an element is not set during export, it will not show up at all in the resulting serialized packages.config file.
Changes the set_package_config_for_upgrade method in the nuget service to be public so it can be accessed for purposes of parsing the saved arguments so they can be exported.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. It reuses the set_package_config_for_upgrade method in the NugetService to read and parse the remembered arguments.
Instead of exporting via building an xml document manually, this creates a PackagesConfigFilePackageSetting and serializes that to create the xml document that is saved. This allows for usage of the same class as is used to read in packages.config files to export those files. The reason the various "Specified" members are added to the PackagesConfigFilePackageSetting class is so if an element is not set during export, it will not show up at all in the resulting serialized packages.config file.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. It reuses the GetPackageConfigFromRememberedArguments method in the NugetService to read and parse the remembered arguments.
👀 Any ETA on this feature getting merged? |
We hope to be bringing this in shortly. |
Instead of exporting via building an xml document manually, this creates a PackagesConfigFilePackageSetting and serializes that to create the xml document that is saved. This allows for usage of the same class as is used to read in packages.config files to export those files. The reason the various "Specified" members are added to the PackagesConfigFilePackageSetting class is so if an element is not set during export, it will not show up at all in the resulting serialized packages.config file.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. It reuses the GetPackageConfigFromRememberedArguments method in the NugetService to read and parse the remembered arguments.
Based on the changes in the associated PR's for this issue, I am going to have to bump this issue from the 2.3.0 release, and instead look at this again in the 2.4.0. The suggested changes to the INuGetService mean that this would essentially be a breaking change, that would need a corresponding change in the Chocolatey Licensed Extension, which we haven't planned to do at the minute. Instead of holding up the release of 2.3.0, we will look to do the work in this issue in a later release. Apologies for any inconvenience that this causes. |
Instead of exporting via building an xml document manually, this creates a PackagesConfigFilePackageSetting and serializes that to create the xml document that is saved. This allows for usage of the same class as is used to read in packages.config files to export those files. The reason the various "Specified" members are added to the PackagesConfigFilePackageSetting class is so if an element is not set during export, it will not show up at all in the resulting serialized packages.config file.
Instead of exporting via building an xml document manually, this creates a PackagesConfigFilePackageSetting and serializes that to create the xml document that is saved. This allows for usage of the same class as is used to read in packages.config files to export those files. The reason the various "Specified" members are added to the PackagesConfigFilePackageSetting class is so if an element is not set during export, it will not show up at all in the resulting serialized packages.config file. # Conflicts: # src/chocolatey/infrastructure.app/commands/ChocolateyExportCommand.cs
This adds the --include-remembered-arguments option which is used to export any remembered arguments. It reuses the GetPackageConfigFromRememberedArguments method in the NugetService to read and parse the remembered arguments.
Instead of exporting via building an xml document manually, this creates a PackagesConfigFilePackageSetting and serializes that to create the xml document that is saved. This allows for usage of the same class as is used to read in packages.config files to export those files. The reason the various "Specified" members are added to the PackagesConfigFilePackageSetting class is so if an element is not set during export, it will not show up at all in the resulting serialized packages.config file.
This adds the --include-remembered-arguments option which is used to export any remembered arguments. It reuses the GetPackageConfigFromRememberedArguments method in the NugetService to read and parse the remembered arguments.
It would be nice to have a flag similar to the
--include-version-numbers
flag for thechoco export
command but for including the installation arguments of a given package (assuming the user has the configurationuseRememberedArgumentsForUpgrades
enabled).Consider the following scenario where I install Git with various installation arguments applied:
then run
choco export -o="choco-packages.config"
, however the output XML only contains:whereas it could contain something like so:
This way, when I run
cinst -y choco-packages.config
it would apply the initial install-args and params for Git.Proposed Solution: add
--include-install-args
flag to thechoco export
command.The text was updated successfully, but these errors were encountered: