Show only latest VS, VC prompts by default

[heaths]

Summary of the Pull Request

Similar to vswhere -latest, show only the latest Visual Studio command prompts / developer PowerShell. This was tested by deleting the local package state and testing against fresh state with both VS2019 and VS2022 Preview installed, and indeed VS2022 Preview (both cmd and powershell) show. The other profiles were generated but hidden by default.

References

Modification of PR #7774

PR Checklist

• Closes Visual Studio Generator should probably prefer x64 tools when available #11307
• CLA signed. If not, go over here and sign the CLA
• Tests added/passed
• Documentation updated. If checked, please file a pull request on our docs repo and link it here: #xxx
• Schema updated.
• I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Detailed Description of the Pull Request / Additional comments

The sort algorithm is the same basic algorithm I used in https://github.com/microsoft/vswhere. It sorts first by installation version with a secondary sort based on the install date in case the installation versions are the same.

Validation Steps Performed

With both VS2019 and VS2022 Preview installed, I made sure the initial state was expected, and tried different combinations of hiding and unhiding generated entries, and restarted Terminal to make sure my settings "stuck".

[heaths]

@zadjii-msft this PR initially has the changes to only show the latest using the same basic algorithm as vswhere -latest.

It seems the other part of the ask here is to also generate profiles similar to what's in the Start menu, which we could do based on the architecture of the WT process running:

Wanted to at least get this "half" of the PR up since it's my first code change to this repo (I added the initial .vsconfig way back in #907).

[heaths]

To note, those shortcuts are only installed if VC is installed, which means I have to either add a workload check, which will load a significantly large file and parse through it (the COM server will), or a file path check which will probably be faster. I'll need to spend a little time investigating when those variations were added (e.g. 15.0, or later in 15.3 or something) and whether the paths are consistent or need varying like @trippwill did for the PowerShell prompt since the path to the module changed.

If another preview is coming up soon, it might be worth taking this PR as-is to avoid spamming anyone with numerous VS installs, and I can open up another PR to continue investigating the aforementioned conditions.

[zadjii-msft]

I appreciate taking the effort to break changes into smaller, more atomic pieces. I think we're targeting early Oct for the next release so we've still got time to iterate here, but you're right that this feels like something more easily digestible.

[github-actions]

@check-spelling-bot Report

Unrecognized words, please review:

• IVisual
• vcvars
• vcvarsamd
• vcvarsx

Previously acknowledged words that are now absent

carlos dpg sid SPACEBAR Unregister xIcon yIcon zamora

To accept these unrecognized words as correct (and remove the previously acknowledged and now absent words), run the following commands

... in a clone of the git@github.com:heaths/terminal.git repository
on the issue11307 branch:

