Hi
I'm working on a code base with a fine grained modularisation. My Package.swift declares a long list of libraries, where each library depends on several targets.
To make this file easier to read I was wondering if there was a way to split it into several "sub" Package.swift ?
Thanks.
You can create a separate subdirectory, with its own self-contained package layout and Package.swift manifest. Then to add dependencies from an upper level use static func package(name: String, path: String) -> Package.Dependency declared on Package.Dependency.
Oh, I didn't know that myself. Glad I read this thread. That could come handy inside my own Swift Playgrounds project on the iPad. Thank you.
There is an important caveat to note when recommending this: path dependencies are invalid for versioned releases. (For hopefully obvious reasons; most paths point at different things depending on the context into which the release was fetched. There may be a case for enabling relative paths which do not escape the package, but to my knowledge that has not yet been considered separately from the general use case of a neighbouring package developed in tandem. So using an internal path will appear to work until you tag a release, but then a client will try to use your release and be told by SwiftPM that your package is invalid.)
Do you know if a GitHub issue tracking this limitation already exists by any chance?
I doubt it. I think this and another thread from a day or two ago were the first time I heard about anyone wanting to use it this way. All design, discussions, issues, troubleshooting, etc. that I can remember all dealt with relative paths pointing outside the package. Things inside the package being different was never on anyone’s mind. I may have missed or forgotten something, but as far as I know you have basically just pitched a brand new idea here.
Thanks for the clarification! That's now tracked in Allow use of local packages within single repo for tagged releases · Issue #6137 · apple/swift-package-manager · GitHub