Restrict platforms for packages?

bdrelling · October 1, 2019, 11:29pm

Is it currently possible to restrict platforms for Swift Packages? For example, if I want to explicitly ensure my package is not able to be used with tvOS, for whatever reason.

SDGGiesbrecht · October 2, 2019, 12:34am

There is no way to declare it in the manifest to affect package resolution.

But you can do the following in any of the source files:

#if os(tvOS)
#error("This package does not support tvOS.")
#endif

May I ask why you want to do this?

bdrelling · October 2, 2019, 12:43am

For the same reason CocoaPods allows it: to make support for a platform on a package I maintain explicit, to improve discoverability for new packages (especially in GitHub or Dave Verwer’s site and other examples sure to pop up), to ensure a new dependency can support the platforms my product is being built on, etc.

If you (or really anyone) thinks these reasons are invalid, can you tell me why? I could just be thinking about this the wrong way.

Explicitly opting in would make much more sense to me—or at least being able to explicitly opt out.

I could see doing something like .tvOS(.unsupported), or making it so if you list one platform you have to be explicit for the rest.

SDGGiesbrecht · October 2, 2019, 1:00am

I have no opinion of my own, but I can provide a few links If you are curious about the history of the API for specifying platforms.

Here is the proposal that added platform specification:

github.com

apple/swift-evolution/blob/main/proposals/0236-package-manager-platform-deployment-settings.md

# Package Manager Platform Deployment Settings

* Proposal: [SE-0236](0236-package-manager-platform-deployment-settings.md)
* Authors: [Ankit Aggarwal](https://github.com/aciidb0mb3r)
* Review Manager: [Boris Bügling](https://github.com/neonichu)
* Status: **Implemented (Swift 5)**
* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-with-modifications-se-0236-package-manager-platform-deployment-settings/18420)
* Previous Revisions: [1](https://github.com/apple/swift-evolution/blob/aebb22c0f3e139fd921d14f79c3945af99d0342d/proposals/0236-package-manager-platform-deployment-settings.md)

## Introduction

This is a proposal for adding support for specifying a per-platform minimum required deployment target in the `Package.swift` manifest file.

## Motivation

Packages should be able to declare the minimum required platform deployment target version. SwiftPM currently uses a hardcoded value for the macOS deployment target. This creates friction for packages which want to use APIs that were introduced after the hardcoded deployment target version.

There are two ways to work around this limitation: 1) using availability checks, or 2) passing the deployment target on the command line while building the package. However, these workarounds are not ideal and the package manager should really provide a proper API for setting the required deployment target version.

## Proposed solution

This file has been truncated. show original

Here is its review:

And here is its acceptance:

bdrelling · October 2, 2019, 3:01am

Thanks Jeremy, this is extremely helpful context.

This is exactly what I was wondering:

Restricting supported platforms: Some packages are only meant to work on certain platforms. This proposal doesn't provide ability to restrict the list of supported platforms and only allows customizing the deployment target versions. Restricting supported platforms is orthogonal to customizing deployment target and will be explored separately.

I wonder if this exploration ever occurred otherwise?

SDGGiesbrecht · October 2, 2019, 3:05am

It hasn’t been revisited yet. (At least not on this forum.)

toph42 · October 2, 2019, 10:42am

What happens if you require a minimum version that doesn't exist? Like 999.0?

SDGGiesbrecht · October 2, 2019, 8:30pm

Then, as with #error, clients will be unable to build it. But #error at least allows you to provide a meaningful explanation.

Note that either may bite back if some tool wants to build for multiple things at once and fails to provide a way to opt out of a platform. (I have heard rumours to this effect about Xcode + XCFrameworks, but I haven’t tested it myself.)

The absolute safest way, (albeit most repetitive and annoying as a vendor) is probably to surround all the sources in #if os(WhatIActuallySupport). That way clients that do want to support another platforms can still safely import your package, using it were possible and filling in the rest with some alternate dependency. If you actively block compilation, they do not have this option—they must either drop the platform, or drop your package.