feat: Swift registry support

[watt]

Fixes #1016

This PR adds support for package registry dependencies, by adding a new build rule type. For a Package.swift dependency like this:

    dependencies: [
        .package(id: "apple.swift-collections", from: "1.1.0"),
    ]

A build rule will be generated like this:

    swift_registry_package(
        name = "swiftpkg_apple.swift_collections",
        dependencies_index = "@//:swift_packages_index.json",
        id = "apple.swift-collections",
        version = "1.1.0",
    )

[luispadron]

This is a great start thank you!

[luispadron]

This is probably fine for a new feature, we should call this out in any documentation though. I wonder if folks on Bazel < 6 but > 5 could use the credentials helper to work around it?

[watt]

This is probably fine for a new feature, we should call this out in any documentation though. I wonder if folks on Bazel < 6 but > 5 could use the credentials helper to work around it?

I'm not familiar with the credentials helper; can it override the Accept header?

[brentleyjones]

I don't like requiring Bazel 7.1. I'm also not familiar with the credentials helper. @luispadron do you know an answer to their question?

[luispadron]

I experimented with it to get private GitHub repos working and works well for that but looks like things like Accept aren't supported, least going off of: bazelbuild/bazel#17829 (comment)

[cgrindel]

Thank you for the contribution! Let me know what you think about my comment on the issue.

[cgrindel]

We can add an attribute defined as attr.label(allow_single_file = True) to swift_registry_package(). We can read the value in _swift_registry_package_impl() and pass the path to this function.

[watt]

OK, I created a registry_config attribute for this. It still defaults to Label("@//:.swiftpm/configuration/registries.json"), rather than emitting that to the generated rules, though. Is that OK? I'm worried that letting this be customized is a bit dangerous, because putting any other value in here means it won't be using the same config that swift package resolve does.

I think we might want to also pass a --config-path arg to swift to prevent it from using global config outside the workspace.

[cgrindel]

Sorry for the delay. I had many family obligations over the past 2 weeks.

Regarding the label default, that is fine. In another comment, I suggest that we update the doc for the attribute stating where the file comes from / how it is typically generated.

I think we might want to also pass a --config-path arg to swift to prevent it from using global config outside the workspace.

Where do you want to add that?

[watt]

I think we might want to also pass a --config-path arg to swift to prevent it from using global config outside the workspace.

Where do you want to add that?

In the SwiftBin wrapper that calls swift package resolve. By passing a --config-path to that command, we can make swift only look at the config in this workspace (which is the only one RSPM is looking at). So the command would become something like:

swift package resolve --config-path .swiftpm/configuration

--config-path sets the location of the shared config, which is usually ~/.swiftpm/configuration. The idea here is just to make it identical to the project config so that there's only one config to consider. Setting it to something like /dev/null would probably have the same effect (but is maybe more fragile if a new version of swift decides the directory must exist).

[cgrindel]

OK. I am fine with having the new parameter passing the --config-path value. However, as I may have mentioned in another thread, the swift_update_packages macro may disappear before 1.0. I will open a discussion about that shortly.

[brentleyjones]

@watt @cgrindel What's needed to land this? Ideally this would be part of 1.0.

[cgrindel]

What's needed to land this? Ideally this would be part of 1.0.

We just need to understand how this PR changes with swift_update_packages disappearing from rules_swift_package_manager.

[watt]

What's needed to land this? Ideally this would be part of 1.0.

We just need to understand how this PR changes with swift_update_packages disappearing from rules_swift_package_manager.

Is this something I can help with? I'd love to land this as it works today and then iterate towards whatever shape 1.0 has, but I don't have a good sense for what that entails.

[cgrindel]

@watt I just merged #957 which removes the swift_update_packages and some other big changes. Can you rebase this PR from main and raise any issues that you may need help navigating?

[watt]

Unfortunately the breaking changes in #957 made it impractical for me to continue working on this. I may revisit it at some point once we have migrated to bzlmod.

[cgrindel]

I am sorry that the recent changes thwarted your efforts. Once the 1.0 release happens, it would be great to pick this up again.