swift-sdk-generator
swift-sdk-generator copied to clipboard
Replace custom `async` file system wrapper with `NIOFileSystem`
We currently have our own, not necessarily well-tested or valid implementation of async file system APIs in https://github.com/apple/swift-sdk-generator/tree/main/Sources/GeneratorEngine/FileSystem. With NIOFileSystem now available in SwiftNIO 2.63, we should use that instead.
Hi, I was wondering if I could work on this?
As I was poking around I noticed that running ./Utilities/soundness.sh on main fails for UnixName.swift
=> Checking license headers...
* swift-or-c... missing headers in file './Sources/SwiftSDKGenerator/SystemUtils/UnixName.swift'!
--- /dev/fd/63 2024-08-03 15:39:55
+++ /tmp/.swift-package-manager-soundness_nooVYa 2024-08-03 15:39:55
Also this is my first time using swiftformat but when running swiftformat . on main, 35 files are reformatted.
➜ swift-sdk-generator git:(main) swiftformat .
Running SwiftFormat...
Reading config file at .../swift-sdk-generator/.swiftformat
warning: --varattributes option is deprecated. Use with `--storedvarattrs` or `--computedvarattrs` instead.
SwiftFormat completed in 0.46s.
34/60 files formatted.
Yes, as this is an issue marked as "good first issue" and is unassigned, it's free for anyone for anyone to work on.
Feel free to fix soundness and formatting issues, but those should be submitted as separate PRs so that those changes don't pollute other PRs one may submit as part of their work.
This will effectively prevent porting to windows until NIO properly supports windows. I would prefer that we didn't do this.
It won't change the status quo WRT Window support, as Swift SDK Generator already depends on SwiftNIO.
Ah, that's rather unfortunate.
Could the new Foundation help with the NIO dependency? Though it doesn't look like SubProcess has made it in yet. https://github.com/apple/swift-foundation/pull/439
No, it won't help since relevant Foundation APIs are not async.