update_files() {
perl -e '
my @expect_files=qw('".github/actions/spelling/expect/alphabet.txt
.github/actions/spelling/expect/expect.txt
.github/actions/spelling/expect/web.txt"');
@ARGV=@expect_files;
my @stale=qw('"$patch_remove"');
my $re=join "|", @stale;
my $suffix=".".time();
my $previous="";
sub maybe_unlink { unlink($_[0]) if $_[0]; }
while (<>) {
if ($ARGV ne $old_argv) { maybe_unlink($previous); $previous="$ARGV$suffix"; rename($ARGV, $previous); open(ARGV_OUT, ">$ARGV"); select(ARGV_OUT); $old_argv = $ARGV; }
next if /^(?:$re)(?:(?:\r|\n)*$| .*)/; print;
}; maybe_unlink($previous);'
perl -e '
my $new_expect_file=".github/actions/spelling/expect/2be394f421b9b23a15e5573fb02b9c7a25768941.txt";
use File::Path qw(make_path);
use File::Basename qw(dirname);
make_path (dirname($new_expect_file));
open FILE, q{<}, $new_expect_file; chomp(my @words = <FILE>); close FILE;
my @add=qw('"$patch_add"');
my %items; @items{@words} = @words x (1); @items{@add} = @add x (1);
@words = sort {lc($a)."-".$a cmp lc($b)."-".$b} keys %items;
open FILE, q{>}, $new_expect_file; for my $word (@words) { print FILE "$word\n" if $word =~ /\w/; };
close FILE;
system("git", "add", $new_expect_file);
'
}

comment_json=$(mktemp)
curl -L -s -S \
  --header "Content-Type: application/json" \
  "https://api.github.com/repos/microsoft/terminal/issues/comments/927257596" > "$comment_json"
comment_body=$(mktemp)
jq -r .body < "$comment_json" > $comment_body
rm $comment_json

patch_remove=$(perl -ne 'next unless s{^</summary>(.*)</details>$}{$1}; print' < "$comment_body")
  

patch_add=$(perl -e '$/=undef;
$_=<>;
s{<details>.*}{}s;
s{^#.*}{};
s{\n##.*}{};
s{(?:^|\n)\s*\*}{}g;
s{\s+}{ }g;
print' < "$comment_body")
  
update_files
rm $comment_body
git add -u

✏️ Contributor please read this

By default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later.

⚠️ The command is written for posix shells. You can copy the contents of each perl command excluding the outer ' marks and dropping any '"/"' quotation mark pairs into a file and then run perl file.pl from the root of the repository to run the code. Alternatively, you can manually insert the items...

If the listed items are:

• ... misspelled, then please correct them instead of using the command.
• ... names, please add them to .github/actions/spelling/allow/names.txt.
• ... APIs, you can add them to a file in .github/actions/spelling/allow/.
• ... just things you're using, please add them to an appropriate file in .github/actions/spelling/expect/.
• ... tokens you only need in one place and shouldn't generally be used, you can add an item in an appropriate file in .github/actions/spelling/patterns/.

See the README.md in each directory for more information.

🔬 You can test your commits without appending to a PR by creating a new branch with that extra change and pushing it to your fork. The check-spelling action will run in response to your push -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. 😉

🗜️ If you see a bunch of garbage

If it relates to a ...

well-formed pattern

See if there's a pattern that would match it.

If not, try writing one and adding it to a patterns/{file}.txt.

Patterns are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your lines.

Note that patterns can't match multiline strings.

binary-ish string

Please add a file path to the excludes.txt file instead of just accepting the garbage.

File paths are Perl 5 Regular Expressions - you can test yours before committing to verify it will match your files.

^ refers to the file's path from the root of the repository, so ^README\.md$ would exclude README.md (on whichever branch you're using).

[heaths]

As discussed, only the latest and processor architecture-matching native tools environment (if VC++ is installed) are shown by default:

[zadjii-msft]

Team discussion: Yea we're pretty cool with this, and the fact that you can mark generated profiles as hidden by default is really cool. We'll try and get this in for 1.12 ☺️

[heaths]

If 1.11 is coming up, note that while the profile GUIDs shouldn't have changed from what @trippwill wrote, the namespace did since there's a single generator. Not sure if that's going to pose a migration problem.

That said, if there's time, I think we should at least take the sorting / hiding of all but the latest VS and can pull in the VC later. I could fairly easily remove the VC detection if you wanted to preview that longer and get feedback. With VS2022 coming out soon, more people will have multiple VSes installed (at least for a little while, based on past telemetry) so there will be at least 4 new entries all for VS. I worried about a backlash because of "spam".

[zadjii-msft]

Oh, I don't think we'll have any troubles merging this for the next release, we still have a little under 2 weeks so that's plenty of time

[heaths]

Isn't the original code already in 1.11 preview and getting close to shipping? (Not trying to sound impatient, mainly concerned about compatibility/migration woes, and sudden showing "too many" VS prompts.)

[zadjii-msft]

@heaths I don't believe so, #7774 only merged on the 15th and 1.11 preview came out on August 31st

[heaths]

Okay, cool. 👍 @bitcrazed made me think otherwise with the mention it was in Windows Terminal Preview.

[zadjii-msft]

Yea I'm cool with this. I like that we're combining this into one namespace, that makes a lot of sense.

[ghost]

Hello @zadjii-msft!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[LuanVSO]

could/should it also prefer powershell 7 for devshell?

[lhecker]

@LuanVSO Totally! If you don't mind, could you open a feature request issue for this?

[DHowett]

Sorry, I'm just coming back from vacation and doing post-mortem PRs.

I read over the body of the PR and the committed changes, and I can't tell why so much code changed. What else happened here? 😄

[heaths]

I refactored into a single discoverer because the existing ones were coded to generate a single profile per VS version. The VC cmd shell were to generate 1 or 4 depending on chip. Once I refactored, the inheritance model of the old generates was unnecessary and I was able to remove some otherwise unnecessary code. No point keeping it around to maintain.

[DHowett]

Love it! Thank you