Awesome, thanks @0xTim! Looking forward to digging into this PR, it might take a few days before we get to it, but just wanted to let you know we're excited about this.

@jurre great! There's still a fair bit to do so I'll ping you when it's in a reasonable state!

This is an awesome addition! Excited to see it come together

One thing I'll note: XCode projects will use a Package.resolved file without a Package.swift. The dependencies are directly managed in the XCode UI.

https://developer.apple.com/documentation/xcode/adding-package-dependencies-to-your-app#Coordinate-package-versions-across-your-team

While Swift libraries and "Swift on Server" style projects will use Package.swift to define Swift dependency requirements, XCode projects won't.

Apologies if you've already considered this and chose to require Package.swift for other reasons. I wanted to raise it because this "2 ways of specifying dependencies" model has bitten me before!

@lseppala I would say Xcode projects are out of scope for the time being. I could look into it once the initial support is added but a) it's not a priority for me personally and b) trying to reverse engineer the Xcode project that can change with different Xcode versions might cause more problems. (I'm also half expecting in a couple of years that the Swift Playground app manifest will also be used for Xcode apps)

Hei @0xTim, thanks for this! Swift support is now finally on top of our list and I plan to spend a bit of time getting this into a workable state. Is there any uncommitted work you'd like to share on top of this branch? I'm planning to use this as a starting point.

@deivid-rodriguez just checked and I have several unfinished spikes but nothing worth committing! Do you want to take this over wholesale or is the plan to collaborate and guide the PR through with contributions from me? (Either work to be clear!)

Planning to take this over wholesale, but I'm sure I'll come back with questions about Swift is that's ok with you!

Ok great, reach out and I'll help where I can!

One question @0xTim.

Current implementation resolves each package name from its url, using the Dependabot::Swift::Package::Identifier class, into a <scope>.<name> identifier (for example, mona.linkedlist).

However, I'm observing that the Package.resolved includes a explicit package name too:

{
  "object": {
    "pins": [
      {
        "package": "LinkedList",
        "repositoryURL": "https://github.com/mona/LinkedList.git",
        "state": {
          "branch": null,
          "revision": "79b05a5da89557a4fa50647cc92488a3d9c3f478",
          "version": "1.2.2"
        }
      },
      ...
    ]
  }
}

Do you think it would be more preferable to use that instead (or just the full URL if there's no lockfile)? It seems simpler to me.

My assumption is that Swift either does not allow conflicting package names, or resolves them somehow, saving an unambiguous package name to the lockfile.

Thoughts?

Do you think it would be more preferable to use that instead (or just the full URL if there's no lockfile)? It seems simpler to me.

@deivid-rodriguez IIRC Package.resolved version 1 and 2 refer to this key differently, and one of them actually shows the display name (the one specified in Package.swift instead of its identifier. eg. https://github.com/mona/linked-list can have a display name of LinkedList, but its real identifier is linked-list, derived by the URL.

I like the idea of using the full URL as identifier, but Package.resolved is not so helpful here. If you want to know more context, check out how https://github.com/swift-server/vscode-swift handles package names and identifiers (and how it finally gets there through PR history).

Thanks!

Another question. How do Swift users normally update dependencies?

What I gathered so far is:

• There's no swift command that changes the Package.swift file (for example to relax/update a requirement range to allow a new version). So when you need to update a dependency requirement, you manually edit this file.
• There's a swift package update [package-name] command that updates the Package.resolved file to the latest version that match the requirement in the Package.swift file.
• There's a swift package resolve command that brings the Package.resolved file up to date with the dependency specifications in Package.swift, trying to respect existing versions in Package.resolved as much as possible. I guess that's what you'd normally run after changing dependencies in Package.swift file.

Are the above correct? Is that how users normally manage swift dependencies?

• There's no swift command that changes the Package.swift file (for example to relax/update a requirement range to allow a new version). So when you need to update a dependency requirement, you manually edit this file.

Correct for the time. There was an accepted proposal to add such functionality, but unfortunately it’s not implemented yet. Until that lands developers have to edit the file manually.

• There's a swift package update [package-name] command that updates the Package.resolved file to the latest version that match the requirement in the Package.swift file.

Correct. And there’s also a swift package update command that tries to update the resolved versions to latest for all packages. The result should be identical to running swift package resolve without Package.resolved. IMO this is likely to be the most popular way for updating dependencies during development?

• There's a swift package resolve command that brings the Package.resolved file up to date with the dependency specifications in Package.swift, trying to respect existing versions in Package.resolved as much as possible. I guess that's what you'd normally run after changing dependencies in Package.swift file.

Exactly👍 SwiftPM will check if the resolved packages in Package.resolved matches the dependency graph of Package.swift, and if not it will run the resolver.

Hei!

I'm working on swift updates at #7525, so let's close this PR and move the discussion there. I will add some attribution there to previous contributors of the initial skeleton :)

@steveapple I have some other questions in case you're still happy to help 😄.

@steveapple I have some other questions in case you're still happy to help 😄.

Feel free to mention me:)