SE-0264 (review #2) — Standard Library Preview Package

It's an interesting idea. However, providing more ways to backward deploy is not the primary intent of these packages and won't always be able to accomplish that. Consider Result: if you mix code that is using Result from the Standard Library and Result from a preview package the two Result types will not be the same as they will be vended by different modules.

1 Like

That makes sense yes. I wouldn't mind some ability to force manually some stdlib API's to act like if they had @_alwaysEmitIntoClient and disable version locking. I'd personally sacrifice some binary size just got the some API's I need and would avoid copy pasting / maintaining them.

@tkremenek As was mentioned in December by @SDGGiesbrecht:

The implementation of SE-0226 is coming in Swift 5.2 and will make those naming issues much more visible, forcing users to explicitly specify their dependencies in their manifests:

let package = Package(
    name: "BestPackage",
    dependencies: [
        .package(url: "https://github.com/apple/swift-standard-library-preview", from: "1.0")
    ],
    targets: [
        .target(name: "BestTarget", dependencies: [
            .product(name: "StandardLibraryPreview", package: "swift-standard-library-preview")
        ]
    ]
)

Shouldn't we start naming repositories the same name as their packages?

@hartbit, just wanted to acknowledge that I've seen this point and have been thinking about.

The change in SE-0226 is a good change, but embracing that model fully is going to be challenging for GitHub organizations that have a large number of repositories that are being contributed by multiple teams. This problem will show up in particular with larger companies that are publishing a variety of open source projects into a single organization.

The Swift repositories have had the swift- prefix to "namespace" them from other projects in the Apple organization. Today, GitHub does not support nested organizations, which would be a nice way to chop off such prefixes that are used in repository names for this purpose.

Because the Swift core project repositories are in the Apple organization (and there is no plan otherwise right now) my intuition is we are dealing with tradeoffs. The tradeoff here is to keep all the repositories consistently named or embrace more of the benefits of SE-0226. After thinking about it, the decision is to go with the former.

I think this will be an evolving story over time. I anticipate that the tools will continue to evolve (e.g., a package index remains an interesting direction) which may change the options available here. For now, we are going to go with the approach given.

3 Likes
Terms of Service

Privacy Policy

Cookie Policy