Adds the "What is a package registry?" blog post - #4134
Conversation
|
Reviews are welcome but we won't merge this until we're ready to publish it. Ideally tomorrow. |
| ] | ||
| ``` | ||
|
|
||
| During package resolution, SwiftPM clones git-based dependencies from their source repository and checks out a matching tag. It then supplies the source to the compiler, ready to build your app. This is simple and requires no extra infrastructure, but there are inherent disadvantages. Git checkouts can be slow and transfer more data than is needed, and git tags are mutable. SwiftPM uses [Trust on First Use](https://en.wikipedia.org/wiki/Trust_on_first_use) (TOFU) checks that help mitigate problems stemming from mutable tags, but they only catch mutations after first package resolution. |
There was a problem hiding this comment.
May be explicit about how SPM finds and checks out the tag?
There was a problem hiding this comment.
There's quite a bit that this could cover. Were you interested in hitting any specific points?
heckj
left a comment
heckj
left a comment
There was a problem hiding this comment.
A couple of nits for grammar and capitalization, but broadly lovely. After reading this in depth though, I was left with two thoughts:
- Does a registry sort out all the issues with transitive dependencies as well, or does every version you want use in a package need to be pre-loaded somewhere in a registry to begin with? Classic example in my world is "I'm using SwiftNIO..." - and we all know how many dependencies that can cascade into. What's it take to get the "faster download" win for those larger scenarios, and how do I get there?
The biggest wins sound like it's most effective for projects with a lot of dependencies, (or lots of transitive dependencies) after you've done all the lifting to convert your Package, and cajoled or harangued others into updating theirs so that transitive dependencies work as well. (or am I mistaking that's a requirement for transitive deps?)
When done, the download speeds should be faster, so a "package resolve" will be "a lot" (?) faster when you're doing a clean build. Reduced local build times, reduced CI times, etc. Are there secondary wins here that are compelling that we want to highlight? The "immutability" and security perspective, for example?
- The article highlights that there are already registries out there - even ready to use, and support for them - so what's this implementation going to be doing that the others aren't? The "We're going to work on..." setup sort of begs the question that something needs doing, but the suggestion of upcoming work and effort makes me infer that they're potentially lacking in some way, and I'm not clear why or what the gap is. What does "comprehensive" mean in the lede for this article
3043de9 to
4c13a14
Compare
|
|
||
| *Note: This command sets a default package registry for the current project, not [globally](https://github.com/swiftlang/swift-package-manager/blob/main/Documentation/PackageRegistry/PackageRegistryUsage.md#configuring-a-registry).* | ||
|
|
||
| **Step 3:** Switch the dependency. Open the `Package.swift` file and make two changes. Switch the `dependencies` section to use [`package(id:from:)`](https://developer.apple.com/documentation/packagedescription/package/dependency/package(id:from:)) instead of [`package(url:from:)`](https://developer.apple.com/documentation/packagedescription/package/dependency/package(url:from:)): |
There was a problem hiding this comment.
I'm not sure if this blog post is the place to address it but a question this raises (that I don't actually know the answer to), and perhaps not just for me: what does this mean for transient dependencies?
I.e. say apple.swift-argument-parser had dependencies itself in its Package.swift that aren't declared as "registry" dependencies. How can you, or can you even, ensure that all of your dependencies are registry-based?
I'd imagine this is being addressed in the spec, so maybe it's worth a sentence and a link?
… exists for the end of the post.
7f319de to
ef2c5d4
Compare
|
|
||
| ### Depending on a registry-based package | ||
|
|
||
| Here’s the same dependency import from a registry: |
There was a problem hiding this comment.
| Here’s the same dependency import from a registry: | |
| Here’s the same dependency, declared using a registry: |
|
|
||
| ### Why build a package registry? | ||
|
|
||
| Given that you just used a community package registry, you might wonder why we are building a new one. The Tuist registry is a valuable resource for the community as a read-only cache implemented on a registry, and we think there's more value to be had with a full implementation. The key difference is that a fully implemented registry allows packages to be published from SwiftPM using `swift package publish`. It's much more than that, though, involving thinking about developer identity, supply chain security, package scope ownership, release management, and more. |
There was a problem hiding this comment.
| Given that you just used a community package registry, you might wonder why we are building a new one. The Tuist registry is a valuable resource for the community as a read-only cache implemented on a registry, and we think there's more value to be had with a full implementation. The key difference is that a fully implemented registry allows packages to be published from SwiftPM using `swift package publish`. It's much more than that, though, involving thinking about developer identity, supply chain security, package scope ownership, release management, and more. | |
| Given that you just used a community package registry, you might wonder why we are building a new one. The Tuist registry is a valuable resource for the community as a read-only cache implemented as a registry, and we think there's more value in a full implementation. The key difference is that a fully implemented registry allows packages to be published from SwiftPM using `swift package publish`. It's much more than that, though. A full registry involves thinking about developer identity, supply chain security, package scope ownership, release management, and more. |
There was a problem hiding this comment.
A few changes here:
- re: on -> as, I believe this revision is correct, but will defer to the team.
- two additional changes are stylistic / simplification but OK as-is!
5 participants
Uh oh!
There was an error while loading. Please reload this page.