Add chocolatey installation method #2852

@mkevenaar commented on GitHub (Jul 20, 2019):

@onomatopellan thanks, that will be fixed soon! I need to fix the check in the package, but that will be done for the next release

@mkevenaar commented on GitHub (Jul 20, 2019): @onomatopellan thanks, that will be fixed soon! I need to fix the check in the package, but that will be done for the next release

claunia commented

https://chocolatey.org/packages/microsoft-windows-terminal/0.2.1831.001

@mkevenaar commented on GitHub (Jul 20, 2019):

A new package has been pushed to @chocolatey, Automatic verification tests have been chaged as well.

The check is corrected here: 64c63a10d7 (diff-abcdb2dbc330c2b660ed5685c5efd623R12)

@mkevenaar commented on GitHub (Jul 20, 2019): A new package has been pushed to @chocolatey, Automatic verification tests have been chaged as well. https://chocolatey.org/packages/microsoft-windows-terminal/0.2.1831.001 The check is corrected here: https://github.com/mkevenaar/chocolatey-packages/commit/64c63a10d7f9f09cf56ea690918b97e5e99547d6#diff-abcdb2dbc330c2b660ed5685c5efd623R12

claunia commented

@gep13 commented on GitHub (Jul 20, 2019):

@onomatopellan I have updated the verification exemption message to reflect the correct OS and build version requirement for this package.

@gep13 commented on GitHub (Jul 20, 2019): @onomatopellan I have updated the verification exemption message to reflect the correct OS and build version requirement for this package.

claunia commented

@WSLUser commented on GitHub (Jul 22, 2019):

@mkevenaar Please see https://github.com/microsoft/terminal/issues/1944 as a related discussion.

@WSLUser commented on GitHub (Jul 22, 2019): @mkevenaar Please see https://github.com/microsoft/terminal/issues/1944 as a related discussion.

claunia commented

@WSLUser commented on GitHub (Jul 22, 2019):

Also, in order to build Windows Terminal, I believe the requirements stated above are good but there are a few PRs that enable all Windows 10 as well as Win8.1 and Win7 to run Windows Terminal. The screenshot in this PR: https://github.com/microsoft/terminal/pull/1274 specifically shows it is capable of running. With how much success I'm not sure but I'd make it available if possible down to Win7. I have a VM I've been itching to test it on but I've had build failures recently due to some env var issues on my local win 10 machine.

Edit: I've looked at your package and see you're using the Release page. Do you think you could update to use the latest commit? This would enable the Win7+ scenario.

@WSLUser commented on GitHub (Jul 22, 2019): Also, in order to _**build**_ Windows Terminal, I believe the requirements stated above are good but there are a few PRs that enable all Windows 10 as well as Win8.1 and Win7 to **_run_** Windows Terminal. The screenshot in this PR: https://github.com/microsoft/terminal/pull/1274 specifically shows it is capable of running. With how much success I'm not sure but I'd make it available if possible down to Win7. I have a VM I've been itching to test it on but I've had build failures recently due to some env var issues on my local win 10 machine. Edit: I've looked at your package and see you're using the Release page. Do you think you could update to use the latest commit? This would enable the Win7+ scenario.

claunia commented

@mkevenaar commented on GitHub (Jul 22, 2019):

@WSLUser I will not build a release my self and push that to Chocolatey. When a official build is released, it will be picked up automagically.

@mkevenaar commented on GitHub (Jul 22, 2019): @WSLUser I will not build a release my self and push that to Chocolatey. When a official build is released, it will be picked up automagically.

claunia commented

@miniksa commented on GitHub (Jul 23, 2019):

Also, in order to build Windows Terminal, I believe the requirements stated above are good but there are a few PRs that enable all Windows 10 as well as Win8.1 and Win7 to run Windows Terminal. The screenshot in this PR: #1274 specifically shows it is capable of running. With how much success I'm not sure but I'd make it available if possible down to Win7. I have a VM I've been itching to test it on but I've had build failures recently due to some env var issues on my local win 10 machine.

