Swift Package Index is overcounting package dependencies

[tayloraswift]

Which package(s) are showing incorrect data?

• https://swiftpackageindex.com/tayloraswift/swift-bson

hey guys, i noticed a while back that Swift Package Index is overcounting package dependencies, and wanted to open this issue to finally start discussions about resolving this issue.

the current formula is rather unfavorable towards my libraries, because they count every transitive dependency reachable from the Package.swift manifest, regardless of whether they are actually included in the library or not.

in the case of swift-bson, the library has two truthful dependencies (swift-unixtime and swift-grammar), and Swift Package Index seems to be augmenting that count with swift-hash and swift-atomics.

• swift-hash is part of an overlay module BSON_UUID, which is provided for user convenience and is not part of the core library (BSON).

• swift-atomics is a dependency of the Testing_ module in swift-grammar, which swift-bson does not use at all.

this is a concern to me, because for most users of swift-bson, SwiftPM will never clone either repository, and the statistic displayed by Swift Package Index is misleading and paints the package in an unnecessarily bad light.

[finestructure]

Yes, this is a known problem. We use Package.resolved to determine this "global" dependency count. It also counts dependencies which are only used in test targets, which is relevant to some degree (supply chain security) but not as important as what I've come to call "product dependencies", i.e. dependencies that contribute directly to your shipped binary.

I started work on improving the situation a while ago but it's a bigger task and unfortunately it's been repeatedly overtaken by other priorities :(

I don't think maintainers should be focusing on the score too much but I can see how it's tempting to try and optimise it.

What we could do is take this out until we have better stats. Or make it much more coarse, in order to only try and reflect only extreme scenarios.

[tayloraswift]

hi Sven, thanks for the quick response!

i think it is a good idea to remove this statistic, as it is better to display no statistic at all than a misleading statistic.

it’s my understanding also that Swift Package Index is also currently demoting packages in search results based on dependency count, which is problematic for the same reasons.

regarding the first issue, i have considered adding banners to the READMEs of the affected packages informing viewers that the Swift Package Index dependency count is wrong, but this would be confusing (or at least highly distracting) to the majority of visitors who are viewing the README from GitHub directly. i don’t want to ask you to delist the packages entirely either, as there are still a lot of benefits to appearing on Swift Package Index. i’m not aware of a way to customize READMEs for Swift Package Index, so you can see the dilemma i’m in here.

[finestructure]

I believe you're way over-interpreting the effect the minuscule adjustment of the score actually has :) As you can see on the maintainer page, the dependency count has pretty much the smallest contribution to the overall score with a maximum of 5 points for 0...3 dependencies. Packages easily get 30-60 points from other categories, so you can see how little this actually does.

I certainly wouldn't call it a "demotion" :)

You're of course free to adjust your Readme in any way you like to call out anything you feel is amiss but I'd like to ask: can you share a search where you feel your package isn't ranking as well as it should be? I think that's something we would need to focus on if it's the case.

[tayloraswift]

while i mentioned it as a related issue, search rankings on Swift Package Index are a secondary concern to me; the main problem is the indicator on the package pages.

i market these libraries as being “lightweight with as few dependencies as possible” (e.g., no Foundation even), so when they show up on Swift Package Index with a label that says “this package has 4 dependencies” when it only has two, that undercuts the message.

now i can add things to the various READMEs to try and explain the discrepancy, but i’m aware that doing so would make it harder for you to correct the metric later, since i would basically be instructing visitors to distrust the Swift Package Index metadata. so i figured it would be better to talk to you about this first :)

[finestructure]

I wasn't at my machine last night but this morning I tested using swift-bson as a dependency in a new package in the simplest way via

swift package init --type library

and a package manifest as follows:

// swift-tools-version: 6.0

import PackageDescription

let package = Package(
    name: "dep-test",
    platforms: [.macOS(.v15)],
    products: [.library( name: "dep-test", targets: ["dep-test"]),],
    dependencies: [.package(url: "https://github.com/tayloraswift/swift-bson", from: "0.7.1")],
    targets: [
        .target(name: "dep-test", dependencies: [.product(name: "BSON", package: "swift-bson")]),
        .testTarget(name: "dep-testTests", dependencies: ["dep-test"])
    ]
)

Both SwiftPM as well as Xcode fetch all four transient dependencies of swift-bson:

❯ ls -l .build/checkouts/
total 0
drwxr-xr-x  19 sas  staff  608 13 Jan 09:44 swift-atomics/
drwxr-xr-x  14 sas  staff  448 13 Jan 09:44 swift-bson/
drwxr-xr-x  12 sas  staff  384 13 Jan 09:44 swift-grammar/
drwxr-xr-x  12 sas  staff  384 13 Jan 09:44 swift-hash/
drwxr-xr-x  13 sas  staff  416 13 Jan 09:44 swift-unixtime/

So I think even if we had more granular info about direct and transient dependencies, I believe it would be entirely reasonable to report 4 dependencies in this case.

You said

SwiftPM will never clone either repository

Are there circumstances where this would be true and our metric of 4 dependencies would be wrong? It doesn't actually seem to be wrong in the simplest case and therefore would reflect what users actually encounter, wouldn't it?

[daveverwer]

One thing that we could do to make this much clearer what this number currently counts is to add a note. I just opened #3593 to hopefully help here.

[tayloraswift]

Are there circumstances where this would be true and our metric of 4 dependencies would be wrong? It doesn't actually seem to be wrong in the simplest case and therefore would reflect what users actually encounter, wouldn't it?

frankly, this looks like a SwiftPM bug. there is no reason SwiftPM should be cloning those dependencies at all, just to build the BSON target.

[tayloraswift]

i’ve started a Forums thread about this issue: https://forums.swift.org/t/swiftpm-seems-to-be-cloning-unnecessary-dependencies/77169

[Sherlouk]

This has long been a challenge of SwiftPM downloading all dependencies, even those not used by the "product" the user is using.

https://github.com/open-telemetry/opentelemetry-swift/ sticks out in my mind as a public example of this, where the "core" product doesn't require GRPC but we still have to fetch it (and it's not a fast one).

If it's a big problem for you, you could have a Package_test.swift file. Before you run your tests on CI, simple rename the files so it uses the test one. Of course this does slightly increase your maintenance cost (have to make sure they're in sync, minus the test specific targets).

SPI, and users, would only see Package.swift which wouldn't include the test targets nor test dependencies, thus giving a more "genuine" representation, and actually benefitting your users by reducing how many dependencies they need to pull.

[Sherlouk]

I believe https://github.com/swiftlang/swift-evolution/blob/main/proposals/0226-package-manager-target-based-dep-resolution.md is relevant to this discussion, as it has been explored in the past. They landed on not building the dependencies, but still cloning them.

[tayloraswift]

unless i’m reading this wrong,

The resolution process will start by examining the products used in the target dependencies and figure out the package dependencies that vend these products. For each dependency, the resolver will only clone what is necessary to build the products that are used in the dependees.

suggests this should not be the case.

[Sherlouk]

"Partially Implemented" and the associated description is probably doing a lot of the heavy lifting. This has been a problem for a long time, I'd love to see it fixed but alas we are where we are (and I appreciate not an easy one to sort for SPM engs).

[daveverwer]

I'll close this as it seems to be more SwiftPM than SPI at this point.