i’m not sure if there is anyone outside Apple willing to fund this work just yet, but would a solution based around Shallow Git Clones be something likely to be accepted upstream?
3 Likes
There’s support for package registries, the problem is that GitHub said that would be supporting that but they haven’t yet, which complicates adoption. I heard that when AI blew up they de-prioritized pretty much every non-AI initiative.
Tuist recently announced support for the registry. I haven’t tried it yet, and it seems you need an account (free as far as I can see) but they seem to support all packages listed by the Swift Package Index.
1 Like
As I understand it, Tuist's registry operates in support of their "cached dependencies" feature. That is, it's not a full registry that offers general publishing and downloads. Instead, it operates as part of their build process, where your declared packages are published on demand for your future integrations. But I haven't looked too closely at it.
IMO, registries are blocked by the lack of support in Xcode, and the still-missing solution to unique package identity and ownership that is needed to prevent squatting or malicious distribution. (e.g. If package identity is only determined by URL, someone could publish https://somegithost.com/alamofire/Alamofire and be on equal footing with the real one. And if someone else publishes the real Alamofire to a registry, they own it, which is also a big issue.)
2 Likes
This. Our use case is with our own private GitHub repos, and from what I understand even if I’m willing to opt into a less secure model it’s currently not possible for me to configure SwiftPM to perform shallow clones.
The Tuist Registry is not connected to our "cached dependencies" functionality at all. The registry looks at the packages in the Swift Package Index and adds them to the registry by using GitHub as the source of truth. So, any package in the Swift Package Index is available through the Tuist Registry.
You are right we currently don't allow package authors to publish their packages – that's something we've been thinking about and might do in the future, including support for publishing private packages to the registry.
It's possible to use registries from Xcode, although the support in Xcode could certainly be better. We have a fixture project that demonstrates the usage of the (Tuist) registry in a regular Xcode project.
Imho, this is on the centralized registry provider to resolve package "impersonation". It's definitely a solvable problem, such as by using GitHub to check the person publishing a package to your registry has access to the open source package they are publishing. How is package registry different from other centralized package managers like npm or CocoaPods for that matter?
Yes, you currently need an account, but it's completely free. We might consider dropping the account requirement in the future, TBD 
2 Likes
Aside the first check out problem, but for already cached repos resolve/update is very slow: Dependency resolution takes 60+ seconds for projects with 30+ dependencies · Issue #9845 · swiftlang/swift-package-manager · GitHub
The minimal reproducer after I had created the case and re-ran again, it took 2 minutes to complete, while nothing had changed on the dependencies side.
2 Likes