Closed fritzfr closed 2 years ago
Hey @fritzfr , interesting, thanks for the issue. I bet it is some unmapped scenario of decoding a Package.swift, I'll get some time soon to check it out. If you feel like trying to play with it and would like some help, just let me know!
After some investigation I was able to reproduce it for any package when running Swift 5.5 toolchain. I guess you are running Swift 5.5 as well?
I found out that the dependencies
object comes in a different format when running swift package-dump \(someLocalPackage)
on different swift toolchains.
Here is how it looks when generated from different Swift toolchains for the same package:
"dependencies" : [
{
"explicitName" : "SnapshotTesting",
"name" : "SnapshotTesting",
"requirement" : {
"range" : [
{
"lowerBound" : "1.8.2",
"upperBound" : "1.9.0"
}
]
},
"url" : "https:\/\/github.com\/pointfreeco\/swift-snapshot-testing"
}
]
"dependencies" : [
{
"scm" : [
{
"identity" : "swift-snapshot-testing",
"location" : "https://github.com/pointfreeco/swift-snapshot-testing",
"name" : "SnapshotTesting",
"productFilter" : null,
"requirement" : {
"range" : [
{
"lowerBound" : "1.8.2",
"upperBound" : "1.9.0"
}
]
}
}
]
}
]
I'll have to take some time to fix this by first analyzing the differences on the package dump between Swift versions, and then adding logic to parse them differently.
Thanks again for the report, and this will be a good learning to keep an eye out on upcoming Swift versions to check any changes on the generated package dump, besides updating dependencies and keeping the swift-tools-version up to date.
Hey @fritzfr, let me know how it goes for you when using the latest 1.3.01.3.1 release.
It works well for me here for different packages, including yours, https://github.com/FinTecSystems/xs2a-ios:
** ARCHIVE SUCCEEDED ** [16.420 sec]
Finished Shell command
Size on disk: 4,5 MB
+-----------------------------------------------+
| Swift Package Info |
| |
| XS2AiOS, 1.2.0 |
+-------------+---------------------------------+
| Provider | Results |
+-------------+---------------------------------+
| Binary Size | Binary size increases by 1,9 MB |
+-------------+---------------------------------+
> Total of 1 provider used.
Cheers.
PS: While testing the changes I also took time to investigate why sometimes the tool would stay stuck when Generating archive for updated app, and I am patching a fix that fixes that and might also improve performance a bit.
Thank you, this fixes the issue.
Actually I have to reopen this. I did a pull and build the tool again, the fired the same command as in the first post here. Still getting:
❯ .build/debug/swift-package-info --for https://github.com/FinTecSystems/xs2a-ios -v 1.4.0
Identified Swift Package:
Repository URL: https://github.com/FinTecSystems/xs2a-ios
Version: 1.4.0
Product: Undefined
Error: keyNotFound(CodingKeys(stringValue: "name", intValue: nil), Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "dependencies", intValue: nil), _JSONKey(stringValue: "Index 0", intValue: 0), CodingKeys(stringValue: "scm", intValue: nil), _JSONKey(stringValue: "Index 0", intValue: 0)], debugDescription: "No value associated with key CodingKeys(stringValue: \"name\", intValue: nil) (\"name\").", underlyingError: nil))
Hey @fritzfr, I was able to reproduce here. I'll take a look soon. Thanks!
Hello @fritzfr, it should be fixed now.
The patch done add fixes on decode Package.swift when using Swift's 5.6 toolchain.
Can you please try it out against the version/tag 1.3.2
? Works fine for me here:
BTW it seems there's a small bug to fix on reporting dependencies as well 🙈
Update: Actually is that when dependencies are declared by name, like on https://github.com/FinTecSystems/xs2a-ios/Package.swift, there's no (at least easy) way to trace which Package provides that product.
Which is not the case when a target dependency is declared via .target
and .product
.
I'm trying to analyze my Swift Package https://github.com/FinTecSystems/xs2a-ios.
I'm getting:
This seems very similar to https://github.com/marinofelipe/swift-package-info/issues/11, but concerns a different key in the Package.swift.