System.CommandLine vs. CommandLineUtils

[ebekker]

What's the relationship between the experimental System.CommandLine package in this repo and the Microsoft.Extensions.CommandLineUtils (found here) that's already been adopted and in use by the community?

It seems based on the goals of the package here, there is a lot of overlap between the conceptual models and API surface between the two. Are there use cases in that S.CL is trying to handle that are difficult or impossible to support in M.E.CLU?

[ebekker]

I saw this discussion about switching to using S.CL for the dotnet cli because there was some sentiment that it was better than M.E.CLU, but upon inspecting the CLI-handling code for the dotnet tool, it looks like that never actually happened.

[shaggygi]

I've also questioned something similar here.

While I haven't reviewed the repo, I have the impression there is also overlap with System.CommandLine.

It seems like it could utilize the System.CommandLine API to help improve so it would help others benefit when using in their CLI projects.

[ebekker]

@shaggygi -- great find! I had assumed from some earlier discussions and tickets I found elsewhere that the dotnet.exe tool was already making use of one of these two CLI parsers since early last year, but it looks like this race has 3 horses in it (at least!).

It would be nice to have some discussion about all these options and directions with "official folks" to see what everyone is thinking and where this will eventually land -- I'm not sure if such a forum exists.

[shaggygi]

@ebekker Maybe @KrzysztofCwalina or @terrajobst could provide some insight?

[am11]

+1 on reconciling. Only under dotnet and Microsoft orgs on GitHub, we can find multiple command line argument parsing implementations.

Copying my comment from #539 (comment) here:

With the stated benefits of System.CommandLine, will it make sense that the following repos take dependency on this assembly, so to test / evolve the implementation and overcome the shortcomings rapidly?

• https://github.com/dotnet/buildtools
• https://github.com/dotnet/codeformatter
• https://github.com/dotnet/cli
• https://github.com/dotnet/roslyn
• https://github.com/Microsoft/msbuild (this presents challenges of parsing BATCH style arguments /p:Configuration=Debug etc.)

Each one of these repos have their own ways of parsing command line arguments..

However, following repos are referencing System.CommandLine:

• https://github.com/dotnet/corert
• https://github.com/dotnet/core-setup
• https://github.com/dotnet/jitutils

[ebekker]

While there are still various other libraries that to consider as described by the previous post, at least to address my original question about M.E.CLU, it looks like that has been answered.

As described in this commit, M.E.CLU will not be further published as a stand-alone CLI parsing library, effectively deprecating it for community use.

[ebekker]

Looks like M.E.CLU has been reincarnated ...

[SidShetye]

So what happened here ... System.CommandLine seems to be now missing at dotnet/corefxlab as well as dotnet/corefx. Is it effectively dead leaving Microsoft.Extensions.CommandLineUtils (now here) as the only modern and maintained option?

Had hoped that the CLI parsing of dotnet was a reusable component but it appears to have included that code at a source-code level.

[ahsonkhan]

So what happened here ... System.CommandLine seems to be now missing at dotnet/corefxlab

That project was archived, see #2245 for context.

Specifically #2245 (comment):

We're still interested in addressing the scenario but based on feedback from both internal & external adopters we don't believe this particular API has a future. Stay tuned.

cc @terrajobst, @KathleenDollard