Package issue - Unnecessary dependencies and wrong name?

Hi.

I'm having an issue with the following package.

There are two products. I just want to use the 'Jaws' library.

I expect the dependency 'Files' only but I'm also getting swift-argument-parser? And the package appears as Vice.

let package = Package(
    name: "Vice",
    platforms: [.macOS(.v10_13)],
    products: [
        .executable(name: "vice", targets: ["Vice"]),
        .library(name: "Jaws", targets: ["Jaws"])
    ],
    dependencies: [
        .package(url: "https://github.com/apple/swift-argument-parser.git", .upToNextMinor(from: "0.3.0")),
        .package(url: "https://github.com/JohnSundell/Files.git", .upToNextMinor(from: "4.2.0")),
    ],
    targets: [
        .target(
            name: "Vice",
            dependencies: [
                .product(name: "ArgumentParser", package: "swift-argument-parser"),
                .product(name: "Files", package: "Files"),
                .target(name: "Jaws")
            ]),
        .target(
            name: "Jaws",
            dependencies: [
                .product(name: "Files", package: "Files")
            ]),
        .testTarget(
            name: "JawsTests",
            dependencies: [
                .product(name: "Files", package: "Files"),
                .target(name: "Jaws")
            ],
            resources: [
                .process("Resources")
            ]
        ),
    ]
)

Your expectation matches the eventual intent for the how the package manager is to behave. However, the more fine‐grained resolution logic capable of recognizing swift-argument-parser as superfluous is not active in any official release yet. Swift 5.3 only knows to skip dependencies not used by any product.

Note that SwiftPM has only fetched the source code. It is not being compiled or in any way included in your build.

The first screenshot you included is displaying a list of fetched packages. Expanding it shows all of the fetched source files, not just the ones relevant to the build. This is on purpose, so that read‐me and other included documentation is available in that menu. “Vice” is the the name of the package, so it is displaying correctly.

The second screenshot is listing of products available to link, which is why you see the product name “Jaws” instead.

Thank you.

What's also curious @SDGGiesbrecht is that the target JawsTests can only be run by the scheme Vice-Package. However, the tests are specific to the Jaws library and have nothing to do with the Vice target.

Is there a means of adjust the PackageDescription above to achieve a more specific test target?

Only the x-Package scheme is “real” in that it matches command line and cross‐platform SwiftPM. As a convenience, Xcode derives several others it thinks might be useful during development. But Xcode is closed source and I don’t know what its logic is. The manifest you posted appears to follow standard best practices, so if Xcode doesn’t already give you the sort of scheme you are looking for, I doubt there is a way to convince it to, at least from the manifest. You could try asking about it from the Xcode side over on the Apple Developer Forms.

1 Like

[@nashysolutions over on GitHub:]

As you can see, I am wondering around GitHub like a nomad, trying to find out more. You guys know if this issue has been raised already?

There is a bug registered here, although it contains little information because work on it has revolved more around the evolution proposal than the bug report.

The fix is actually already implemented, it’s just not live. I implemented it in this pull request and it was merged. Unfortunately it ran into another bug that mishandles some packages and had to be temporarily disabled and hidden behind a compiler condition (by this pull request). At this point, all the known packages which trigger the bug are confidential. Since I am not cleared to see them, I cannot reproduce the bug and cannot debug it. Apple’s employees have done some debugging of their own and from what they were able to say publicly, it seems the bug might actually have to do with package identity and caching instead, and may have only been exposed by the new code. For now I am crossing my fingers that it might have fixed itself by the time the identity overhaul is complete, and that at that point all we will have to do is remove the compiler condition. I think the most recent discussion is in this pull request, from which you should be able to follow links to find all the others.

It will not be included in Swift 5.4. I am hoping it will be in Swift 5.5.

Terms of Service

Privacy Policy

Cookie Policy