Make the Python pack optional on Linux #31761
Conversation
ghost
added
the
| @@ -48,7 +48,7 @@ | |||
| "alias-to": { | |||
| "win-x86": "Microsoft.NET.Runtime.Emscripten.2.0.12.Python.win-x86", | |||
| "win-x64": "Microsoft.NET.Runtime.Emscripten.2.0.12.Python.win-x64", | |||
| "linux-x64": "Microsoft.NET.Runtime.Emscripten.2.0.12.Python.linux-x64", | |||
| "linux-x64": null, | |||
There was a problem hiding this comment.
@dsplaisted / @mhutch we have this weird case where a workload pack is optional specifically on Linux. Importing the SDK based on the OS seems easy. However, I was trying to figure out what it would look like for the workload install tool. We want to signal to it, that there truly does not exist a version of this pack for this platform so ignore this entry.
Using a null appears to do the job. Thoughts on this? Other options I should consider?
There was a problem hiding this comment.
The idea with the null is to distinguish an unneeded pack from a completely unsupported arch?
There was a problem hiding this comment.
Yes. I was trying to extrapolate what the workload installer would do. Right now, the assumption is that in the absence of a alias for a platform, the SDK falls back to using the default ID: https://github.com/dotnet/sdk/blob/cf1db25c688a37cfad7adbfb608f1db930eb1412/src/Resolvers/Microsoft.NET.Sdk.WorkloadManifestReader/WorkloadResolver.cs#L143. Having an explicit null value would let you differentiate between, this pack does not exist for that platform vs use the "default" pack for this platform.
There was a problem hiding this comment.
I don't think we meant to support null here.
Is this pack optional on Linux or does it not exist at all? If it's optional (and exists), then you wouldn't want to set this to null as there wouldn't be any way to use it if it was installed.
My understanding is that the pack is optional on Windows too, and that you would opt in to using it by setting a property in the project. If that's right and applies here then I don't think Linux would be any different than Windows (ie they'd both alias to the appropriate pack).
There was a problem hiding this comment.
The python pack doesn't currently exist at all on linux because upstream emsdk doesn't produce it, whereas it does for window and macos. @akoeplinger can add details.
There was a problem hiding this comment.
@mhutch dotnet/sdk#16746 seems to have broken this workaround, what should we be doing here?
|
With the latest dotnet/installer builds the workload is renamed by the installer, this tool either needs to do a similar rename or the workload package should be renamed to match the installer name |
|
I'm going to #yolo this change in, to unblock the linux issue, but we can continue the discussion about the optional pack. |
No description provided.