Terminal: Add chocolatey installation method

[mkevenaar]

Hi,

I have created an @chocolatey package for Windows Terminal. Are you willing to add this installation method to your documentation?

Thanks,

Maurice

[onomatopellan]

Thanks! But it says it requires "at least Windows 10 version 1809/OS build 17763" and that's not correct. The Windows Terminal needs at least build 18362 (Windows 10 version 1903) or later.

[mkevenaar]

@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]

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

[gep13]

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

[WSLUser]

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

[WSLUser]

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.

[mkevenaar]

@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.

[miniksa]

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.

[WSLUser]

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

[zadjii-msft]

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.

[mkevenaar]

@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.

[WSLUser]

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]

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

[DHowett-MSFT]

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

[WSLUser]

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…

[DHowett-MSFT]

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.

[mkevenaar]

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

[WSLUser]

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.

[miniksa]

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.

[DHowett-MSFT]

Yeah, I agree with all of that. :smile: Thanks!

[gep13]

@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.

[miniksa]

@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.

[gep13]

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

This is great news!

[mkevenaar]

@miniksa @DHowett-MSFT I have submitted a PR for this #2084