A search in the SwiftPM code base shows that there are a significant number of references to localFileSystem (294 at the time of this writing). Outside of tests or executables, SwiftPM should be using the FileSystem instance it was provided rather than localFileSystem, the latter of which breaks the abstraction.
There are also a number of places where localFileSystem is used as a default argument. We should limit such uses to end-user-facing parts of the library, or even eliminate them entirely, because it's harder to audit callers for missing-but-intended arguments.
DougGregor
commented
4 years ago
Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Package Manager | |Labels | Bug | |Assignee | None | |Priority | Medium | md5: 21cdaa69e8e455354383b9e23c9b8050Issue Description:
A search in the SwiftPM code base shows that there are a significant number of references to localFileSystem (294 at the time of this writing). Outside of tests or executables, SwiftPM should be using the FileSystem instance it was provided rather than localFileSystem, the latter of which breaks the abstraction.
There are also a number of places where localFileSystem is used as a default argument. We should limit such uses to end-user-facing parts of the library, or even eliminate them entirely, because it's harder to audit callers for missing-but-intended arguments.