Today I get to announce Windows Package Manager 1.3 has been released. The team has been adding several enhancements to manifests to improve your package installation experience. We’ve enabled better package version reporting. A new setting allows verbose logs to be on by default. If you run
Some packages include documentation associated with a package version. You will now be able to see the documentation and an associated URL when you run
Most command-line packages require a terminal restart for the environment variables to be loaded. Some other packages have nuances related to what a user should understand before running them the first time. Installation notes will be displayed after the package is installed. We’ve also added arguments and settings to manage these notes. The default behavior is to display these notes. You can add “suppressInstallNotes” as a setting to prevent them from being displayed. You can also pass “–display-notes” or “–suppress-notes” to override settings.
Most .exe-based installers can provide custom responses for various failure scenarios. We’ve added an enhancement to provide not only a standard error message, but now a URL can also be included. We’re hoping this will help with troubleshooting why something didn’t go quite right. Manifest authors can add a “ReturnResponseURL” to the array of “InstallerReturnCode” values.
Note: The following example shows an error that was intentionally forced to occur.
The Windows Package Manager settings file is opened with your default JSON editor when you run
The Windows Package Manager was designed to behave in a predictable manner by default and give users the ability to customize those behaviors. The “suppressInstallNotes” setting was added for users who prefer not to see install notes included in manifests.
If you add “–verbose-logs” to any command, the Windows Package Manager adds additional information to the logs. This is often helpful for troubleshooting or digging deeper into exactly what the Windows Package Manager is doing. Users can now specify what level of logging they want. The “Logging” levels available are “verbose”, “info”, “warning”, “error”, and “critical”.
Some packages like the Microsoft .NET SDK display versions to users that are slightly different from their build numbers. Unfortunately, this caused confusion during the upgrade process, and it caused frustration for manifest authors. The Windows Package Manager will now honor the preferred version publishers would like to display, and the tooling will still be able to make the correct comparisons when determining if a newer version is available.
In the example below from Windows Apps & Features, you can see the Microsoft .NET Runtime packages and the Microsoft .NET SDK package versions displayed start with “6.0”. The but the Microsoft .NET SDK version below the display name starts with “6.3”. Manifests can now use the display version (“packageVersion” in the manifest) to show users what version is installed or which upgrade is available, but it can still use the build version (“displayVersion” manifest key from the registry and “AppsAndFeatures” from the manifest) for comparison.
Not all packages run natively on every architecture. Sometimes packages are run under emulation. We’ve updated
One of our most popular features is the customizable progress bar. Thanks to a community contribution, it just got better. Additional fine-grained blocks make that progress bar buttery smooth. If you didn’t know, you can customize your progress bar in settings. I use:
“visual”: {“progressBar”: “rainbow”}
Don’t worry, all the styles get the improved progress bar.
Is there a portable package you wish you could manage with the Windows Package Manager? These are essentially just executable programs that don’t have an installer. Maybe you would like to
Note: We’ve added Microsoft.NuGet to the repository so you can test this out. It will fail on Windows Package Manager versions lower than 1.3 as shown in the image below.
The Windows Package Manager Community Repository will begin accepting submissions for other portable packages after the upgrade has rolled out to a majority of the user base. This should take about one week. If you want to submit a pull request, go ahead. We’ll mark it as blocked for now, and as soon as we begin to accept portable packages, we will run them all through validation.
The post Windows Package Manager 1.3 appeared first on Windows Command Line.
Continue reading...
winget -–info the system architecture is now displayed. The progress bar was improved with more fine-grained blocks. And the Windows Package Manager now supports portable applications.Manifest Improvements
Display Documentation
Some packages include documentation associated with a package version. You will now be able to see the documentation and an associated URL when you run
winget show <package>.Installation Notes
Most command-line packages require a terminal restart for the environment variables to be loaded. Some other packages have nuances related to what a user should understand before running them the first time. Installation notes will be displayed after the package is installed. We’ve also added arguments and settings to manage these notes. The default behavior is to display these notes. You can add “suppressInstallNotes” as a setting to prevent them from being displayed. You can also pass “–display-notes” or “–suppress-notes” to override settings.
Expected Return Code Response URL
Most .exe-based installers can provide custom responses for various failure scenarios. We’ve added an enhancement to provide not only a standard error message, but now a URL can also be included. We’re hoping this will help with troubleshooting why something didn’t go quite right. Manifest authors can add a “ReturnResponseURL” to the array of “InstallerReturnCode” values.
Note: The following example shows an error that was intentionally forced to occur.
New Settings
The Windows Package Manager settings file is opened with your default JSON editor when you run
winget settings. If you happen to have Visual Studio Code installed and configured, you also get the benefit of the JSON schema for tooltips and code completion. If you don’t, you can run winget install vscode.Installation Notes
The Windows Package Manager was designed to behave in a predictable manner by default and give users the ability to customize those behaviors. The “suppressInstallNotes” setting was added for users who prefer not to see install notes included in manifests.
Verbose Logs
If you add “–verbose-logs” to any command, the Windows Package Manager adds additional information to the logs. This is often helpful for troubleshooting or digging deeper into exactly what the Windows Package Manager is doing. Users can now specify what level of logging they want. The “Logging” levels available are “verbose”, “info”, “warning”, “error”, and “critical”.
New Version Reporting
Some packages like the Microsoft .NET SDK display versions to users that are slightly different from their build numbers. Unfortunately, this caused confusion during the upgrade process, and it caused frustration for manifest authors. The Windows Package Manager will now honor the preferred version publishers would like to display, and the tooling will still be able to make the correct comparisons when determining if a newer version is available.
In the example below from Windows Apps & Features, you can see the Microsoft .NET Runtime packages and the Microsoft .NET SDK package versions displayed start with “6.0”. The but the Microsoft .NET SDK version below the display name starts with “6.3”. Manifests can now use the display version (“packageVersion” in the manifest) to show users what version is installed or which upgrade is available, but it can still use the build version (“displayVersion” manifest key from the registry and “AppsAndFeatures” from the manifest) for comparison.
Display System Architecture
Not all packages run natively on every architecture. Sometimes packages are run under emulation. We’ve updated
winget –info so it now displays the system architecture so you can quickly see what architecture your hardware has. This might help with troubleshooting why a particular package doesn’t have a matching installer, or why it might not behave exactly as you expect.An Even Better Progress Bar
One of our most popular features is the customizable progress bar. Thanks to a community contribution, it just got better. Additional fine-grained blocks make that progress bar buttery smooth. If you didn’t know, you can customize your progress bar in settings. I use:
“visual”: {“progressBar”: “rainbow”}
Don’t worry, all the styles get the improved progress bar.
Support for Portable Packages
Is there a portable package you wish you could manage with the Windows Package Manager? These are essentially just executable programs that don’t have an installer. Maybe you would like to
winget install Microsoft.NuGet or winget upgrade Microsoft.NuGet. We wanted to make sure you could manage these portable packages, so we add the appropriate entries in Windows Apps & Features when you install them. That allows you to see them as installed applications. You can even uninstall them from there if you don’t want to type winget uninstall Microsoft.NuGet.Note: We’ve added Microsoft.NuGet to the repository so you can test this out. It will fail on Windows Package Manager versions lower than 1.3 as shown in the image below.
Submitting Manifests for Portable Packages
The Windows Package Manager Community Repository will begin accepting submissions for other portable packages after the upgrade has rolled out to a majority of the user base. This should take about one week. If you want to submit a pull request, go ahead. We’ll mark it as blocked for now, and as soon as we begin to accept portable packages, we will run them all through validation.
The post Windows Package Manager 1.3 appeared first on Windows Command Line.
Continue reading...