Provide a way to limit which package installation instructions to display

[JeremySkinner]

Background

When viewing a package, various installation instructions are shown under different tabs. Not all of these are relevant to the package in question, which I believe can be confusing. For example, the Cake tab was recently added to the installation instructions tab for all packages (#8381).

This tab contains install instructions for installing the package as cake addins and cake tools, even when the package may not be compatible with these scenarios.

For example, the FluentValidation package is not a CLI tool, but clicking on the cake tab shows the #tool option:

I think this is confusing, as it implies you can install the package in this way when in reality this can't be done (or wouldn't be useful). Similarly, one of my other packages (FluentValidation.AspNetCore) is only available in web projects, so it doesn't really make sense to list cake as an installation option under this package (the Script / Interactive tab probably isn't relevant here too).

Proposal

I think it would be helpful if there was a way to limit which installation instructions are displayed based on the type of package that's being viewed. Ideally, it would be great if this could be done automatically based on context, but if that isn't possible then please consider giving package authors an opt-out feature (or maybe opt-in, with tags?), so we can choose to show/hide which install instructions are visible.

For example, this is already partially supported with .NET CLI tools - the ".NET Global Tool" and ".NET Local Tool" tabs aren't shown for regular packages, and the cake #addin option is hidden from within the Cake tab when viewing a .NET CLI tool.

Thanks for the consideration

//cc @joelverhagen

[patriksvensson]

"For example, it doesn't make sense for my package (FluentValidation), which is neither a Cake addin nor a CLI tool, but this is still shown:"

Not sure if you misunderstood what Cake does here, but it doesn't have to be a Cake addin to be used from a Cake script...

Your request reads to me like if I would have written: "I doesn't make sense for Spectre.Console to have the Paket tab since I'm not using it"

[augustoproiete]

Hey @JeremySkinner FluentValidation is absolutely a valid package for the Cake #addin directive and I use it in many projects.

It seems you're not familiar with what it means to load a NuGet Package via the #addin directive in Cake, but in summary it means:

1. Download the NuGet package
2. Expand it into the tools folder
3. Reference all the assemblies inside the package (if any)
4. Scan for any tailored Cake method aliases and make them available to the script (if any)

Therefore, any NuGet package that contains .NET assemblies are valid Cake #addin packages.

FluentValidation in particular can be very useful to perform validations in Cake scripts, and if you're interested I'm happy to send a PR to the FluentValidation repo with examples on how to leverage FluentValidation in Cake scripts! :cake:

[JeremySkinner]

Hi @augustoproiete thanks for the more detailed explanation.

