Closed natemcmaster closed 6 years ago
Just curious, have you looked at a couple other efforts that are trying to build out standard CLI parsing for .NET? Some of them are even being run as MS projects? Or do you just find you like the M.E.CLU approach the best?
Yeah, there are plenty of libraries already available for command-line parsing, including a draft of official support, aka System.CommandLine. This project started not as an attempt to replace those, but rather it was about making a community-driven fork of a library that has seen lots of adoption and that MS decided to drop. @ebekker did you have other efforts in mind?
Well I'm one of those that started to adopt M.E.CLU -- when I saw the Microsoft.Extensions
namespace I assumed it was an endorsement of sorts, similar to how .Logging
, .Configuration
and .DependencyInjection
are being treated in the .NET Core space.
But even before the announcement was made to discontinue support, I had already started looking at what everyone else was doing in the CLI parsing space, and I found a few that I started to play with:
I even tried to get some clarity on this from the powers that be but that only gave me more options :-)
Anyway, just curious what your take was on the landscape -- if you had played with others and actually settled on/preferred the model of M.E.CLU?
BTW, when I did initially decide to adopt M.E.CLU, while I like the overall API, I'm very much a model-driven and declarative-approach kinda guy, so I started to build such an optional layer atop CLU: https://github.com/zyborg/Zyborg.CLI
I've since stopped working on it, but if you pursue this reincarnation, I may get re-inspired...
If possible, I would like to see more effort put into the API in CoreFxLab.
https://github.com/dotnet/corefxlab/blob/master/src/System.CommandLine/README.md
@shaggygi -- maybe it's just me, but I wasn't too happy with the very explicit and mechanical approach they took, it didn't seem any better than what I used with Mono.Options (NDesk) for many, many years before .NET Core came around.
I'd be very interested to see an official response to https://github.com/dotnet/corefxlab/issues/1311.
Anyway, just curious what your take was on the landscape
My understanding of the landscape: https://imgs.xkcd.com/comics/standards.png
This is an important piece of System.CommandLine's readme:
The purpose of this library is to make command line tools first class by providing a command line parser. We've already made an attempt in 2009 but that wasn't a design we (or the community) was happy with.
I'm fairly new to .NET (i.e. only started working with it full time a few years ago), so I'm sure there is history that I've missed here. But it seems even the .NET team has tried to design a CLI parsing API, and found it difficult to satisfy everyone. M.E.CLU isn't exempt from this either.
That said, I'm hoping to carry on the work of building a solid CLI parsing command line. Maybe I should also write a roadmap...
I suspect what you see in 1311 is as official as it will get.
@natemcmaster funny image 😄
I honestly don't care which API is the winner. I just hope for one that gets some good features and backing from MS and the community. I just thought the one on CoreFxLabs would be the one that got the most love and eventually made it over to CoreFx like some of the other experimental APIs.
I'll keep an eye on your progress, as well.
Thanks
git mv {Microsoft => McMaster}.Extensions.CommandLineUtils
History
The ASP.NET Core team is in the business of producing a web framework, and not in producing .NET libraries in general. In the early days of what later became ASP.NET Core, Microsoft.Extensions.CommandLineUtils was created as a requirement of producing dnx and ASP.NET vNext. It was never intended to be the Microsoft-official way to write command line apps. After later refactoring of the architecture of dnx into dotnet, and reassignments of resources, the ASP.NET Core team no longer maintains much command-line code, so they decided to stop active development on their CommandLineUtils library. See https://github.com/aspnet/Common/issues/257.
What this is
Hence, I've forked the project. This project will maintain and improve upon the 1.0 and 1.1 versions of the library.
Fork is the operative word here. Not branch, not update, not replace.
Goals
Non-goal
Future
This repo is open to community contributions under the Apache 2.0 License. Please read the contributing guidelines, and tag me @natemcmaster in the pull-request.
Cheers, Nate. 🍻