I have a build tool plugin in an iOS Xcode project that gets the dependencies of the SwiftPM target and then reads the files of the dependencies to find some information. It then generates some files. Is this an accepted use case?
I looked at the sandbox rules and it says \(allow\ file-read\*\) so it does work, just wondering if there's danger of this becoming disallowed in the future.
that's absolutely an acceptable use case. One of the earliest drivers for the SwiftPM plugin system was code generation - specifically reading a configuration file, such as a protobuf or gRPC IDL or OpenAPI spec, and generating the related code associated with that spec.
I wonder if @vash is talking specifically about the source files of a package's dependencies, rather than the source files of the package itself (Sources/Tests).
@Joseph_Heck is right that various code generators do the latter, but I'm not sure if we have an example of the former.
I wonder if this will only work when the checkouts are located at PACKAGE_ROOT/.build, but will stop working if placed outside the package directory. It's my understanding that tools like IDEs can place the checkouts in other locations too, but I suspect that'd break such a build plugin.
cc @dschaefer2 for whether this is a supported use case
(you're right - I missed the dependencies detail earlier)
I'd expect that where it lives on disk isn't guaranteed, but the public API that passes the context of the package includes it's dependencies that you can walk and references a package origin, so in terms of "can I read the dependencies" - you should absolutely be able to find out what they are, get their ID, etc.
The information about that package that you want to read, if it's not provided by the API, may not be available though - at least not on disk. So if you're after the files associated with the source of a dependency, that could get a little dicier - as those aren't guaranteed to be on disk or within the sandbox that I know of. The origin location is exposed, but @Honza_Dvorsky is dead on in that it may not be available locally or guaranteed to be included within the sandbox locations.
Correct, the scratch path can be anywhere. If you look at Xcode it is in DerivedData somewhere. And the user can change it with the --scratch-path arg to SwiftPM so it’s not always .build (which is why I always call it the scratch path 
).
That said, the plugins do have access to the directoryURL of the Packages. I haven’t looked to see whether we add them to the sandbox spec so the plugin or the plugin tools can do anything with that information.