Do you think it's intentional that the XPC capability is disabled in the sandbox? Doesn't seem to be mentioned.

Can we tell we're in an SPM-plugin / sandboxed environment and automatically use the in-proc version? Something like SWIFT_PACKAGE but in the environment?

Should we just always use the in-proc version if it's available? I guess that would be a bold move...

Need to document the setting in the README.

When you build a Swift package that uses SPM plugins, you can find the helper script that Xcode uses to execute custom build commands in the build log. The script uses sandbox-exec with some rules that specify which directories the command may write files to. It doesn't explicitly specify any XPC rules, so I guess that's just a side effect of using a sandbox.

I looked at detecting if we're in an SPM plugin, the only thing that I found was this environment variable set by Xcode:

export GCC_PREPROCESSOR_DEFINITIONS\=\ SWIFT_PACKAGE\ DEBUG\=1

So it would be possible to parse it at runtime, and if SWIFT_PACKAGE is part of this environment variable, then we could assume that we're running in an SPM plugin. Though I'm not sure if it is a good solution.

We could also try testing if we have write access to some directories to test if we're in a sandbox, but that also feels like a workaround.

The solution in this PR isn't ideal either, because setting environment variables in a .buildCommand in an SPM build tool plugin doesn't seem to work in the current Release Candidate of Xcode. But it can be worked around, for example, swiftlint could have a command line argument, and if that is set, then it could set the environment variable at runtime, before calling SourceKitten.

Regarding always using the in-proc version, that might be not great for people who use SourceKittenFramework in a GUI app, because then if sourcekit crashes, so will the GUI app. So there are advantages in using the XPC version.

So, which solution is the best? I feel that using an environment variable to give the users a choice is the most universal way.

An environment variable for this is fine, but I think we’d additionally want a programmatic option for use in SwiftLint.

Alright, I've added the description of the new environment variable in the README.

For a programmatic option, we could make this a public var. But it would only have an effect if it is set before SourceKit is used.

-let useInProcSourceKit = envBool("USE_INPROC_SOURCEKIT")
+public var useInProcSourceKit = envBool("USE_INPROC_SOURCEKIT")

Thanks @juozasvalancius! I made a few small changes on your branch, I hope you don't mind:

• Moved useInProcSourceKit from a global to a public static mutable var in a SourceKittenConfiguration namespace. In a public API, I prefer not exposing global variables or free functions. This provides the programmatic interface I had asked for earlier.
• Renamed the env var from USE_INPROC_SOURCEKIT to IN_PROCESS_SOURCEKIT, which I feel is a bit more descriptive without being any longer

I'll be merging this once CI passes.

Thanks for working on this, and please keep me up to date as you make progress on your SwiftPM build tool integration!

I tested with SwiftLint to see if there was any performance impact and it looks like the answer is no.

$ hyperfine \
  "IN_PROCESS_SOURCEKIT=1 swiftlint --quiet --no-cache" \
  "IN_PROCESS_SOURCEKIT=0 swiftlint --quiet --no-cache"
Benchmark 1: IN_PROCESS_SOURCEKIT=1 swiftlint --quiet --no-cache
  Time (mean ± σ):      1.201 s ±  0.032 s    [User: 5.793 s, System: 0.281 s]
  Range (min … max):    1.146 s …  1.252 s    10 runs
 
Benchmark 2: IN_PROCESS_SOURCEKIT=0 swiftlint --quiet --no-cache
  Time (mean ± σ):      1.181 s ±  0.009 s    [User: 5.678 s, System: 0.220 s]
  Range (min … max):    1.167 s …  1.199 s    10 runs
 
Summary
  'IN_PROCESS_SOURCEKIT=0 swiftlint --quiet --no-cache' ran
    1.02 ± 0.03 times faster than 'IN_PROCESS_SOURCEKIT=1 swiftlint --quiet --no-cache'

I confirmed via htop that a SourceKitService process is running when IN_PROCESS_SOURCEKIT=0 but not when IN_PROCESS_SOURCEKIT=1 so this seems to be working as intended.

@jpsim thanks for the improvements! And I'll be sure to update you if I have more code to share about SPM plugins.