package plugins automatically depend on
PackagePlugin. now i have two such plugins, and i want to factor out some of their common functionality into a library target they will come to import. but the library target can’t link to
error: no such module 'PackagePlugin'
trying to link externally against
"https://github.com/apple/swift-package-manager" won’t guarantee that the tools version will match, and compiling the SPM from source takes a long time anyway.
A plugin definition cannot have dependencies in the first place, just as the manifest cannot. That is your real first hurdle. I do not know if there is a technical reason, or if it is just to repel the temptation to pull real work into the plugin definition, where it will end up running every time the package loads instead of just as needed by the build.
To other readers: Defer as much as you can to the associated executable, which can have dependencies. (Although by then the
PackagePlugin module is useless, so I doubt it helps in your particular case, @taylorswift.)
it is because it needs the type definitions in
PackagePlugin/PackageModel.swift file, as the library target implements dependency resolution algorithms.
I meant the reasoning of the SwiftPM team for prohibiting dependencies.
I'd really like to be able to do this as well. We have some shared code that multiple plugins are depending on, which needs access to the
PluginContext. Is there a way to do this?
I’ve ended up passing everything I need from the context as command line arguments to the tool.
I first planned to just pipe a json serialized representation but realized I can’t really share the definitions as one can’t have any dependencies - it’s a bit unfortunate.
For me, the biggest reason is that package plugins (and manifests) are meant to be built and executed on the host, while libraries and executables are built against the target. Since Swift and SwiftPM should fully support cross compilation, this means
PackagePlugin are very different from standard and core libraries. They’re not distributed along with the SDK, and shouldn’t be referenced by any regular target simply because that’s not available.