Edit: I've looked at your package and see you're using the Release page. Do you think you could update to use the latest commit? This would enable the Win7+ scenario.

The linked PR specifically allows the DX Rendering Component to run down to Win7.

It does not enable the entire Terminal project to run down to Win7.

@miniksa commented on GitHub (Jul 23, 2019): > > > Also, in order to _**build**_ Windows Terminal, I believe the requirements stated above are good but there are a few PRs that enable all Windows 10 as well as Win8.1 and Win7 to **_run_** Windows Terminal. The screenshot in this PR: #1274 specifically shows it is capable of running. With how much success I'm not sure but I'd make it available if possible down to Win7. I have a VM I've been itching to test it on but I've had build failures recently due to some env var issues on my local win 10 machine. > > Edit: I've looked at your package and see you're using the Release page. Do you think you could update to use the latest commit? This would enable the Win7+ scenario. The linked PR specifically allows the DX Rendering Component to run down to Win7. It does not enable the entire Terminal project to run down to Win7.

claunia commented

@WSLUser commented on GitHub (Jul 24, 2019):

Yes, I would like to be able to test it out though and determine what’s missing.

@WSLUser commented on GitHub (Jul 24, 2019): Yes, I would like to be able to test it out though and determine what’s missing.

claunia commented

@zadjii-msft commented on GitHub (Jul 24, 2019):

What's going to be missing to enable the terminal on Win7:

You'll need conpty to be able to serve as the console API server on windows 7. You'd have to take the conhost.exe and bring it with you to be able to run on Windows 7.
Conhost.exe was changed for Windows 8 to use condrv to handle console API calls, instead of whatever it was using before. So if you wanted to run conhost on Windows 7, you'll need to update it to be able to handle the windows 7 style connection.
You'll need XAML Islands ported to windows 7 to be able to host our UI
You'll need some appx infrastructure to be able to install the .msix on Windows 7. I don't believe that infrastructure has been brought downlevel.
You'd also need to bring SxS WinRT activation downlevel to be able to support running the terminal as administrator.

1 and 2 might be possible by changes here in this repo, but the remainder are all OS changes, and I can't imagine they'd be possible.

There might also be others, those are just off the top of my head.

@zadjii-msft commented on GitHub (Jul 24, 2019): What's going to be missing to enable the terminal on Win7: * [ ] You'll need conpty to be able to serve as the console API server on windows 7. You'd have to take the conhost.exe and bring it with you to be able to run on Windows 7. * [ ] Conhost.exe was changed for Windows 8 to use condrv to handle console API calls, instead of _whatever it was using before_. So if you wanted to run conhost on Windows 7, you'll need to update it to be able to handle the windows 7 style connection. * [ ] You'll need XAML Islands ported to windows 7 to be able to host our UI * [ ] You'll need some appx infrastructure to be able to install the .msix on Windows 7. I don't believe that infrastructure has been brought downlevel. * [ ] You'd also need to bring SxS WinRT activation downlevel to be able to support running the terminal as administrator. 1 and 2 might be possible by changes here in this repo, but the remainder are all OS changes, and I can't imagine they'd be possible. There might also be others, those are just off the top of my head.

claunia commented

@mkevenaar commented on GitHub (Jul 24, 2019):

@zadjii-msft I think that would deserve it’s own issue. I opened this issue with an request to add the Chocolatey installation to the documentation.

@mkevenaar commented on GitHub (Jul 24, 2019): @zadjii-msft I think that would deserve it’s own issue. I opened this issue with an request to add the Chocolatey installation to the documentation.

claunia commented

@WSLUser commented on GitHub (Jul 24, 2019):

Yes that is separate. I apologize for letting this issue go off topic.

You'll need some appx infrastructure to be able to install the .msix on Windows 7. I don't believe that infrastructure has been brought downlevel.

