cli
cli copied to clipboard
dapr
Add Dapr installer to winget
/area test-and-release
Describe the feature
Dapr should integrate with winget.
Will require an exe or msi installer for cli.
It can also potentially initialize dapr on the local system.
After chatting w/ @rynowak sounds like we can achieve this by pointing the yaml manifest to the Dapr CLI and adding an install/uninstall flag which adds/removes the Dapr cli to ProgramFiles/ AppData/TBD.
Additionally this install functionality can initialize dapr locally if we want it to
Reading the WinGet documentation it looks like we'll need an executable that:
- Copies the dapr cli binary into C:\dapr
- Adds this directory to the local user path
This can be either a standalone .exe named "dapr-installer.exe" or we can add a flag/feature to the existing dapr binary that causes it to copy itself and then update the path.
@artursouza thoughts?
@AaronCrawfis, you seem to be describing a msi installer.
WinGet accepts .msi installers. This can be achieved "easily" with https://wixtoolset.org
The msi installer must be configured to add the dapr.exe in the right folder and update the PATH env variable. The building of the .msi installer belongs to the dapr/cli repo IMO and should be one of the assets generated side-by-side with the executables. This would add value right away since Windows users can install by downloading the msi directly regardless of winget. This work by itself deserves a separate issue.
Then, we add a step to create a PR from DaprBot against the Winget repo adding/updating the yaml file in the end of a cli release. Alternatively, we could use a similar approach from our homebrew setup and have our own winget source repo. I would initially try to work with the official winget repo first, unless they are "too slow" to merge the PRs.
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.
Does winget provide some PowerShell install/uninstall scripting extension points? I believe Chocolately does.
winget doesn't support zip applications in 1.3 release. The supported file formats are EXE, INNO, NULLSOFT, MSI, APPX, MSIX, BURN, PORTABLE. Support for adding zip files is WIP: https://github.com/microsoft/winget-cli/issues/140. A preview release with the support for the same has been released: https://github.com/microsoft/winget-cli/releases/tag/v1.4.2011-preview. As per release notes:
Note: The [Windows Package Manager Community Repository](https://github.com/microsoft/winget-pkgs) does not accept zip applications. They will not be accepted until after 1.4 is Generally Available and has been rolled out to the majority of Windows systems via the automatic upgrade from the Microsoft Store. Users may test with local manifests.
Looks like this should be significantly easier now due to portable packages in winget 1.3
Portable packages as well require releases in one of the supported formats, e.g. kubectl, youtube-dl
Looks like this should be significantly easier now due to portable packages in winget 1.3
Portable packages as well require releases in one of the supported formats, e.g. kubectl, youtube-dl
Currently the windows Dapr CLI is zipped on its own, as such it could just as well be uploaded to the release page directly without compression thus making it possible to create an install manifest on the winget community repo.
winget doesn't support zip applications in 1.3 release. The supported file formats are EXE, INNO, NULLSOFT, MSI, APPX, MSIX, BURN, PORTABLE. Support for adding zip files is WIP: microsoft/winget-cli#140. A preview release with the support for the same has been released: https://github.com/microsoft/winget-cli/releases/tag/v1.4.2011-preview. As per release notes:
Note: The [Windows Package Manager Community Repository](https://github.com/microsoft/winget-pkgs) does not accept zip applications. They will not be accepted until after 1.4 is Generally Available and has been rolled out to the majority of Windows systems via the automatic upgrade from the Microsoft Store. Users may test with local manifests.
So possible solutions could be:
- Release .exe directly on the release page
- Have msi installers for cli and then use it for winget
- Wait till 1.4 GA, might be long
@artursouza thoughts?
@shivamkm07 Can you investigate on creating an MSI installer? I believe that is the way to move forward with this. Similarly we could have dmg package for macOS at a later point in time.
@shivamkm07 Can you investigate on creating an MSI installer? I believe that is the way to move forward with this. Similarly we could have dmg package for macOS at a later point in time.
Brew is usually the prefered way to grab most single file tools such as dapr, kubectl, istioctl, and many others in the CNCF for both Linux and Mac so DMG is likely unnecessary. Same thing could likely go for Windows, MSI is a bit excessive for a single executable when winget already supports that scenario.
Short version of the story is, if exe's were directly published onto the release page we could have a winget package released within a day.
Not sure why just publishing the exe is not favorite. Maybe because of filesize?
Out of curiosity, in the past you had these unzip bootstrap exe wrappers. I.e. still one exe but the payload gets decompressed when executed.
Has this been considered?
Op vr 26 aug. 2022 13:40 schreef Andrew Babbitt @.***>:
Short version of the story is, if exe's were directly published onto the release page we could have a winget package released within a day.
— Reply to this email directly, view it on GitHub https://github.com/dapr/cli/issues/424#issuecomment-1228388333, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPIYJEZ4MMMCDA74NR433LV3CUKFANCNFSM4PL5NIVA . You are receiving this because you commented.Message ID: @.***>
@shivamkm07 when should the associated PR be merged??
It can be merged only after:
- There is an existing manifest for dapr in winget: https://github.com/microsoft/winget-pkgs/pull/81209
- Fork of
winget-pkgsis created underdaprorg: https://github.com/dapr/community/issues/229
EDIT: An another PR in winget-pkgs need to be merged as well before this one: https://github.com/microsoft/winget-pkgs/pull/82429
Update: 1.9.0-rc.1 has been published to winget: https://github.com/microsoft/winget-pkgs/tree/master/manifests/d/Dapr/CLI/Preview/1.9.0-rc.1
As per discussion with maintainers of winget-pkgs (https://github.com/microsoft/winget-pkgs/pull/82508), rc releases would be released with PackageIdentifier Dapr.CLI.Preview while the stable ones would be released as Dapr.CLI. This is to avoid version conflicts between the stable and preview releases. The same has also been updated in the docs: https://github.com/dapr/docs/issues/2848. So the associated PR would have to wait till we have 1.9.0 stable release published in winget
The fork of winget-pkgs would be created automatically under https://github.com/dapr-bot when the workflow runs. @artursouza has verified DAPR_BOT_TOKEN has required permissions.
For the automation part, create a separate issue and tag it to 1.10 milestone ...
FYI 1.9.1 CLI is published to winget: https://github.com/microsoft/winget-pkgs/pull/83516
For the automation part, create a separate issue and tag it to 1.10 milestone ...
Created. This issue can be closed now.