cgrindel / rules_swift_package_manager

Collection of utilities and Bazel rules to aid in the development and maintenance of Swift repositories using Bazel.
Apache License 2.0
72 stars 26 forks source link

swift-deps-index.json became invalid after updating from 0.15.0 to 0.20.0 #733

Open AttilaTheFun opened 10 months ago

AttilaTheFun commented 10 months ago

I'm using RxSwift and one of my files imports:

import RxRelay
import RxSwift

But the gazelle plugin is adding these to my build file:

        "@swiftpkg_rxswift//:Sources_RxBlocking",
        "@swiftpkg_rxswift//:Sources_RxCocoa",
        "@swiftpkg_rxswift//:Sources_RxRelay",
        "@swiftpkg_rxswift//:Sources_RxSwift",
        "@swiftpkg_rxswift//:Sources_RxTest",

My Package.resolved has:

    {
      "identity" : "rxswift",
      "kind" : "remoteSourceControl",
      "location" : "https://github.com/ReactiveX/RxSwift",
      "state" : {
        "revision" : "9dcaa4b333db437b0fbfaf453fad29069044a8b4",
        "version" : "6.6.0"
      }
    },

RxSwift has not been updated in 6+ months and the Package.swift was last added two years ago: https://github.com/ReactiveX/RxSwift/blob/main/Package.swift

I believe this is a recent regression with rules swift package manager.

In my MODULE.bazel I have:

bazel_dep(name = "rules_swift_package_manager", version = "0.20.0")

This is blocking me because this target depends on XCTest which I can't link into my application.

AttilaTheFun commented 9 months ago

Following up here, @luispadron and I figured out on Slack that my swift-deps-index.json became invalid when I updated my rules_swift_package_manager version from 0.15.0 to 0.20.0

When I deleted this file and Package.resolved, and then re-generated them with my swift_update_packages target, the correct dependencies could be added by the plugin.

At a minimum, the file should include versioning information and the plugin should throw an error if the file was generated from an incompatible version telling the user to re-run the swift update packages action.

Preferably, though, as I've mentioned previously, we could just produce this file from the repository rule and not check it into the repository. Bazel would automatically regenerate it when the version changes because the module versions are included in the directories in the bazel-gen and bazel-out directories.

cgrindel commented 9 months ago

Related to #703.

At a minimum, the file should include versioning information and the plugin should throw an error if the file was generated from an incompatible version telling the user to re-run the swift update packages action.

In the short-term, I agree that we should add a version to the file and fail with a nice message if the version of rules_swift_package_manager requires a newer version of the index file. The index file version should be independent of the rules_swift_package_manager version. It may be as simple as "file_version": X where X is an integer. This will be incremented whenever an incompatible change occurs to the file.

luispadron commented 9 months ago

More discussion on removing need for this file in: https://github.com/cgrindel/rules_swift_package_manager/discussions/743

It may be as simple as "file_version": X where X is an integer. This will be incremented whenever an incompatible change occurs to the file.

My main concern with detaching this from the version of rules_spm is that it just adds another version we can mess up on updating. I also don't know how we could catch this in CI for all cases. I almost want update_swift_pkgs to be a target you need to run whenever you update rules_spm until the discussion above is addressed.

For now though, at a minimum we should fail to build with an appropriate warning if this file is out-of-date. @AttilaTheFun is this version addition something you'd be able to contribute?