Currently to specify a platform version for, e.g., MacOS, an opaque enum value is required (PackageDescription.SupportedPlatform.MacOSVersion) and can be specified by e..g .macOS(.v10_15)
In cases where a project is distributed via multiple package managers and/or involves build tools other than those provided by Xcode, it is useful to externalise versions in relevant dotfiles. To this end, I use a .macos-version files that contains a string such as 10.15
It would be very useful to introduce a string initializer of a form similar to .macOS("10.15") to allow this behaviour.
The only option for doing this at the moment is to either a) update version numbers in multiple places, thus defeating the purpose of the dotfile; or b) add the complication of string templating and generate the Package.swift file as part of the build process.
Feedback appreciated as well as examples of where you've run into this problem or a similar one.
A quick test shows that a manifest can read from (but not write to) the file system, so what you want to do would work today. I don't know if SPM would plan to be more restrictive in the future about what the manifest can do in the sandbox, though.
Only if the files are actually there. Sometimes they wonât be, such as when resolving a registry dependency, in which case the manifests are fetched and loaded before deciding whether or not to download the rest of the source.
Better to write such things into the manifest with a command plugâin before check in. (If you rig CI to flag when the command changes anything, you will catch it if someone manually updates something out of sync.)