Package identity in name field

[martinK-7]

Hey, first thanks for creating this great tool!

We are using it in our pipelines to generate license information for the packages of our Xcode project. We noticed that sometimes it happens that the package identity is also in the generated name field which leads to non-user-friendly outputs. For example the json output for abseil:

{
    "identity" : "abseil-cpp-binary",
    "license" : "...",
    "name" : "abseil-cpp-binary",
    "repositoryURL" : "https:\/\/github.com\/google\/abseil-cpp-binary.git",
    "revision" : "748c7837511d0e6a507737353af268484e1745e2",
    "version" : "1.2024011601.1"
  }

Name should actually be "abseil" here.

As I understood, you get this information from "workspace-state" in derivedData. There it also looks like this:

{
        "basedOn" : null,
        "packageRef" : {
          "identity" : "abseil-cpp-binary",
          "kind" : "remoteSourceControl",
          "location" : "https://github.com/google/abseil-cpp-binary.git",
          "name" : "abseil-cpp-binary"
        },
        "state" : {
          "checkoutState" : {
            "revision" : "748c7837511d0e6a507737353af268484e1745e2",
            "version" : "1.2024011601.1"
          },
          "name" : "sourceControlCheckout"
        },
        "subpath" : "abseil-cpp-binary"
      },

It seems like an issue with Xcode itself, unfortunately I cannot really tell how to reproduce it. We found that in our case it happens only when originHash in Package.resolved changes, for example after updating some package. After reverting only the change in the hash it starts working as expected again (🤷).

To avoid these random Xcode issues, would it be an option to get package names directly from "Package.swift" in checkouts? Or maybe you have some other ideas.

Setup: Xcode 15.4 swift-package-list 4.1.0 Input Parameters: .../x.xcworkspace --output-path '.' --custom-file-name 'tmpDeps' --output-type 'json' --custom-derived-data-path '/Users/x/Library/Developer/Xcode/DerivedData'

Please let me know if you need more information. Thanks in advance.

[FelixHerrmann]

Hey, thanks for reaching out! If you say pipeline does it mean you only experience this during a CI job? I feel like it could have something to do with timing, so when it is invoked during your build process. The not so user-friendly repo-name is the fallback until the dependency is fully fetched and loaded, see swift-package-manager for reference; you can actually see that happening in Xcode when SPM is in progress.

To avoid these random Xcode issues, would it be an option to get package names directly from "Package.swift" in checkouts? Or maybe you have some other ideas.

I've intentionally avoided that in #72 because this either requires a error-prone string lookup or an actual compilation step of the Package.swift which also requires the PackageDescription module from https://github.com/apple/swift-package-manager.

[martinK-7]

Thanks for the detailed answer.

If you say pipeline does it mean you only experience this during a CI job? I feel like it could have something to do with timing, so when it is invoked during your build process.

We are only using your tool in our CI jobs, so usually we don't check the "workspace-state" file. What happens on CI is that the repo is checked-out from scratch and we build the project using gym (xcodebuild). After that, we run swift-package-list. I tried that flow locally and it leads to the same issue. From that point, I could not find a way to recover it, even opening Xcode does not change anything.

I could also reproduce it with a test package. If you want to try it, you can find it here: https://github.com/martinK-7/PackageDependenciesTest My steps were basically:

• checkout
• xcodebuild -scheme PackageDependencies -destination 'generic/platform=iOS'
• check workspace-state

It actually also happens when you open the Package with Xcode and wait for packages to be resolved. It seems, Xcode only generates this file properly if you change dependencies while having it opened. I tried with different packages as well. On our CI, sometimes it works just fine, unfortunately I cannot tell in which exact cases.

[FelixHerrmann]

Thanks for all the details, that is very helpful. I could produce it with the xcodebuild CLI on my side too, will do a more detailed investigation when I find some time!

[vdm-swm]

Having the same issue while building locally: My mac shows some packages with the non-user-friendly outputs whilst my colleagues mac resolves the names just fine.

[martinK-7]

Hey @FelixHerrmann is there anything new about this issue? Thanks in advance :)

[FelixHerrmann]

Hey @martinK-7, interestingly I could no longer produce it with Xcode 16 (tested it with beta 5) and xcodebuild so it might be fixed, would be great if you could test this on your side too; on the other hand swift build still behaves like that, VS Code for example also shows the identifiers:

swift package dump-package is a reliable solution to get the name defined in the manifest and I might consider adding it as an option; tho it is significantly slower and adds complexity because we prob. want to spawn these processes in parallel (each package is 1 process). Let me know if you have other ideas!

[JonnyBeeGod]

~~Hey @FelixHerrmann this is still an issue on our side, even when building with Xcode 16.0 (16A242d). Is a solution relying on swift package dump-package feasible in your opinion?~~

Edit: Problem caused by Xcode build system, not by swift-package-list

[FelixHerrmann]

Hey @JonnyBeeGod, can you roughly explain your stack so I can try to reproduce it? It worked fine for me last week with an Xcode cloud build.

I'm trying to avoid this overhead of managing multiple sub processes where instead we can rely on data that Xcode produces anyways.

[JonnyBeeGod]

Hey @FelixHerrmann after further investigation in turns out that the problem was indeed caused by Xcodes build system building a workspace-state.json with name == identity. This is happening on our side each time we update the app projects package dependencies before executing fastlane scan. Investigation is ongoing on how to prevent this but this is no issue for swift-package-list

[FelixHerrmann]

Alright, I hope you get that sorted on your side!

[pixlwave]

@JonnyBeeGod Did you manage to fix it? We get diffs like this whenever a dependency is updated.

It is easily fixed by resetting package caches, but would love to know if there's a way to stop it happening in the first place.

[FelixHerrmann]

Hey @pixlwave, this is not a fix for the actual problem but there is no need to have the Settings.bundle under source-control if you don't have other settings configured and the generation is constantly invoked by a build-script.

If you use the SPM plugin you can actually remove it entirely from the project, it will be located somewhere in DerivedData and injected automatically in the build process for you.