One of the packages I mentioned (FluentValidation.AspNetCore) is a web-only AspNet package, it feels very confusing to have instructions for adding this as a Cake addin/tool (unless I'm missing something?). So for this package, I'd like to be able to hide the cake addin/tool instructions.

For the core library (FluentValidation), I've never actually seen this used as an addin in the wild, although I guess there could be people using it in this way, but as it's not a CLI tool, so at a minimum I'd like to be able to hide #tool instructions.

Edit For example, something similar is already done for .NET tools. .NET Tool packages have instructions for dotnet tool install, but packages which aren't .NET Tools don't have these instructions show up (and the other package manager instructions are automatically hidden), which helps keep the list of install instructions relevant. In this case, the Cake Addin option is actually already hidden.

I think a lot of packages would fall under at least one of these scenarios, and it'd be nice to streamline/tailor the install instructions as much as possible, within reason, to reduce confusion. I hope that clarifies my thinking a bit.

[augustoproiete]

Hey @JeremySkinner, fundamentally the Cake tab contains instructions on how to consume a package in a Cake script... If you're not a Cake user, you just ... don't ... click on that tab (?) :smile: :shrug:. I honestly don't see what's confusing about it.

By the same token, I don't use Paket, and I don't use C#/F# Interactive... So... I just don't click on any of these others tabs, ever... :smile:

Are you confused by the "Script & Interactive" tab as well? If FluentValidation.AspNetCore is a web-only AspNet package that should never be consumed by Cake, then it probably doesn't make sense to show the "Script & Interactive" tab either, right? :wink: Why are you making this about Cake only?

More importantly, at its core, Cake is a C# code runner, so there's nothing preventing one to spin up an ASP .NET web app from a Cake script if they wanted to, and use FluentValidation.AspNetCore there - not something I personally had the need yet :smile::smile: but there's nothing intrinsically "wrong" with it either... It's no different than hosting a web app in a Console app and use FluentValidation.AspNetCore there...

The point is that if someone wanted to use FluentValidation.AspNetCore in a Cake script, they absolutely could and it would work - even if it seems like an odd use-case to you or I.

That said, it would be great if package authors could include more metadata in the package that could allow for more tailored install instructions. I proposed some improvements to how PackageTypes work, which would open the door for these kind of experiences.

[JeremySkinner]

By the same token, I don't use Paket, and I don't use C#/F# Interactive... So... I just don't click on any of these others tabs, ever...

I don't really think the two are analogous. As a replacement package manager, it seems perfectly valid to have instructions for Paket available, even if you don't use it yourself.

I honestly don't see what's confusing about it

I believe it's confusing to have instructions for #tool when a package can't be used as a CLI tool. As I mentioned in my edit above, the gallery will automatically show/hide tabs for .NET Tools if they aren't relevant (including sections of the Cake tab). I'm asking if this feature that already exists could be extended. For example, here's a screenshot of the Powershell gobal tool, which has 3 tabs - CLI Global, CLI local and Cake. The other package managers are hidden:

Additionally, the Cake tab only shows #tool not #addin as it isn't relevant in this case:

Conversely, the CLI Global tool and CLI Local tool tabs are hidden for non-tool packages. So essentially I'd like to see an extension of this, where I can hide #tool for non CLI tools.

If FluentValidation.AspNetCore is a web-only AspNet package that should never be consumed by Cake, then it probably doesn't make sense to show the "Script & Interactive" tab either, right?

Yes, I think that would probably make sense too, in the same way that the Script/Interactive tab isn't shown for .NET CLI Tools, although I'd still take being able to hide #tool within the cake tab as a first step.

I proposed some improvements to how PackageTypes work, which would open the door for these kind of experiences.

I hadn't seen that before, but just had a read through it seems sensible - I like the idea of using PackageType, although what I was suggesting here was more just for display purposes on the gallery rather than affecting the CLI itself (so maybe expandin/limiting the use of tags would make it easier to implement?) but if it has the same end result where certain install instructions could be hidden, then I'd be happy 👍

[augustoproiete]

I believe it's confusing to have instructions for #tool when a package can't be used as a CLI tool.

Confusing to whom? The #tool instruction is only available on the Cake tab, which is targeted at Cake users who understand what #addin and #tool does, and when to choose one vs. the other...

the CLI Global tool and CLI Local tool tabs are hidden for non-tool packages

Correct. And that's driven by the PackageType in the metadata. My proposal would allow for additional metadata to be added, which could be used to drive the display of tabs as well as improve the discovery via search/filter.

what I was suggesting here was more just for display purposes on the gallery rather than affecting the CLI itself

It's the same purpose. The issue is that if you try to install a package that has a custom package type, it doesn't work today. You can read more about it in the links below:

• Consider using a custom package type for addins / modules
• PoC: Cake Extensions with Custom NuGet Package Types

I'm asking if this feature that already exists could be extended

I suggest you reword the issue title and description to reflect that, as it's not about Cake, but about providing more metadata in packages, to enable the NuGet Gallery to provide a more personalized experience on each package.

[JeremySkinner]

Sure, I've updated the issue title/desc to make it more generic

[nils-a]

In light of this discussion I am wondering whether it would be prudent to halt adding new tabs to the gallery (currently only #8511 as far as I can see..) until a good solution for handling "3rd party installation instructions" is provided.

[JonDouglas]

For those participating in this issue, please feel free to provide your thoughts regarding the addition of the NUKE tab for DotnetTool package types.

https://github.com/NuGet/Home/pull/10782

With respect to this current proposal, we would be more than welcoming of a proposal & community ideas/PRs/etc as to limiting package installation instructions.

https://github.com/NuGet/Home/tree/dev/meta#how-do-i-create-a-proposal

In the meantime, I have added a question to our upcoming NuGet.org survey to understand how people feel about the installation instructions & I can share that with everyone to provide some data. We also can help others understand what tabs are mostly used in addition here.

[matkoch]

@JonDouglas do you mean sharing the questions or sharing the results? In any case, I'd be interested in both :)

[JonDouglas]

@matkoch the latter. The survey is going up any day with the next deployment. Keep eyes out on NuGet.org for a banner!

[JonDouglas]

As promised, here are some preliminary results with ~300 responses.

Some of the free responses were around:

• "So long as there isn't ads, I don't care."
• "Each method has it's pros/cons."
• "Package Manager Console should be retired in favor of dotnet CLI."

For what it's worth, users also found "Instructions on installing a package in my project" (5.61 points) to be the highest satisfaction of various browsing options.

Let's continue the conversation about how we can make the options more precise or context aware. But as of right now, I think we shouldn't focus the conversation on too many or too little options given most people feel like there's enough or just don't care.