History and purpose: how this is project came to be, and what it's for about commandlineutils HOT 9 CLOSED

I'd be very interested to see an official response to dotnet/corefxlab#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...

from commandlineutils.

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?

from commandlineutils.

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?

from commandlineutils.

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:

• https://github.com/gsscoder/commandline
• https://github.com/dotnet/CliCommandLineParser
• https://github.com/dotnet/corefxlab/tree/master/src/System.CommandLine
• https://github.com/dotnet/buildtools/blob/master/src/common/CommandLine.cs

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?

from commandlineutils.

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

from commandlineutils.

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

from commandlineutils.

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

from commandlineutils.

I suspect what you see in 1311 is as official as it will get.

from commandlineutils.

@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

from commandlineutils.