This has been done for some time now. For proof, here’s one of several PRs that were merged awhile ago changing references: https://github.com/microsoft/msix-packaging/pull/100

@WSLUser commented on GitHub (Jul 24, 2019): Yes that is separate. I apologize for letting this issue go off topic. > You'll need some appx infrastructure to be able to install the .msix on Windows 7. I don't believe that infrastructure has been brought downlevel. This has been done for some time now. For proof, here’s one of several PRs that were merged awhile ago changing references: https://github.com/microsoft/msix-packaging/pull/100

claunia commented

@WSLUser commented on GitHub (Jul 24, 2019):

Going to shift to a new issue so anybody that wants to speak up about it can do so there instead of this issue.

@WSLUser commented on GitHub (Jul 24, 2019): Going to shift to a new issue so anybody that wants to speak up about it can do so there instead of this issue.

claunia commented

@DHowett-MSFT commented on GitHub (Jul 24, 2019):

Just so you know, I am going to close with prejudice any issue that says "please support windows 7."

@DHowett-MSFT commented on GitHub (Jul 24, 2019): Just so you know, I _am_ going to close with prejudice any issue that says "please support windows 7."

claunia commented

@WSLUser commented on GitHub (Jul 24, 2019):

Indeed, should there not be an issue for someone outside the team willing to make the necessary changes? This is open-source project afterall. Plus the alternative to WinRT is WPF, which there is a pending PR for…

