In a project, I need to compose the product from a number of different tools. Those tools are to be fetched from Git or from the file system, and they are subject to complex version dependencies.
The Swift package Manager (SPM) delivers the needed features quite well, and as some of the tools are written in Swift, the definition of the dependencies is easy for the according developers. As far as no Swift packages are involved, you just need to use "Package.swift" files without products or targets. The according versions of the tools (in most cases their sources) are collected inside the .build/checkout directory of the top-level product definition.
The problem comes with tools that are Swift packages. Dependant Swift packages should not be resolved across tools (each tool contains a separate executable), actually the Swift packages should not be resolved at all in this process.
So I compiled a different version of the Swift Package Manager (swift-5.10.1-RELEASE) with the following replacements:
- replace
Package.swiftbyComposition.swift(whole word, 280 occurrences across 56 files) - replace
Package.resolvedbyComposition.resolved(whole word, 51 occurrences across 24 files) - replace
"Package"by"Composition"(whole word, 6 occurrences across 6 files)
Then when calling swift-package resolve for this adjusted SPM, instead of Package.swift and Package.resolved the filenames Composition.swift and Composition.resolved are used and I can compose my product using those new filenames, also checking out the appropriate versions of the Swift based tools.
So I would like to be able to call SPM by e.g.
swift package resolve --config-basename Composition
or
swift package update --config-basename Composition
which changes the accordings basenames from the default Package. (The .build folder does not have to be renamed.) Update: In addition, the SPM should not complain about missing Composition.swift files (to keep the example) and just continue the checkouts of the resolved versions (you would like to be able to pull foreign tools where you cannot add such a Composition.swift file which would be without dependencies anyway, and not using Package.swift means this is not about Swift).
Such a change would be easy and without much risk, but as the Package basename is used a lot across the source files of the SPM, the addition of such a new argument would not be a "trivial" patch.
What do you think?