Automatically provide global using for Spectre.Console

[kzu]

It's (almost?) sure that someone referencing the package will right-away use its provided types.

With the new C# 10 global usings feature, it would be great if referencing the package automatically provided such global usings, so that a simple console top-level program could right-away be just:

AnsiConsole.WriteLine("Hello World!");

No added usings needed.

---

Please upvote :+1: this issue if you are interested in it.

[phil-scott-78]

I'm a little antsy about enabling this for people automatically. I always kinda feel when people add our package we are a guest in their solution, and turning this on feels like we are putting our feet up on the table uninvited.

[bddckr]

My suggestions:

1. Wait - implicit global usings are getting changed to be opt-in rather than opt-out: https://github.com/dotnet/sdk/issues/19521
2. Once the above is done, follow whatever approach they are taking to make it opt-in. The last change did by conditionalizing the ItemGroup: https://github.com/dotnet/sdk/pull/19599/files#diff-96d423b08310b8431268198a954468fb9ca7f757d78aa38ae8c9bf3aa1bb6c20R23

Even then I agree with Phil, but I feel like that is true even with the suggested opt-in changes by the .NET teams due to the fact that the user has no easy way to figure out which usings a specific package has added. Sure, we can Remove them easily, but that might become a game of Whack-a-mole, especially as package updates might change their added usings.

[kzu]

In my humble opinion as a fairly heavy user of this project, I've never added it to any project where I didn't immediately added it as a using. Its types are (mostly? All?) Ansi* and never found any conflicts with any other types (that I commonly use at least).

The argument might apply if you're, say, Newtonsoft.Json, Automapper or some other general purpose library. But this project is sharply focused on ONE use case: the console uex for a project. It would be like creating a WPF or Xamarin.Forms project and assuming you might not want to import the default namespaces. Doesn't make a lot of sense to me 🤔

[phil-scott-78]

For small projects, sure. But of anything with any real meat we'd be bringing in a bunch of stuff in that namespace with names like Color, Decoration, Profile, and Capabilities project wide. And for many console applications only a handful of classes concern themselves with the reading and writing of the output, so these could easily start getting in the way. And that assumes we are the only nuget package that thinks we deserve an automatic global import. If this becomes a trend very quickly things start getting weird for consumers, and frankly I don't want to be leading that charge :-)

Don't get me wrong, it's a feature I'm not against. And I've already begun investigating making static global usings better for a later version. I just want to make sure that when our project is added that we play nice in our user's projects

[kzu]

Any non-trivial CLI "uex" will likely share quite a bit of code with other "UIs" and I seriously doubt in that case, all the shared code will live in a console project.

In my experience building dotnet global tools, shared code does not have a reference to any presentation library (console or otherwise).

Advanced users can always remove the added using anyway. What's important IMO is to make the newcomer's experience as simple and straightforward as possible.

Advanced users will surely quickly understand and leverage global usings on a regular basis. They shouldn't be the main concern as long as you don't make their life miserable.

[patriksvensson]

While I appreciate the PR you sent for this, I'm a bit on the fence about this. Like @phil-scott-78 said, we would be bringing in a lot of generic-sounding things, not only the AnsiConsole stuff. I could personally consider adding something like this if it was opt-in by an MSBuild flag.