natemcmaster / CommandLineUtils

Command line parsing and utilities for .NET
https://natemcmaster.github.io/CommandLineUtils/
Apache License 2.0
2.21k stars 254 forks source link

History and purpose: how this is project came to be, and what it's for #1

Closed natemcmaster closed 6 years ago

natemcmaster commented 7 years ago

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

ebekker commented 7 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?

natemcmaster commented 7 years ago

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?

ebekker commented 7 years ago

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?

ebekker commented 7 years ago

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

shaggygi commented 7 years ago

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

ebekker commented 7 years ago

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

natemcmaster commented 7 years ago

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

ebekker commented 7 years ago

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

shaggygi commented 7 years ago

@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