Stateless VS command-line-api

After using stateless for three years, my conclusion is that I cannot imagine a scenario, where it makes sense to use it.

I'm playing around with this library for a medium sized state machine I'm setting up, and it has this functionality. I think explicit state machines are a good use-case for having an actual diagram, since they can take up enough space that it becomes hard to build a mental map from reading the code due to locality issues.

using System.CommandLine.Invocation; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.DependencyInjection.Extensions; namespace System.CommandLine.Builder; internal static class DependencyInjectionMiddleware { public static CommandLineBuilder UseDependencyInjection(this CommandLineBuilder builder, Action configureServices) { return UseDependencyInjection(builder, (_, services) => configureServices(services)); } // This overload allows you to conditionally register services based on the command line invocation context // in order to improve startup time when you have a lot of services to register. public static CommandLineBuilder UseDependencyInjection(this CommandLineBuilder builder, Action configureServices) { return builder.AddMiddleware(async (context, next) => { // Register our services in the modern Microsoft dependency injection container var services = new ServiceCollection(); configureServices(context, services); var uniqueServiceTypes = new HashSet(services.Select(x => x.ServiceType)); services.TryAddSingleton(context.Console); await using var serviceProvider = services.BuildServiceProvider(); // System.CommandLine's service provider is a "fake" implementation that relies on a dictionary of factories, // but we can still make sure here that "true" dependency-injected services are available from "context.BindingContext". // https://github.com/dotnet/command-line-api/blob/2.0.0-beta4.22272.1/src/System.CommandLine/Invocation/ServiceProvider.cs context.BindingContext.AddService(_ => serviceProvider); foreach (var serviceType in uniqueServiceTypes) { context.BindingContext.AddService(serviceType, _ => serviceProvider.GetRequiredService(serviceType)); // Enable support for "context.BindingContext.GetServices<>()" as in the modern dependency injection var enumerableServiceType = typeof(IEnumerable<>).MakeGenericType(serviceType); context.BindingContext.AddService(enumerableServiceType, _ => serviceProvider.GetServices(serviceType)); } await next(context); }); } }

command-line-api

This looks really nice.

I've been spending a lot of time with python lately because of new project work, I had never really used python before. It's been really cool to keep finding stuff like this.

The equivalent of something like in the .net world (eg https://github.com/dotnet/command-line-api) and even powershell modules (https://learn.microsoft.com/en-us/powershell/module/microsof...) have a steeper learning curve and take significantly MORE work to set up for the end-user.

https://github.com/dotnet/command-line-api is a library that facilitates making commandline executables with nice arguments and options. It's a little complicated but if you're going to pack in a lot of functionality, you need something like this.

if you're looking into command line utilities built in c#, you might want to check out System.CommandLine. You'll be able to build your comands in c#.

System.Commandline is my current favorite.

In the source of https://github.com/dotnet/command-line-api/tree/main/src/System.CommandLine there is a Command class which represents a invocation path for a command line program. There is a corresponding CommandExtensions class which is basically a set of extension methods for Command class. This library owns the Command class and yet extension methods are defined for it. What could be the reason for this decision when all the methods can be directly defined inside the command class?

Second, is what type "owns" the method. This is the crux of the matter. The library authors apparently decided that a Command should not be concerned with how a Command is invoked. If you look at the Command type, you see no Invoke method - at all. The library authors decided that a command should define what the command is but now how it's invoked. That responsibility is handled inside of the CommandExtensions class.