Open baronfel opened 3 months ago
Thanks for writing this! I'd suggest considering dotnet workload list versions
instead of dotnet workload list sets
, avoiding "workload sets" as a user-facing term.
Looks great. Just a few thoughts on my end:
xcode@9.0
syntax seems like a great shorthand that could be a streamlined syntax if no parameter is provided for --version
and --component
.What is a reasonable place to store this data on the NuGet package metadata?
question still. It sounds like workload metadata would go into the release notes field? That doesn't seem ideal as release notes should be used for changes to the workload itself?
Now that we have workload sets, users have three questions about them that we can't easily answer:
We will provide CLI commands that enable users to learn the answers to all of those questions.
What workload set versions are available?
Workload sets are shipped as a specific NuGet package and are selected by users by version, either implicitly or explicitly. We should provide a command to list the top N versions of the workload set package available on the selected feeds so that users know what versions are available.
dotnet workload search versions
Microsoft.NET.Workloads.{SDKFeatureBand}
of the currently-used SDK--take
command to limit the number of versions returned (based on prior art fromdotnet package search --take
, I'm not personally a fan of this and would consider--count
).--format <table|json>
option and will emit the results as either a JSON array of strings or a terminal-formatted table using our existing helpersdotnet workload install --version
anddotnet workload update --version
for workload setsWhat's in workload set XYZ?
Users want to know what versions of the workloads are bundled in each workload set for a number of reasons. We'll tackle this in two parts:
dotnet workload search sets <workload set version>
--format <table|json>
option that will emit the results as either a JSON array of objects describing each workload in the workload set, or as a table using our existing helpersAs an example of what this could look like, let's take the existing output from
dotnet workload list
, which lists the versions of workloads that are installed locally. This output is from my local Windows desktop, which is not configured to use workload sets:The major difference that the proposed "what's in workload set X" command would have compared to this is:
What workload contains version X of component or workload Y?
AKA a reverse-lookup, inverting the previous command. Once we have the data to power the above command, we should be able to use it to look up the matching workload set version for a given workload version (e.g. Aspire 8.0.1).
dotnet workload search sets --component <component ID and version>
, where<component ID and version>
is a structure like<component@version>
- for exampleAspire@8.0.1
.dotnet workload search sets --component aspire@8.0.1 --component maui-android@17.2.1
--component
option easily as welldotnet workload search sets aspire@8.0.1 maui-android@17.2.1
dotnet workload search versions xcode@9.0
This question is the least fleshed-out but we hope this gives enough of an idea to have a discussion.
Automatically install a workload set that contains a given workload version
Building on the previous 3 commands, users should be able to do something like
dotnet workload install aspire@8.0.1 maui@46.8
and the tooling should find the workload set (or sets) that contains both of those and install that workload set. Potentially prompting the user to make a choice if multiple valid sets are found.Open questions
sets
but @dsplaisted's suggestion ofversions
is also very reasonable and has the upside of not introducing the workload sets concept to the CLI grammar or to users.<id>::<version>