Move `RegisterWithDotnetSuggest` to the application framework layer and consider making it internal, as it will ideally be replaced eventually by intrinsic SDK or runtime support

[jonsequitur]

        // This feels... very specific.  I would hope that we expect this API set overall to live "forever" and I doubt that dotnet.exe will.
        // I recommend cutting it, or moving it to some library outside the main System.CommandLine library.
        public static CommandLineBuilder RegisterWithDotnetSuggest(this CommandLineBuilder builder);

[KalleOlaviNiemitalo]

Please ensure there is a way to prevent it from registering automatically if CommandLineBuilderExtensions.UseSuggestDirective is not called or CommandLineConfiguration.EnableDirectives is false.

[MichalStrehovsky]

At minimum, registering with dotnet-suggest should not be the default that one gets if they do new RootCommand().Invoke(args);. I was shocked to find out that this line will launch a process and write to the file system. The APIs should ideally follow the principles of least surprise: a general-purpose command line API should ideally not have default behaviors that are specific to writing .NET tools.

[jonsequitur]

The dotnet-suggest integration is sorely in need of redesign. We're planning to move it to the app framework layer, and it definitely shouldn't require starting a process, even as a one-time thing (as is currently the case).

Ideally, the design won't require registration at all, or registration would happen on dotnet tool install, so that for end users, completions just work for all .NET-based tools. We want this to be "free" for developers as well (including free of performance compromises) because otherwise, most people won't take the extra time to build it in, though it's clearly useful for users.

[KathleenDollard]

One of the challenging things here is that suggestions require registration somehow and that registration would ideally be at the control of the end user. Whether it is opt-in or opt-out, the using programmer is not the one with the strongest opinion on whether getting suggestions for CLI commands is worth the registration.

[MichalStrehovsky]

Writing to filesystem and launching processes behind the user's back is where I'd personally draw a line for providing conveniences. In the end the programmer is responsible for what their program is doing and no reasonable person would expect a parser to launch an arbitrary process named dotnet-suggest.

I actually checked with MSRC whether they consider it interesting and I shouldn't draw attention to it but they said it's fine.

[KalleOlaviNiemitalo]

Should System.CommandLine search for a dotnet-suggest executable in the current directory, though? It looks like System.Diagnostics.Process does that if dotnet-suggest does not exist in the application directory, as it probably won't. On Windows, users can suppress that via the NoDefaultCurrentDirectoryInExePath environment variable, but on Unix one cannot. https://github.com/dotnet/runtime/blob/af494f4060cdc03782d0b4cf68bf073a4d979260/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs#L715-L719

If that behaviour is undesired, then System.CommandLine could search PATH on its own and pass the result to Process.Start, although doing so would require knowing whether executables have an .exe extension.

[jonsequitur]

Should System.CommandLine search for a dotnet-suggest executable in the current directory, though?

It shouldn't search for dotnet-suggest at all.

The new registration behavior won't involve launching a process. This is a change that's been planned for a while now, for all of the reasons mentioned here.

The functionality for completion registration will also not be included in the core System.CommandLine library. One approach that's been discussed for years is to register during dotnet tool install. @baronfel

[KalleOlaviNiemitalo]

Are there more detailed plans about the completion registration yet? I would prefer that it not rely on dotnet tool install, as I'm using System.CommandLine in some tools that developers are expected to build from source and run in place.

I would also like to use System.CommandLine in tools that are deployed to a production system that will not have .NET SDK installed. Although I suppose such a computer won't have dotnet-suggest either, so suggestions cannot work anyway.

[jonsequitur]

There's been more discussion about how to improve the design but it's still somewhat high level while we work through the lower-level improvements.

We do want to get to a place where the SDK isn't required and where, for example, NativeAOT-compiled or even non-.NET CLI apps can participate. Generating app-specific scripts will be the ideal case for performance. Hooking into dotnet tool install was a suggestion aimed at improving the registration experience for SDK users, not a requirement for the completions feature all-up.

The current [suggest] directive-driven will in all likelihood remain in place as a fallback, needed due to the large number of different shell APIs and conventions.

[adamsitnik]

Fixed by #2099