Big changes are coming in the 1.0 release with implications for projects that use legacy Bazel workspace for external dependencies

[cgrindel]

tl;dr Release 1.0 will not support the automatic generation of Swift package repository rules for legacy Bazel workspaces. Read on and provide your feedback.

Release 1.0 Goals

• Separate the Gazelle plugin for Swift code from the SPM functionality.
• Remove the checked-in Swift index JSON file that is currently required.

Tracking issue

Impact on legacy Bazel workspaces

If you load rules_swift_package_manager using http_archive from a WORKSPACE file or .bzl file that is loaded into your WORKSPACE, you are using the legacy external dependency mechanism. Be sure to read this section.

Today, the update_repos command in the Gazelle plugin generates a swift_deps.bzl file that you load in your WORKSPACE. This file declares each of the Swift packages that your project depends upon as an external repository using the swift_package and local_swift_package repository rules. This happens for you when you execute the swift_update_packages target as described in the documentation.

With the Gazelle plugin being moved to its own repository, rules_swift_package_manager will not be able to generate the swift_deps.bzl file for you.

Will Bazel module (bzlmod enabled) workspaces work properly?

Yes. With bzlmod enabled, Bazel provides a phase of execution that allows us to do the same work previously done in the Gazelle plugin's update_repos action.

Can you support legacy workspaces in the Gazelle plugin after you move it to a new repository?

Maybe. However, that would require more work and the solution would have a fairly short shelf-life as legacy Bazel workspaces will not be available with the release of Bazel 9. Frankly, Bazel modules is the future. We highly encourage everyone to migrate to bzlmod.

I can't migrate my entire workspace to bzlmod at this time. What can I do?

Bazel does support a hybrid mode that allows you to load some of your dependencies using bzlmod and some via the legacy mechanism. We suggest enabling this hybrid mode, load rules_swift_package_manager as a bazel_dep and leave the rest of your dependencies loading from your WORKSPACE file.

Where is the Gazelle plugin going?

It will move to a new repository. It will continue to support the build file generation that you know and, hopefully, love.

I have questions or concerns. What should I do?

Reply to this discussion. We want to hear from you. The intention of these changes is to address concerns with the existing architecture and allow folks to easily leverage the functionality that they want. We are trying to find the best path forward while minimizing the development effort and support overhead.

[jpsim]

I've very happy to see the project remove the need for the index JSON file, and overall the approach works for me. I've confirmed that our project compiles with the gh924_no_swift_index branch too.

However, we're currently relying on the index json file to get the mapping from dependency name to Bazel label (e.g. AsyncAlgorithms to @swiftpkg_swift_async_algorithms//:AsyncAlgorithms). How would you suggest we derive this mapping without having the checked-in index json file?

[jpsim]

We could hardcode a list of mappings, we have about 40 of them, but I'd like to find a way to automate it.

[cgrindel]

I added a repository rule called swift_deps_info that generates the Swift index JSON file. It has the same format as the one that is generated using Gazelle. You should be able to get the mappings from there.

[cgrindel]

This repository rule will move to the new repository when the Gazelle plugin moves.

[cgrindel]

FYI. I am merging #957. There are some breaking changes. Please review the doc before updating.