Clarify workload extension & platform restrictions #230
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
akoeplinger
reviewed
Jun 28, 2021
| | `extends` | string array | IDs of workloads whose packs should be included in this workload. | No | | ||
| | `platforms` | string array | Limits the workload and workloads that extend it to only be shown and installed on these host platforms. The strings are RIDs. | No | | ||
| | `extends` | string array | IDs of "base" workloads whose packs should be included in this workload. | No | | ||
| | `platforms` | string array | Restricts the workload and workloads that extend it to only be shown and installed on these host platforms. Inherits any restrictions imposed by base workloads. The strings are RIDs. | No | |
There was a problem hiding this comment.
does this only support portable RIDs or the full RID graph? e.g. osx-arm64 vs. osx.11.0-arm64
There was a problem hiding this comment.
It uses the chain in sdk/[VERSION]/NETCoreSdkRuntimeIdentifierChain.txt
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
akoeplinger
approved these changes
Jul 6, 2021
mhutch
added a commit
to mhutch/sdk
that referenced
this pull request
Jul 6, 2021
Platform checks should take restrictions on base workloads into account, as clarified in dotnet/designs#230. This means that the CLI can no longer trivially display the RIDs for the platforms on which the workloads are available. This could be added back in future using the RID graph to coalesce values, but would probably need additional work to ensure the values were user friendly. The resolver no longer returns workload definitions. The ensures clients use the resolver's APIs that work on the composed manifest data. Having all code that deals with manifest data direct in a central location helps keep behaviour consistent. It also does not be return abstract or empty workloads as these cannot be installed.
dsplaisted
approved these changes
Jul 6, 2021
| This is intended to be used to pre-download NuGet packages referenced by templates so that a workload can work offline after installation. It should be used sparingly i.e. only for NuGets referenced by the core templates with default or popular options. | ||
| Library packs are intended to be used to pre-download NuGet packages referenced by templates so that a workload can work offline after installation. Core workloads should include library packs very sparingly, if at all. Instead, it is strongly recommended that library packs are contained in separate workloads with the ID suffix `-offline-templates`. An offline template workload should only contain library packs referenced by templates, and should extend the workload that contains the templates. | ||
|
|
||
| > NOTE: SDK targets should **not** implicitly add `PackageReference` items. They should instead add `FrameworkReference` items that resolve to runtime packs and targeting packs. |
There was a problem hiding this comment.
I wouldn't phrase this as strongly, as I think .NET MAUI is going to have implicit PackageReference items.
There was a problem hiding this comment.
Right now the plan with dotnet/maui is to have some implicit PackageReference for things like:
- https://www.nuget.org/packages/Microsoft.ProjectReunion/
- https://www.nuget.org/packages/Xamarin.Google.Android.Material/
- https://www.nuget.org/packages/Xamarin.AndroidX.AppCompat/
- https://www.nuget.org/packages/Microsoft.Maui.Graphics/ - supposed to be a standalone NuGet
I agree with workloads should include library packs very sparingly, but it doesn't seem like dotnet/maui is doing that at the moment. dotnet/maui probably wouldn't be a good fit with the -offline-templates naming for these either, because they are dependencies for any app.
/cc @Redth
mhutch
added a commit
to mhutch/sdk
that referenced
this pull request
Jul 13, 2021
Platform checks should take restrictions on base workloads into account, as clarified in dotnet/designs#230. This means that the CLI can no longer trivially display the RIDs for the platforms on which the workloads are available. This could be added back in future using the RID graph to coalesce values, but would probably need additional work to ensure the values were user friendly. The resolver no longer returns workload definitions. The ensures clients use the resolver's APIs that work on the composed manifest data. Having all code that deals with manifest data direct in a central location helps keep behaviour consistent. It also does not be return abstract or empty workloads as these cannot be installed.
mhutch
added a commit
to mhutch/sdk
that referenced
this pull request
Jul 14, 2021
Platform checks should take restrictions on base workloads into account, as clarified in dotnet/designs#230. This means that the CLI can no longer trivially display the RIDs for the platforms on which the workloads are available. This could be added back in future using the RID graph to coalesce values, but would probably need additional work to ensure the values were user friendly. The resolver no longer returns workload definitions. The ensures clients use the resolver's APIs that work on the composed manifest data. Having all code that deals with manifest data direct in a central location helps keep behaviour consistent. It also does not be return abstract or empty workloads as these cannot be installed.
mhutch
added a commit
to mhutch/sdk
that referenced
this pull request
Jul 15, 2021
Platform checks should take restrictions on base workloads into account, as clarified in dotnet/designs#230. This means that the CLI can no longer trivially display the RIDs for the platforms on which the workloads are available. This could be added back in future using the RID graph to coalesce values, but would probably need additional work to ensure the values were user friendly. The resolver no longer returns workload definitions. The ensures clients use the resolver's APIs that work on the composed manifest data. Having all code that deals with manifest data direct in a central location helps keep behaviour consistent. It also does not be return abstract or empty workloads as these cannot be installed.
mhutch
added a commit
to mhutch/sdk
that referenced
this pull request
Jul 15, 2021
Platform checks should take restrictions on base workloads into account, as clarified in dotnet/designs#230. This means that the CLI can no longer trivially display the RIDs for the platforms on which the workloads are available. This could be added back in future using the RID graph to coalesce values, but would probably need additional work to ensure the values were user friendly. The resolver no longer returns workload definitions. The ensures clients use the resolver's APIs that work on the composed manifest data. Having all code that deals with manifest data direct in a central location helps keep behaviour consistent. It also does not be return abstract or empty workloads as these cannot be installed.
mhutch
added a commit
to mhutch/sdk
that referenced
this pull request
Jul 17, 2021
Platform checks should take restrictions on base workloads into account, as clarified in dotnet/designs#230. This means that the CLI can no longer trivially display the RIDs for the platforms on which the workloads are available. This could be added back in future using the RID graph to coalesce values, but would probably need additional work to ensure the values were user friendly. The resolver no longer returns workload definitions. The ensures clients use the resolver's APIs that work on the composed manifest data. Having all code that deals with manifest data direct in a central location helps keep behaviour consistent. It also does not be return abstract or empty workloads as these cannot be installed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Expand explanation of extending workloads and clarify how platform restrictions interact with it.