@WSLUser commented on GitHub (Jul 24, 2019): Indeed, should there not be an issue for someone outside the team willing to make the necessary changes? This is open-source project afterall. Plus the alternative to WinRT is WPF, which there is a [pending PR ](https://github.com/microsoft/terminal/pull/2004)for…

claunia commented

@DHowett-MSFT commented on GitHub (Jul 24, 2019):

It sounds great on paper, but even if the community contributes support for Windows 7 we need to carry on that maintenance burden forever. Any project is welcome to use the WPF control, once it lands, as part of a terminal. That's not necessarily the same as us supporting this specific terminal on Windows 7, but it does let folks leverage a lot of the work we've already done.

@DHowett-MSFT commented on GitHub (Jul 24, 2019): It sounds great on paper, but even if the community contributes support for Windows 7 _we_ need to carry on that maintenance burden forever. Any project is welcome to use the WPF control, once it lands, _as part of a terminal_. That's not necessarily the same as us supporting this specific terminal on Windows 7, but it does let folks leverage a lot of the work we've already done.

claunia commented

@mkevenaar commented on GitHub (Jul 24, 2019):

But the main question remains, are you willing to add the chocolatey installation method to your documentation?

@mkevenaar commented on GitHub (Jul 24, 2019): But the main question remains, are you willing to add the chocolatey installation method to your documentation?

claunia commented

@WSLUser commented on GitHub (Jul 24, 2019):

I’ve phrased a new issue not requesting support but better enable contributors to make it possible. I hope it can satisfy you.

@mkevenaar just throw a PR in to the main README.

@WSLUser commented on GitHub (Jul 24, 2019): I’ve phrased a new issue not requesting support but better enable contributors to make it possible. I hope it can satisfy you. @mkevenaar just throw a PR in to the main [README](https://github.com/microsoft/terminal/blob/master/README.md).

claunia commented

@miniksa commented on GitHub (Jul 24, 2019):

But the main question remains, are you willing to add the chocolatey installation method to your documentation?

I don't mind people getting their hands on the Windows Terminal by any means necessary.

But I also don't want to maintain this route. We've determined internally that at our current capacity and level-of-general-busyness that we can maintain the store distribution and posting the bundles to the Releases section.

If we start ramping up to weekly releases and someone comes here whining and moaning about the Chocolatey package being out of date or moans about the Chocolatey package not providing flight rings or wants us to build some auto-updater and delivery mechanism that is not the Store for servicing packages acquired a different way... then I will react very poorly and so will the rest of the team, probably.

I'm willing to entertain this on a trial basis. This isn't really a problem until it becomes a problem, but if it becomes a problem, we might have to revisit and pull the link and our blessing.

@DHowett-MSFT might have a more authoritative or contrary statement here though. And his word overrides mine here as he's the lead and gets to put his foot down on how we spend our time/money if he wants to.

@miniksa commented on GitHub (Jul 24, 2019): > But the main question remains, are you willing to add the chocolatey installation method to your documentation? I don't mind people getting their hands on the Windows Terminal by any means necessary. But I also don't want to maintain this route. We've determined internally that at our current capacity and level-of-general-busyness that we can maintain the store distribution and posting the bundles to the Releases section. If we start ramping up to weekly releases and someone comes here whining and moaning about the Chocolatey package being out of date or moans about the Chocolatey package not providing flight rings or wants us to build some auto-updater and delivery mechanism that is not the Store for servicing packages acquired a different way... then I will react very poorly and so will the rest of the team, probably. I'm willing to entertain this on a trial basis. This isn't really a problem until it becomes a problem, but if it becomes a problem, we might have to revisit and pull the link and our blessing. @DHowett-MSFT might have a more authoritative or contrary statement here though. And his word overrides mine here as he's the lead and gets to put his foot down on how we spend our time/money if he wants to.

claunia commented

@DHowett-MSFT commented on GitHub (Jul 24, 2019):

Yeah, I agree with all of that. 😄 Thanks!

@DHowett-MSFT commented on GitHub (Jul 24, 2019): Yeah, I agree with all of that. :smile: Thanks!

claunia commented

@gep13 commented on GitHub (Jul 24, 2019):

@miniksa @DHowett-MSFT I can confirm that @mkevenaar has set up this package as an AU package. This means that on a schedule, normally every 6 hours, the AU system will check for a new release of the msixbundle on GitHub. If it finds one, it will automatically generate a new Chocolatey package and push it to chocolatey.org. So as long as you and the team continue to push out the GitHub releases, then the Chocolatey side of things should also happen behind the scenes.

Please let me know if you have any questions.

@gep13 commented on GitHub (Jul 24, 2019): @miniksa @DHowett-MSFT I can confirm that @mkevenaar has set up this package as an AU package. This means that on a schedule, normally every 6 hours, the AU system will check for a new release of the msixbundle on GitHub. If it finds one, it will automatically generate a new Chocolatey package and push it to chocolatey.org. So as long as you and the team continue to push out the GitHub releases, then the Chocolatey side of things should also happen behind the scenes. Please let me know if you have any questions.

claunia commented

@miniksa commented on GitHub (Jul 24, 2019):

@miniksa Michael Niksa FTE @DHowett-MSFT Dustin Howett FTE I can confirm that @mkevenaar has set up this package as an AU package. This means that on a schedule, normally every 6 hours, the AU system will check for a new release of the msixbundle on GitHub. If it finds one, it will automatically generate a new Chocolatey package and push it to chocolatey.org. So as long as you and the team continue to push out the GitHub releases, then the Chocolatey side of things should also happen behind the scenes.

Please let me know if you have any questions.

Sounds good. If @mkevenaar sends the PR to add the link to the download part of our README, we'll accept it.

@miniksa commented on GitHub (Jul 24, 2019): > @miniksa Michael Niksa FTE @DHowett-MSFT Dustin Howett FTE I can confirm that @mkevenaar has set up this package as an AU package. This means that on a schedule, normally every 6 hours, the AU system will check for a new release of the msixbundle on GitHub. If it finds one, it will automatically generate a new Chocolatey package and push it to chocolatey.org. So as long as you and the team continue to push out the GitHub releases, then the Chocolatey side of things should also happen behind the scenes. > > Please let me know if you have any questions. Sounds good. If @mkevenaar sends the PR to add the link to the download part of our README, we'll accept it.

claunia commented