1 00:00:04,110 --> 00:00:06,700 Leo Dion (host): Hello and welcome to another episode at EmpowerApps. 2 00:00:06,720 --> 00:00:08,130 I'm your host, Leo Dion. 3 00:00:08,520 --> 00:00:13,290 Today I am joined by Sven Schmidt and Dave Verwer of Swift Package Index. 4 00:00:13,320 --> 00:00:14,670 Thank you guys for coming on. 5 00:00:14,670 --> 00:00:16,470 You've both been on separately. 6 00:00:16,470 --> 00:00:18,240 This is the first time I've had you on together. 7 00:00:18,422 --> 00:00:19,062 is awesome. 8 00:00:19,062 --> 00:00:20,097 Thank you for doing this. 9 00:00:20,247 --> 00:00:21,177 Dave Verwer (guest): Thanks for having us, Leo. 10 00:00:21,567 --> 00:00:22,047 Hey, Leo. 11 00:00:22,197 --> 00:00:23,837 Yeah, thanks for having us. 12 00:00:24,747 --> 00:00:27,851 Leo Dion (host): Before we begin, I'll let you introduce yourself for 13 00:00:27,851 --> 00:00:31,037 those who don't know what the Swift Package Index is and what you do. 14 00:00:31,937 --> 00:00:32,207 Dave Verwer (guest): Sure. 15 00:00:32,207 --> 00:00:36,826 So my name's Dave Verwer with Sven I run the Swift Package Index. 16 00:00:36,827 --> 00:00:41,762 also run a newsletter called iOS Dev Weekly various other sites have directory. 17 00:00:41,762 --> 00:00:43,982 I always have jobs, basically everything starting with 18 00:00:43,982 --> 00:00:45,593 iOSdev something to do with me, 19 00:00:46,593 --> 00:00:46,983 . Sven A. Schmidt (guest): Yeah. 20 00:00:46,983 --> 00:00:50,703 Hey, I'm, I'm Sven, I'm an indie developer podcaster. 21 00:00:50,793 --> 00:00:54,972 Even most recently we've started out together, Dave and I I've been working on 22 00:00:54,972 --> 00:00:58,902 the Swift Package Index this past almost three years now, together with Dave. 23 00:00:58,902 --> 00:00:59,682 Mm-hmm. 24 00:00:59,688 --> 00:01:00,062 . Awesome. 25 00:01:00,143 --> 00:01:04,077 two other apps that I have, but the Swift Package Index is, is really 26 00:01:04,077 --> 00:01:05,997 the main thing that I'm doing. 27 00:01:06,997 --> 00:01:08,507 Leo Dion (host): So you, do, you do a podcast? 28 00:01:08,507 --> 00:01:12,466 Is this this related to the Twitter spaces or is this something different? 29 00:01:14,251 --> 00:01:15,481 . Dave Verwer (guest): That's certainly how it started. 30 00:01:15,481 --> 00:01:15,781 Yeah. 31 00:01:15,781 --> 00:01:16,935 So we. 32 00:01:17,685 --> 00:01:23,397 decided few months ago now to, to do little Twitter spaces, to to basically 33 00:01:23,417 --> 00:01:26,957 just chat through a little bit of what's been going on with the package 34 00:01:26,962 --> 00:01:31,034 index and then also to recommend some packages that we've seen fast 35 00:01:31,054 --> 00:01:32,434 on the, on the feeds basically. 36 00:01:32,434 --> 00:01:36,124 So whenever packages get updated, We can subscribe to an rss. 37 00:01:36,124 --> 00:01:39,394 In fact, anyone can subscribe to an RSS feed of those updates. 38 00:01:39,454 --> 00:01:42,934 We check over those updates every week and every couple of weeks. 39 00:01:42,934 --> 00:01:47,716 We did a Twitter space to talk about those packages and also talk about what 40 00:01:47,716 --> 00:01:49,076 was happening with the package index. 41 00:01:49,076 --> 00:01:53,768 went down reasonably well, and we decided to kind of upgrade that a little bit 42 00:01:53,768 --> 00:01:57,578 into an actual podcast because we did get some requests for people to Yeah. 43 00:01:57,583 --> 00:01:59,498 Who wanted to listen to it in a podcast player. 44 00:01:59,498 --> 00:02:02,991 So yeah, the last three I think, or three or so episodes have 45 00:02:02,991 --> 00:02:04,791 been proper podcast episodes. 46 00:02:04,821 --> 00:02:05,151 Okay. 47 00:02:05,404 --> 00:02:09,504 we, we experimented with live streaming to YouTube and then we experimented 48 00:02:09,504 --> 00:02:11,484 with stopping live streaming to YouTube. 49 00:02:11,657 --> 00:02:12,867 now it's just a regular. 50 00:02:13,587 --> 00:02:14,037 Podcast. 51 00:02:14,067 --> 00:02:17,382 Yeah, I'm not, we still do have a YouTube version, but, but 52 00:02:17,402 --> 00:02:18,482 the podcast is the main way. 53 00:02:18,482 --> 00:02:18,872 Leo Dion (host): Yeah. 54 00:02:18,912 --> 00:02:19,072 Yeah. 55 00:02:19,072 --> 00:02:20,342 I'm not, I'm not Yeah. 56 00:02:20,672 --> 00:02:24,992 Risky enough to, to willing to do live streams as well with the, with this stuff. 57 00:02:24,992 --> 00:02:26,012 So yeah. 58 00:02:26,017 --> 00:02:28,142 I commend you for doing that experiment. 59 00:02:28,430 --> 00:02:29,120 I gonna say? 60 00:02:29,237 --> 00:02:29,387 Yeah. 61 00:02:29,387 --> 00:02:31,837 Well, I'm glad you didn't go the other route and go to 62 00:02:31,837 --> 00:02:34,387 Clubhouse, I guess, so if that's 63 00:02:34,387 --> 00:02:35,407 Dave Verwer (guest): still a thing, right? 64 00:02:35,467 --> 00:02:35,737 Yes. 65 00:02:35,737 --> 00:02:37,207 Is that still a thing even now 66 00:02:37,477 --> 00:02:40,327 Leo Dion (host): so Dave, you spoke recently at the wonderful 67 00:02:40,327 --> 00:02:44,677 Server-Side Swift conference that Tim Condon had put that seemed like 68 00:02:44,677 --> 00:02:46,177 that conference was a huge success. 69 00:02:46,177 --> 00:02:50,197 Apple revealing that they're open sourcing or making available the 70 00:02:50,197 --> 00:02:51,997 foundation in the library, I believe. 71 00:02:53,677 --> 00:03:00,907 But I want to kind of just do a little brief redux on your talk that you did 72 00:03:00,907 --> 00:03:06,067 on how you accidentally ended up running the largest open source Vapor site. 73 00:03:06,067 --> 00:03:06,807 I love that title. 74 00:03:06,828 --> 00:03:07,369 And 75 00:03:07,859 --> 00:03:10,469 Dave Verwer (guest): so, I mean, one of the jokes that I made in the talk 76 00:03:10,469 --> 00:03:14,919 was if you put enough conditions on anything, you can win any competition. 77 00:03:14,919 --> 00:03:15,719 That's right. 78 00:03:15,724 --> 00:03:15,799 That's right. 79 00:03:16,199 --> 00:03:16,639 . Yeah. 80 00:03:17,729 --> 00:03:22,306 . Open source Vapor . So, yes, it was really, it was really little 81 00:03:22,326 --> 00:03:25,809 bit of history about how the Swift Baggage Index came to be. 82 00:03:26,063 --> 00:03:28,303 it was previous to being a Swift package index. 83 00:03:28,303 --> 00:03:31,266 It was actually a little rails application that was a closed 84 00:03:31,266 --> 00:03:32,866 source rails application initially. 85 00:03:32,983 --> 00:03:36,408 then through a conversation that, and I had over email. 86 00:03:37,248 --> 00:03:40,316 that the Swift Package Index. 87 00:03:40,356 --> 00:03:44,697 And, and it was an open source project from day one because we knew that if, if 88 00:03:44,702 --> 00:03:49,767 it stood any chance of becoming really significantly becoming the place to find 89 00:03:49,767 --> 00:03:52,766 Swift packages, it had to be source. 90 00:03:52,796 --> 00:03:55,046 And if it was gonna be open source for the Swift community, 91 00:03:55,286 --> 00:03:56,346 it had to be written in Swift. 92 00:03:56,626 --> 00:04:00,676 So was, it was very clear immediately that we, that when we were talking 93 00:04:00,676 --> 00:04:06,772 about in fact, , we were talking about redoing it in Swift because of 94 00:04:06,772 --> 00:04:09,558 various other conversations that had gone But it was very clear that it, 95 00:04:09,618 --> 00:04:11,418 that it, it should be a Vapor project. 96 00:04:11,448 --> 00:04:11,658 Leo Dion (host): Yeah. 97 00:04:12,088 --> 00:04:12,148 Yeah. 98 00:04:12,148 --> 00:04:17,520 And of the things that I think you mentioned was the fact that like, Vapor 99 00:04:17,520 --> 00:04:20,850 was, was, what was it at the time, really? 100 00:04:20,960 --> 00:04:26,070 not sure where Kitura had stood, but Perfect, at least had been discontinued. 101 00:04:26,125 --> 00:04:28,155 So it just made an obvious choice. 102 00:04:28,454 --> 00:04:31,024 Dave Verwer (guest): I think as well Spen had some experience with Vapor 103 00:04:31,024 --> 00:04:35,568 already, which was huge bonus because I had actually , I had actually 104 00:04:35,573 --> 00:04:39,118 started, I'd made a new Vapor project, but it was also in that period 105 00:04:39,118 --> 00:04:40,978 between Vapor three and Vapor Four. 106 00:04:42,163 --> 00:04:45,283 I'd made a Vapor three project because there was better 107 00:04:45,343 --> 00:04:46,843 examples and documentation. 108 00:04:47,023 --> 00:04:53,233 But then when Sven kind of came on board with some Vapor experience, everything, 109 00:04:53,293 --> 00:04:54,513 everything changed from that point. 110 00:04:54,513 --> 00:04:57,964 So maybe, maybe Sven Can can talk about it from his perspective. 111 00:04:58,684 --> 00:04:59,104 Sven A. Schmidt (guest): Yeah. 112 00:04:59,104 --> 00:05:01,264 I had been running a small. 113 00:05:01,669 --> 00:05:03,919 Vapor 3 project before in, in production. 114 00:05:03,919 --> 00:05:06,354 Like it was doing a real thing and I had good experience with 115 00:05:06,506 --> 00:05:09,481 But also there was, it was good documentation, which I had worked with. 116 00:05:09,486 --> 00:05:12,781 And the Discord community, the Vapor Discord community was there. 117 00:05:12,781 --> 00:05:13,831 I knew about it. 118 00:05:13,836 --> 00:05:14,701 I, I was in it. 119 00:05:14,714 --> 00:05:17,489 I There'd be enough people to answer questions and, and I 120 00:05:17,494 --> 00:05:20,368 made heavy use of that early on, and that was really helpful. 121 00:05:20,667 --> 00:05:22,847 at the time there weren't really that many other options. 122 00:05:22,847 --> 00:05:24,803 You mentioned couture perfect. 123 00:05:24,803 --> 00:05:29,033 Which was sort of, you know, if not already discontinued on the way out. 124 00:05:29,543 --> 00:05:31,793 Smoke I don't think existed yet. 125 00:05:31,798 --> 00:05:36,143 Amazon's smoke and, and Hummingbird by Adam Fowler didn't exist yet either. 126 00:05:36,143 --> 00:05:37,103 So Vapor. 127 00:05:37,563 --> 00:05:40,993 Pretty obviously obvious thing to pick if it's swift spec'd. 128 00:05:41,013 --> 00:05:47,399 I had previously run two Python services in Flask and also another one in Django. 129 00:05:47,419 --> 00:05:50,114 So I had some experience running that kind of service. 130 00:05:50,918 --> 00:05:55,353 I think that was also similar, but I have to say in hindsight, I would definitely 131 00:05:55,353 --> 00:06:00,113 pick Vapor and Swift over these, over these backend frameworks because. 132 00:06:00,145 --> 00:06:04,600 of issues that I faced with the Vapor, with the Python based services we 133 00:06:04,600 --> 00:06:06,430 don't actually have in production. 134 00:06:06,430 --> 00:06:09,850 Like I remember fighting with Python and the service just dying, running 135 00:06:09,850 --> 00:06:11,110 out of memory, that sort of stuff. 136 00:06:11,350 --> 00:06:13,980 We don't see any of that with with the Vapor Service. 137 00:06:13,980 --> 00:06:15,490 It's rock solid in production. 138 00:06:15,560 --> 00:06:20,150 runtime issues just don't exist because they are compiled home issues in Swift. 139 00:06:20,286 --> 00:06:22,006 works just really, really well. 140 00:06:22,036 --> 00:06:24,346 I think some smaller. 141 00:06:24,961 --> 00:06:30,241 issues early on we had mostly around foundation not being exactly a 142 00:06:30,241 --> 00:06:33,271 hundred percent the same between macOS, where we develop and 143 00:06:33,271 --> 00:06:35,131 Linux where we, where we deploy. 144 00:06:35,641 --> 00:06:35,971 Yeah. 145 00:06:36,331 --> 00:06:41,371 But once you sort of know what, these are mostly around formats 146 00:06:41,371 --> 00:06:43,111 and stuff, you can work around it. 147 00:06:43,111 --> 00:06:44,371 Plus UCI catches that. 148 00:06:44,371 --> 00:06:46,591 I mean, you're never going to accidentally ship that. 149 00:06:46,591 --> 00:06:47,101 Right, right. 150 00:06:47,101 --> 00:06:48,061 In Python, that might be a problem. 151 00:06:48,061 --> 00:06:51,106 You know, you, you don't hit that code path, you ship it and 152 00:06:51,106 --> 00:06:52,156 then in production you hit it. 153 00:06:52,156 --> 00:06:55,906 But the compiler makes sure you can't actually ship that sort of stuff in Swift. 154 00:06:55,906 --> 00:06:58,728 So I, I think it, it works really well. 155 00:06:58,825 --> 00:07:03,435 The, the, the other downside perhaps is that the package ecosystem doesn't 156 00:07:03,435 --> 00:07:06,405 have the same depth as it does on other platforms that are older. 157 00:07:06,465 --> 00:07:09,595 You know, like Ruby, Ruby on Rails, Python again. 158 00:07:09,796 --> 00:07:10,756 guess also go. 159 00:07:11,756 --> 00:07:16,706 , I don't think breadth is necessarily what's lacking in Swift. 160 00:07:16,706 --> 00:07:20,666 I, you might argue that there aren't many variants of different services, 161 00:07:20,666 --> 00:07:22,076 you know, to, to choose from. 162 00:07:22,676 --> 00:07:27,056 But of all the stuff that we've been doing, there's always been a package, 163 00:07:27,386 --> 00:07:30,416 and that package has, has pretty much always been really high quality. 164 00:07:30,686 --> 00:07:34,046 You didn't have like five to choose from, you know, three of which 165 00:07:34,046 --> 00:07:37,286 might be questionable and, and not maintain, but you had often had that 166 00:07:37,286 --> 00:07:38,766 one and, and that was good enough. 167 00:07:39,268 --> 00:07:43,173 mean, our service is probably not the most edge, you know, the, 168 00:07:43,383 --> 00:07:45,003 you know, on the bleeding edge. 169 00:07:45,003 --> 00:07:47,823 We're not, we're not doing authentication at the moment beyond 170 00:07:47,823 --> 00:07:50,108 some, some basic basic types. 171 00:07:50,126 --> 00:07:53,216 We're not doing image video uploading, transcoding, that sort of 172 00:07:53,216 --> 00:07:57,476 stuff, but I know others are, and, and it, it works perfectly fine. 173 00:07:58,076 --> 00:07:58,256 Yeah. 174 00:07:58,256 --> 00:07:58,706 Talk to the 175 00:07:58,706 --> 00:07:59,636 Leo Dion (host): folks at Amazon. 176 00:08:01,466 --> 00:08:01,976 . Dave Verwer (guest): Exactly. 177 00:08:01,976 --> 00:08:02,096 Yeah. 178 00:08:02,186 --> 00:08:03,926 I think there's, and Tim, yeah, I think there's two 179 00:08:03,926 --> 00:08:05,226 sides to this question as well. 180 00:08:05,440 --> 00:08:12,110 first is certainly Vapor and running a web application on Swift is a very stable 181 00:08:12,115 --> 00:08:14,349 environment the, to, to in production. 182 00:08:14,354 --> 00:08:18,314 And, and we've seen that over, over years now of, of running the site. 183 00:08:19,004 --> 00:08:21,481 But I think the other side of it is we also. 184 00:08:22,396 --> 00:08:25,306 Build a lot of stuff into making sure that's the case. 185 00:08:25,396 --> 00:08:30,750 So extensive test suite monitoring, good logging and a lot of those 186 00:08:30,990 --> 00:08:33,630 tools really help that reliability. 187 00:08:33,720 --> 00:08:37,650 It wouldn't be unreliable without those, but it's more than just 188 00:08:37,650 --> 00:08:38,820 picking the right framework. 189 00:08:38,825 --> 00:08:42,690 It's, it's how you approach development of your entire service. 190 00:08:42,690 --> 00:08:45,120 I think that that makes a stable service. 191 00:08:45,660 --> 00:08:46,020 Leo Dion (host): Yeah. 192 00:08:46,080 --> 00:08:50,250 And one of the things I remember spend when I had you on was talking about 193 00:08:50,250 --> 00:08:53,850 some of those libraries that you use, like prometheus and snapshot testing 194 00:08:53,947 --> 00:08:57,907 make sure that the site is running and doing, you know, is staying stable. 195 00:08:59,537 --> 00:09:00,027 Yeah. 196 00:09:01,057 --> 00:09:01,417 . Sven A. Schmidt (guest): Yeah. 197 00:09:01,477 --> 00:09:05,437 And, and one of the reasons why I'm so confident that Swift is better, you know, 198 00:09:05,467 --> 00:09:09,577 from my experience with, as opposed to the Python frameworks, is because we 199 00:09:09,577 --> 00:09:11,437 did exactly the same things in Python. 200 00:09:11,497 --> 00:09:13,597 I mean, I'm, I'm a test driven nurse, okay? 201 00:09:13,867 --> 00:09:17,917 I, I do that in all projects because otherwise I can't, I feel I can't 202 00:09:17,922 --> 00:09:19,807 deploy unless I've run a test suite. 203 00:09:19,807 --> 00:09:24,457 So I have these in place and, and yet still I see a lot of issues not appearing 204 00:09:24,457 --> 00:09:26,977 in Swift, that that did appear in Python. 205 00:09:28,102 --> 00:09:29,287 . So yeah, that's, that's my 2 206 00:09:29,287 --> 00:09:29,872 Leo Dion (host): cents on that. 207 00:09:30,082 --> 00:09:30,442 Yeah. 208 00:09:30,442 --> 00:09:32,452 And I think this is the gear. 209 00:09:32,482 --> 00:09:35,152 If you're, I, this is probably the second year I've said this, 210 00:09:35,152 --> 00:09:38,782 but like, yeah, I mean, there's no reason not to go with a server side 211 00:09:38,782 --> 00:09:40,302 backend and swift at this point. 212 00:09:40,507 --> 00:09:40,987 So 213 00:09:41,187 --> 00:09:43,392 Sven A. Schmidt (guest): is it the year of Swift on the server? 214 00:09:43,482 --> 00:09:43,722 Well, that 215 00:09:43,722 --> 00:09:46,692 Leo Dion (host): was, that was the episode I did last year and I can't, I can't 216 00:09:46,692 --> 00:09:48,252 do that again, unfortunately with Tim. 217 00:09:48,257 --> 00:09:48,527 So, 218 00:09:49,145 --> 00:09:53,280 Dave Verwer (guest): This last year has been all about documentation and not 219 00:09:53,280 --> 00:09:58,648 the documentation of the Swift package index, but so a little while ago I 220 00:09:58,648 --> 00:10:01,298 can't remember exactly when it was, but it was probably almost a year ago. 221 00:10:01,304 --> 00:10:03,935 We shipped the first version of. 222 00:10:04,195 --> 00:10:08,915 DocC documentation generation support on the package index. 223 00:10:09,005 --> 00:10:11,255 So just a quick recap of what that is. 224 00:10:12,665 --> 00:10:17,795 If you have a Swift package that is already in the package index and if your 225 00:10:17,800 --> 00:10:22,295 Swift files have documentation comments that DocC would understand and would 226 00:10:22,295 --> 00:10:26,315 produce documentation from, and of course you can test that locally with Xcode. 227 00:10:27,110 --> 00:10:28,130 Swift Package manager. 228 00:10:28,140 --> 00:10:34,026 Locally you can indicate to the Swift package index that we should build 229 00:10:34,026 --> 00:10:36,576 and host your package documentation. 230 00:10:37,506 --> 00:10:41,599 and we do a couple of things, which think in my, my opinion, takes 231 00:10:41,599 --> 00:10:45,079 us above and beyond, beyond even what, what people would potentially 232 00:10:45,079 --> 00:10:46,657 set up with their systems. 233 00:10:46,847 --> 00:10:51,687 So the first thing that we do is all you really need to tell us is what 234 00:10:51,692 --> 00:10:56,007 target or targets that you would like documentation to be generated for. 235 00:10:56,832 --> 00:11:00,702 . And then as we do our compatibility builds because behind the package 236 00:11:00,702 --> 00:11:05,502 index is a full, almost a kind of full CI system for every package 237 00:11:05,712 --> 00:11:11,381 where we verify compatibility with platforms swift versions by building 238 00:11:11,561 --> 00:11:14,261 each package hundreds of times. 239 00:11:14,596 --> 00:11:21,091 the end of that process, we tacked on the documentation generation step, so, Package 240 00:11:21,091 --> 00:11:26,431 authors have let us know that there are three documented targets in a package. 241 00:11:27,031 --> 00:11:31,171 As we build that package, we'll also generate documentation, upload 242 00:11:31,171 --> 00:11:33,811 it, and host it automatically. 243 00:11:33,841 --> 00:11:35,851 Like literally, you don't need to do anything apart from, 244 00:11:36,091 --> 00:11:38,521 from it's awesome targets. 245 00:11:38,791 --> 00:11:39,151 Yeah. 246 00:11:39,421 --> 00:11:42,082 And then secondly we keep every version. 247 00:11:43,072 --> 00:11:43,852 Documentation. 248 00:11:43,972 --> 00:11:48,770 So as your package is moved forward through releases and especially major 249 00:11:48,770 --> 00:11:53,382 releases we, we update the documentation every time you release a package. 250 00:11:53,802 --> 00:11:57,192 And then also if you upgrade a major version, version two to version 251 00:11:57,192 --> 00:12:01,212 three, for example, we'll keep the old major version, the latest 252 00:12:01,212 --> 00:12:05,022 old major versions documentation around and put it in a little 253 00:12:05,022 --> 00:12:07,152 dropdown on your documentation site. 254 00:12:07,152 --> 00:12:11,632 So when you make breaking API changes, Generally get indicated 255 00:12:11,632 --> 00:12:14,302 by a major version change. 256 00:12:14,752 --> 00:12:16,792 We'll keep that old version around for you. 257 00:12:16,822 --> 00:12:19,972 And again, all of that just happens completely automatically. 258 00:12:20,182 --> 00:12:22,582 You just release your versions and that's it. 259 00:12:22,582 --> 00:12:22,942 It's done. 260 00:12:23,062 --> 00:12:28,002 So that's a, a very quick recap of what the feature does. 261 00:12:28,104 --> 00:12:32,879 of course, To provide that level of simplicity for the end user 262 00:12:32,939 --> 00:12:34,319 and also for the package author. 263 00:12:35,249 --> 00:12:38,490 There's an enormous amount of work maybe can talk a little bit about 264 00:12:38,572 --> 00:12:40,887 of the stuff that we've, we've worked on with that this year. 265 00:12:41,457 --> 00:12:41,817 Right. 266 00:12:41,817 --> 00:12:42,027 Yeah. 267 00:12:42,027 --> 00:12:44,397 Sven A. Schmidt (guest): So the, the DocC hosting, as Dave mentioned 268 00:12:44,397 --> 00:12:46,107 is, is a tack onto the build system. 269 00:12:46,107 --> 00:12:49,915 And, and the tricky bit there is, you know, to pick which targets actually 270 00:12:50,255 --> 00:12:53,968 the docs are built for the uploading to S3 for that, and especially 271 00:12:53,968 --> 00:12:57,808 the proxying around because we, we are adding a, a custom header. 272 00:12:57,808 --> 00:13:01,168 The, the thing that Dave just described, the bar on the, on the top of it, 273 00:13:01,618 --> 00:13:05,068 where you have a chooser of which target you're viewing docs for, and. 274 00:13:05,893 --> 00:13:07,093 Which version you're looking at. 275 00:13:07,234 --> 00:13:11,194 normal DocC site doesn't have any of that, so we have to fiddle a bit with the 276 00:13:11,284 --> 00:13:13,052 structure of the webpage to inject that. 277 00:13:13,333 --> 00:13:17,445 just to mer make everything work with us hosting that site you know, 278 00:13:17,495 --> 00:13:21,155 and, and doing the redirecting and, and proxying of all those URLs. 279 00:13:22,025 --> 00:13:22,715 Well, I was just gonna 280 00:13:22,715 --> 00:13:27,251 Leo Dion (host): say the DocC building is fantastic on Swift Package Index. 281 00:13:27,251 --> 00:13:31,856 Set up stuff with Netlify on hosting my documentation. 282 00:13:31,886 --> 00:13:35,366 But like the fact that you do automatically, and like Dave said, 283 00:13:35,366 --> 00:13:38,486 has all these quirks with like major version, I didn't even think of that. 284 00:13:38,516 --> 00:13:41,336 Like yeah, if you update to a new major version, you have breaking changes. 285 00:13:41,336 --> 00:13:43,676 Like people might wanna pull up the old docs. 286 00:13:44,246 --> 00:13:46,066 Just yesterday, speaking of like put. 287 00:13:46,556 --> 00:13:52,046 I updated an old repo that I had and renamed it, and like I was able to 288 00:13:52,046 --> 00:13:56,326 get this DocC documentation working in minutes, and it's fantastic. 289 00:13:56,426 --> 00:13:57,016 That's great to have. 290 00:13:57,016 --> 00:13:57,496 Yeah. 291 00:13:57,501 --> 00:14:01,614 I want to jump a little bit and talk about you add a 292 00:14:01,614 --> 00:14:04,329 package, two Swift package index. 293 00:14:04,329 --> 00:14:05,049 It's simple. 294 00:14:05,259 --> 00:14:07,969 You know, Dave, you're a big fan of doing pull requests. 295 00:14:08,385 --> 00:14:09,365 that's, that's it. 296 00:14:09,365 --> 00:14:10,085 That's all you have to do. 297 00:14:10,085 --> 00:14:12,405 You put it in a pull request, it's still almost working. 298 00:14:12,745 --> 00:14:14,105 It's awesome. 299 00:14:14,105 --> 00:14:15,892 And like you have to do. 300 00:14:15,897 --> 00:14:18,262 But then there's some custom quirks that. 301 00:14:18,937 --> 00:14:22,975 You know, swift package Index, like you said, DocC You know, we've talked about, 302 00:14:22,975 --> 00:14:27,715 I think watch kit testing, which used to be a thing, but now it's native anyways. 303 00:14:27,955 --> 00:14:31,328 But there's a few things that you can do in swift Package Index to 304 00:14:31,328 --> 00:14:36,288 customize using this like YAML file you've set up, you want to explain 305 00:14:37,748 --> 00:14:39,818 what that, what purpose that serves. 306 00:14:39,818 --> 00:14:39,908 Sure. 307 00:14:39,938 --> 00:14:43,138 And how it works with Swift Package Index. 308 00:14:44,908 --> 00:14:51,118 Dave Verwer (guest): So, from the very beginning we had w w we knew that at 309 00:14:51,123 --> 00:14:56,278 some point we would need ways for package authors to tell us bits of metadata 310 00:14:56,518 --> 00:14:59,878 that we might need to know that were was outside of the Package.swift file.. 311 00:14:59,878 --> 00:15:03,318 Because obviously we get a lot of, we had as much as we can from. 312 00:15:04,423 --> 00:15:08,473 the package manifest, and also services like GitHub, where packages are hosted. 313 00:15:08,473 --> 00:15:08,543 Mm-hmm. 314 00:15:09,064 --> 00:15:13,594 . we knew proposing changes to the package manifest is a long and 315 00:15:13,624 --> 00:15:15,064 slow process as it should be. 316 00:15:15,064 --> 00:15:18,503 You know, we shouldn't be, we shouldn't be changing that file every, every , but 317 00:15:18,503 --> 00:15:22,093 that we'd need a way for package authors to be able to tell us various bits of 318 00:15:22,243 --> 00:15:23,873 metadata that was not covered by that. 319 00:15:23,873 --> 00:15:29,172 Originally I think the idea for the Swift YAML file came from us 320 00:15:29,177 --> 00:15:31,872 wanting to add author support, which we recently just added. 321 00:15:32,022 --> 00:15:34,332 So I'm actually just gonna go off a slight tangent. 322 00:15:34,332 --> 00:15:34,902 Yeah, go for it. 323 00:15:34,902 --> 00:15:36,482 Talk about this. 324 00:15:37,022 --> 00:15:41,828 We Swift package Index participated in the Swift Mentorship program again this year. 325 00:15:41,828 --> 00:15:46,539 So we had two mentees come on board and implement features. 326 00:15:46,882 --> 00:15:50,801 We was mentoring one, and I mentored the other, and my mentee 327 00:15:51,011 --> 00:15:54,521 basically he implemented author support for the swift package index. 328 00:15:54,521 --> 00:15:59,354 So passing out git history, finding the most people with the most commits 329 00:15:59,474 --> 00:16:03,584 deciding who was like a significant author based on an algorithm and. 330 00:16:04,284 --> 00:16:06,864 putting that information live on, on the site. 331 00:16:07,104 --> 00:16:10,674 But then of course with anything automated, it's gonna get it wrong 332 00:16:10,884 --> 00:16:15,294 sometimes or get history as maybe not as accurate as, as people 333 00:16:15,294 --> 00:16:19,051 or it do maybe doesn't represent who actually wrote package. 334 00:16:19,191 --> 00:16:23,421 And so we wanted a way for people to be able to override what 335 00:16:23,631 --> 00:16:25,221 the automated system had done. 336 00:16:25,551 --> 00:16:30,921 And again, we used the Swift package index YAML file to allow package authors to say, 337 00:16:30,921 --> 00:16:36,986 actually your author information that you've kind of derived isn't quite right. 338 00:16:37,166 --> 00:16:40,612 Here's the string you should put to say who wrote this so even though that 339 00:16:40,612 --> 00:16:45,006 feature has only just recently been implemented we've had the idea for that 340 00:16:45,006 --> 00:16:50,511 feature a very long time ago, and so we knew that we'd need this package 341 00:16:50,560 --> 00:16:52,755 Swift package index YAML file to do that. 342 00:16:53,115 --> 00:16:57,385 But then the first time it actually got used was when the compatibility build. 343 00:16:57,616 --> 00:16:58,236 being developed. 344 00:16:58,236 --> 00:17:03,007 So we I think it was the very first thing we needed to do was custom targets. 345 00:17:03,007 --> 00:17:03,457 Is that 346 00:17:03,603 --> 00:17:04,037 Sven A. Schmidt (guest): Schemes. 347 00:17:04,057 --> 00:17:04,917 Schemes, schemes. 348 00:17:04,917 --> 00:17:05,427 Yeah. 349 00:17:05,497 --> 00:17:05,737 Yeah. 350 00:17:05,787 --> 00:17:06,507 It was schemes. 351 00:17:06,507 --> 00:17:09,627 I, I remember, well, we were still, we had an open discussion. 352 00:17:09,717 --> 00:17:12,767 We had an issue in our GitHub talking about what the format 353 00:17:12,767 --> 00:17:13,727 should be of that file. 354 00:17:13,727 --> 00:17:15,497 And you can imagine what that discussion was like. 355 00:17:15,947 --> 00:17:18,057 , you know, oh, don't use YAML, use JSON. 356 00:17:18,077 --> 00:17:19,067 Well, JSON is terrible. 357 00:17:19,072 --> 00:17:22,327 You can't have comments use TOML and you know, , while the 358 00:17:22,327 --> 00:17:23,617 discussion was still brewing. 359 00:17:24,097 --> 00:17:27,933 We really just needed some way of, of authors to tell us scheme to use 360 00:17:27,938 --> 00:17:29,343 because you mentioned it earlier. 361 00:17:29,538 --> 00:17:32,778 There was one issue that you couldn't build on watch os if there was a, 362 00:17:32,898 --> 00:17:34,463 I think if there was a test, right? 363 00:17:34,717 --> 00:17:35,802 Because of, yeah, 364 00:17:35,802 --> 00:17:39,052 Leo Dion (host): you had needed, you had the example of the point free I 365 00:17:39,052 --> 00:17:40,642 think it was composable architecture. 366 00:17:40,672 --> 00:17:41,872 Sven A. Schmidt (guest): Yeah, exactly. 367 00:17:41,992 --> 00:17:42,142 Right. 368 00:17:42,622 --> 00:17:46,822 And the way we, in the build system we had, we sort of had to, we, what 369 00:17:46,827 --> 00:17:49,372 we're doing is we're guessing which scheme is the right one to build. 370 00:17:49,372 --> 00:17:51,352 There are often many, and we just pick one. 371 00:17:51,862 --> 00:17:55,242 Certain heuristics, they sometimes fail and it's less and less common, 372 00:17:55,242 --> 00:17:58,372 but especially early on, people needed a way to tell us just use 373 00:17:58,372 --> 00:17:59,692 this scheme for this platform. 374 00:18:00,382 --> 00:18:04,882 So effectively we say, all right, YAML, it is . Everyone's gonna be unhappy, 375 00:18:04,882 --> 00:18:08,902 but this one is, this is what we're going to choose just to get this fixed. 376 00:18:08,902 --> 00:18:12,292 And, and that's how this file was born and has lived ever since. 377 00:18:12,362 --> 00:18:13,052 Pretty much. 378 00:18:14,042 --> 00:18:14,704 Leo Dion (host): So 379 00:18:14,704 --> 00:18:15,319 Dave Verwer (guest): yeah, go ahead Dave. 380 00:18:15,319 --> 00:18:16,489 And it's done us really well. 381 00:18:16,691 --> 00:18:20,359 terms We've expanded the amount of metadata that package authors 382 00:18:20,359 --> 00:18:22,245 can to that file over time. 383 00:18:22,245 --> 00:18:25,414 And that's also where package authors us which targets our 384 00:18:25,414 --> 00:18:26,754 documents and that kind of thing. 385 00:18:26,810 --> 00:18:30,725 There's two main advantages of doing this file in this way is we could have made 386 00:18:30,725 --> 00:18:37,145 a system where package authors needed to authenticate on packaging next.com, log 387 00:18:37,150 --> 00:18:40,895 in, and maybe they get a web view where they can say, oh, it's these targets, 388 00:18:40,900 --> 00:18:43,775 and it's, you know, this is the correct author information and that kind of thing. 389 00:18:44,435 --> 00:18:48,305 But because everything comes from a Git repository, that's the 390 00:18:48,310 --> 00:18:53,675 source of truth for everything to, to have some of the metadata. 391 00:18:54,310 --> 00:18:59,920 Somewhere else, maybe behind a specific site, never really felt right to me. 392 00:19:00,100 --> 00:19:04,245 And to have that as a YAML file in the package repository 393 00:19:04,290 --> 00:19:05,875 feels like the right solution. 394 00:19:05,880 --> 00:19:09,625 It also means that any other tools can also look at that file because 395 00:19:09,645 --> 00:19:11,685 it's just a file in a git repository. 396 00:19:11,695 --> 00:19:14,852 think as far as I'm aware, we are the only, we are the app 397 00:19:14,852 --> 00:19:16,072 that does look at that file. 398 00:19:16,218 --> 00:19:18,918 certainly it felt right to have that metadata. 399 00:19:19,888 --> 00:19:21,198 In the package repository. 400 00:19:21,403 --> 00:19:25,903 course there are downsides to it because it's much more difficult 401 00:19:25,903 --> 00:19:30,344 to tell people that they should go looking at the package documentation. 402 00:19:30,369 --> 00:19:32,439 And actually, just to go off on another tangent, go for it. 403 00:19:32,439 --> 00:19:37,947 The other mentorship project Sven with his was to document that file. 404 00:19:37,947 --> 00:19:39,807 So maybe you can talk about a bit about that Sven.. 405 00:19:40,707 --> 00:19:41,127 Sven A. Schmidt (guest): Yeah. 406 00:19:41,127 --> 00:19:45,207 I mean, this has been, this, this popped up quite a few times that. 407 00:19:46,182 --> 00:19:49,692 You know, knew there was this file, but they didn't know what the format 408 00:19:49,692 --> 00:19:53,112 was, what the, what the actual things are that you can put in it. 409 00:19:53,172 --> 00:19:56,832 And we had a blog post that introduced it and a couple bits and bobs here 410 00:19:56,832 --> 00:20:00,942 and there, but no central place to actually host more document. 411 00:20:00,942 --> 00:20:04,062 I mean, the obvious central place is obviously the package index, but 412 00:20:04,512 --> 00:20:08,322 we never actually put up a a page on it that explained that file better. 413 00:20:09,042 --> 00:20:15,327 And then we kind of thought, well, , we had just built a doc system and we 414 00:20:15,327 --> 00:20:21,487 had pushed all of the, the specs that, like the SPI YAML file is 415 00:20:21,487 --> 00:20:25,007 actually Codable struct that is behind it is in a separate package 416 00:20:25,187 --> 00:20:27,257 that we have in the, in our GitHub. 417 00:20:27,497 --> 00:20:31,817 So it's Swift package index slash SPI manifest, and the 418 00:20:31,817 --> 00:20:33,377 package is actually in the index. 419 00:20:33,377 --> 00:20:38,207 And then the obvious thing was to just add documentation, oxy documentation, have it 420 00:20:38,207 --> 00:20:43,892 generated through the index, and thenpoint towards that documentation in the index. 421 00:20:43,892 --> 00:20:46,426 And that's what Azza worked towards 422 00:20:46,456 --> 00:20:46,836 actually 423 00:20:46,897 --> 00:20:50,329 Sven A. Schmidt (guest): adding docs to that package such that we can host 424 00:20:50,334 --> 00:20:54,289 it and then direct people towards that file and have Nice, it has examples now. 425 00:20:54,294 --> 00:20:56,059 We chose, you know, what things you can do. 426 00:20:56,089 --> 00:20:56,329 Yeah. 427 00:20:56,479 --> 00:20:58,669 How you add to, I actually, I mean, that's the thing. 428 00:20:58,879 --> 00:21:01,609 I had snippets lying around to tell people what to do, and now 429 00:21:01,609 --> 00:21:03,409 finally I can , I can look it up 430 00:21:04,249 --> 00:21:04,639 Leo Dion (host): myself. 431 00:21:04,669 --> 00:21:04,999 Did you. 432 00:21:05,564 --> 00:21:09,134 Did you really deep dive into DocC and like do tutorials and 433 00:21:09,134 --> 00:21:10,484 articles and things like that? 434 00:21:10,484 --> 00:21:13,889 Or did you just stick stay with like, document, like just swift comments? 435 00:21:14,889 --> 00:21:16,899 Sven A. Schmidt (guest): Yeah, it's, it's, this is just a, it has 436 00:21:16,899 --> 00:21:18,879 a intro just marked down pages. 437 00:21:18,884 --> 00:21:18,899 Yeah. 438 00:21:18,899 --> 00:21:19,019 Okay. 439 00:21:19,019 --> 00:21:23,319 I mean, it's obviously the, the structure is documented to a certain degree, but 440 00:21:23,379 --> 00:21:28,179 the main documentation for this kind of thing has to be a markdown file 441 00:21:28,179 --> 00:21:32,804 describing or what the purpose is and, and you know, I think the, the most 442 00:21:32,804 --> 00:21:35,864 interesting page there is common use cases where we describe, you know, what 443 00:21:35,864 --> 00:21:38,264 do I do if I want to override the scheme? 444 00:21:38,324 --> 00:21:40,694 Okay, what do I do if I want to override the target? 445 00:21:40,754 --> 00:21:42,014 How to add documentation? 446 00:21:42,014 --> 00:21:42,614 That sort of thing. 447 00:21:42,614 --> 00:21:42,964 Yeah, yeah, yeah. 448 00:21:42,969 --> 00:21:44,924 Because those are the main questions people ask. 449 00:21:45,073 --> 00:21:47,133 Leo Dion (host): One of the big improvements it sounds like you wanna do 450 00:21:47,138 --> 00:21:49,993 this year is to searching on the site. 451 00:21:49,993 --> 00:21:54,499 do you wanna explain how it works now and what you're hoping to do in 2023? 452 00:21:55,499 --> 00:21:56,609 Dave Verwer (guest): Well, I think actually. 453 00:21:58,439 --> 00:22:00,869 , I think what you're potentially referring to is a change that we've 454 00:22:00,869 --> 00:22:04,791 already made , and again, this was a this was a contribution the 455 00:22:04,791 --> 00:22:06,701 open source project from Joe Heck. 456 00:22:06,740 --> 00:22:11,615 So Joe noticed some problems when he was searching for think he, 457 00:22:11,635 --> 00:22:13,525 was he searching for Ping or ftp? 458 00:22:13,525 --> 00:22:14,204 One of the two. 459 00:22:14,220 --> 00:22:14,860 Yeah, both of them. 460 00:22:14,980 --> 00:22:15,100 Yeah. 461 00:22:15,100 --> 00:22:16,300 Those were those. 462 00:22:17,350 --> 00:22:17,920 . Those are the two. 463 00:22:18,070 --> 00:22:19,823 Yeah, those are the two problems. 464 00:22:19,823 --> 00:22:23,968 Both of those have very ambiguous not ambiguous, that's the wrong word, but 465 00:22:23,988 --> 00:22:28,817 both of those phrases occur in lots of other words in ways that you wouldn't Yes. 466 00:22:28,867 --> 00:22:33,637 And it was putting potentially terrible search results to the top of the list. 467 00:22:33,811 --> 00:22:36,411 so he originally reported it. 468 00:22:37,236 --> 00:22:37,896 as an issue. 469 00:22:37,986 --> 00:22:41,836 And we talked about it a little bit, but he was also interested in in, 470 00:22:41,896 --> 00:22:43,346 doing some work to, to solve it. 471 00:22:43,346 --> 00:22:48,982 And he did some amazing work with looking at some of the Postgres search commands 472 00:22:49,408 --> 00:22:52,808 I forget the name of technology, maybe span remembers what other 473 00:22:52,808 --> 00:22:53,888 things that they've broken up into. 474 00:22:53,888 --> 00:22:54,338 Stemming the 475 00:22:54,338 --> 00:22:55,208 Leo Dion (host): heuristics. 476 00:22:55,538 --> 00:22:55,898 Okay. 477 00:22:55,988 --> 00:22:56,258 Dave Verwer (guest): Yeah. 478 00:22:56,408 --> 00:22:57,818 Stemming and stemming. 479 00:22:57,848 --> 00:22:58,988 There was something else as well. 480 00:22:58,988 --> 00:23:00,008 I can't remember what it was. 481 00:23:00,038 --> 00:23:00,368 Yeah. 482 00:23:00,422 --> 00:23:06,539 And, so that landed few months ago And what it does in, in real terms is make. 483 00:23:07,044 --> 00:23:11,872 Vastly improved search results where if you type ftp it's more, much 484 00:23:11,872 --> 00:23:15,262 more likely now to show you things that are about FTP instead of that 485 00:23:15,262 --> 00:23:16,492 being part of some of the word. 486 00:23:16,512 --> 00:23:16,792 Okay. 487 00:23:17,092 --> 00:23:17,692 Sven A. Schmidt (guest): That's really cool. 488 00:23:17,692 --> 00:23:17,752 Yeah. 489 00:23:17,752 --> 00:23:21,202 Just maybe to explain by, by example what the problem was. 490 00:23:21,352 --> 00:23:25,612 So imagine you search for, for Ping, you get all sorts of hits 491 00:23:25,612 --> 00:23:30,112 from mapping, you know, ing being ping, being a pretty common ending. 492 00:23:30,682 --> 00:23:32,842 Ftp, likewise Swift package. 493 00:23:33,532 --> 00:23:36,322 ftp, swift FTP package. 494 00:23:36,322 --> 00:23:36,382 Yeah. 495 00:23:36,382 --> 00:23:36,682 Right. 496 00:23:36,832 --> 00:23:39,322 You know, when that's spelled together, you get hits like that. 497 00:23:39,322 --> 00:23:41,452 They have nothing to do with what you were actually looking for. 498 00:23:42,052 --> 00:23:47,281 So what you can do is have run an index does word stemming so it, it 499 00:23:47,281 --> 00:23:51,211 breaks up words and, and discards endings that aren't actually, you 500 00:23:51,211 --> 00:23:54,041 know, part parts of the world really. 501 00:23:54,071 --> 00:23:54,341 Right. 502 00:23:54,492 --> 00:23:58,172 that then gives you good search results if you, if you ranked by those, it was a 503 00:23:58,172 --> 00:24:02,762 bit more complicated than that because we had to weave it into our existing search 504 00:24:02,767 --> 00:24:06,652 and our, you know, we want to preserve a lot of aspects of our current search. 505 00:24:06,658 --> 00:24:08,064 Joe did a lot of work. 506 00:24:08,069 --> 00:24:13,339 I mean, Joe actually wrote a SwiftUI app that took searches that he'd. 507 00:24:14,224 --> 00:24:15,294 , which he had captured. 508 00:24:15,414 --> 00:24:18,594 So he captured the ranking, had a Swift UI app to actually look at 509 00:24:18,594 --> 00:24:20,064 those results and to compare them. 510 00:24:20,344 --> 00:24:21,814 He went all in on that. 511 00:24:21,819 --> 00:24:22,924 That's awesome because it was amazing. 512 00:24:23,014 --> 00:24:26,764 Leo Dion (host): Is this, and this all works within Vapor and Fluent or like, 513 00:24:26,764 --> 00:24:29,284 was there some customization in there? 514 00:24:31,084 --> 00:24:33,184 Sven A. Schmidt (guest): So what saves us here is that 515 00:24:33,184 --> 00:24:34,894 you can drop down to pure sql. 516 00:24:35,224 --> 00:24:35,464 Okay. 517 00:24:35,464 --> 00:24:36,454 I mean, I, I'm sure you. 518 00:24:37,744 --> 00:24:42,244 potentially write this in, not in fluent, but in, there's, there are 519 00:24:42,249 --> 00:24:43,953 other layers in Vapor below flu. 520 00:24:43,973 --> 00:24:48,365 Right, right, SQLKit, for instance, where you can, you know, write your 521 00:24:48,459 --> 00:24:50,579 SQL functions and then assemble them. 522 00:24:51,449 --> 00:24:58,319 But in this case, in search, we are really assemble what we're using. 523 00:24:58,349 --> 00:25:01,939 We are using SQLKit, but a lot of SQL RAW as well that we then assemble. 524 00:25:02,519 --> 00:25:04,349 that's how we build up the, the search string. 525 00:25:04,349 --> 00:25:08,898 And it's effectively going through a materialized view to keep it fast. 526 00:25:09,168 --> 00:25:10,158 Yeah, that makes total sense. 527 00:25:10,758 --> 00:25:13,188 But this sort of stuff you can't, you can't do with 528 00:25:13,188 --> 00:25:13,518 Leo Dion (host): fluent. 529 00:25:13,568 --> 00:25:13,928 Yeah. 530 00:25:14,088 --> 00:25:14,478 Yeah. 531 00:25:14,778 --> 00:25:17,838 You can get into the raw sequel, which sounds like what you guys 532 00:25:17,838 --> 00:25:19,528 did and it makes sense with search. 533 00:25:19,628 --> 00:25:20,038 ahead Dave. 534 00:25:20,113 --> 00:25:22,613 Dave Verwer (guest): And the nice thing about being able to talk about this on, on 535 00:25:22,613 --> 00:25:28,073 a podcast is that that kind of work that Joe did on that is really thankless, like. 536 00:25:29,678 --> 00:25:34,908 He did an enormous amount of work to get that pull request in and, and, and, 537 00:25:34,958 --> 00:25:38,048 and to improve the search on the site. 538 00:25:38,978 --> 00:25:42,908 And to anybody using the site, it still just produces search results, right? 539 00:25:42,968 --> 00:25:47,210 You only that, that's the kind of change where only really notice when 540 00:25:47,210 --> 00:25:51,830 it goes wrong and it, the fact that nobody noticed is, is a great testament 541 00:25:51,830 --> 00:25:53,390 to how good that changed from Joe was. 542 00:25:53,420 --> 00:25:53,480 Yeah. 543 00:25:53,600 --> 00:25:54,170 That's a, that's 544 00:25:54,170 --> 00:25:54,650 Leo Dion (host): awesome. 545 00:25:56,330 --> 00:25:59,610 . So one of the other things you've talked about quite a bit is the 546 00:25:59,610 --> 00:26:03,531 whole we, we just got this whole infrastructure, I believe it was June 547 00:26:03,531 --> 00:26:06,116 of this year with Swift package plugins. 548 00:26:06,656 --> 00:26:10,766 What, what are you doing with Swift package plugins and Swift Package 549 00:26:10,771 --> 00:26:15,216 Index and how, how, how do those two, what's their relationship, I guess? 550 00:26:16,806 --> 00:26:19,308 Sven A. Schmidt (guest): we've passed this package manifests the whole time. 551 00:26:19,308 --> 00:26:22,358 And, and plugins are a new type of product that appeared 552 00:26:22,446 --> 00:26:24,216 when they, when they came live. 553 00:26:24,846 --> 00:26:27,696 But initially we were blind to them because they weren't 554 00:26:27,696 --> 00:26:28,896 a product that we knew. 555 00:26:29,041 --> 00:26:31,962 So we had to had to change that to actually ingest But I think that 556 00:26:31,962 --> 00:26:36,492 happened pretty early on because if I recall correctly, not passing them 557 00:26:36,492 --> 00:26:40,062 led to, you know, the packages with plugins actually failing to index. 558 00:26:40,572 --> 00:26:41,977 So that was an obvious thing to do. 559 00:26:42,707 --> 00:26:46,636 But of the things that, that was also a contributing change . and 560 00:26:46,676 --> 00:26:48,376 was support for plugin search. 561 00:26:48,451 --> 00:26:52,206 So you may not know we have certain extensions on search. 562 00:26:52,206 --> 00:26:56,384 You can obviously search for terms, but you can also apply little qualifiers. 563 00:26:56,454 --> 00:27:01,404 So for instance, platform colon iOS, which, you know, lists packages 564 00:27:01,404 --> 00:27:02,754 that are compatible with iOS. 565 00:27:02,809 --> 00:27:04,199 But we also have a. 566 00:27:04,207 --> 00:27:07,057 , product colon and then executable product colon library. 567 00:27:07,087 --> 00:27:08,638 And then product colon Mine, plugin. 568 00:27:08,692 --> 00:27:10,812 Added a support for product colon plugin. 569 00:27:10,817 --> 00:27:14,622 And then you can search for, for plugins, you know, you can just search 570 00:27:14,622 --> 00:27:18,411 for product colon plugin that lists you all the packages with plugin. 571 00:27:18,751 --> 00:27:22,051 The package index knows about, and you can obviously add other 572 00:27:22,051 --> 00:27:25,751 search terms in addition to that, to to filter that down further. 573 00:27:25,751 --> 00:27:29,561 that was really cool because that allowed us early on to, to see, you 574 00:27:29,561 --> 00:27:33,073 know, to expose what plugins they actually are and see them, you know, 575 00:27:33,073 --> 00:27:37,033 the lists grow over the months as they, as they started appearing. 576 00:27:37,693 --> 00:27:40,213 Leo Dion (host): What are some quirks that you found with plugins that 577 00:27:40,213 --> 00:27:43,213 you didn't have to run into besides just the new product type I guess 578 00:27:43,763 --> 00:27:46,223 ? Sven A. Schmidt (guest): I don't think there were any problems really. 579 00:27:46,273 --> 00:27:50,983 Well actually, let me qualify that one issue that is, is there, now that 580 00:27:50,988 --> 00:27:54,368 I think of it that is there, and I don't think there's a, an obvious 581 00:27:54,368 --> 00:27:57,320 fix is compatibility of plugins. 582 00:27:57,350 --> 00:27:57,620 Okay. 583 00:27:57,830 --> 00:28:02,315 Because what do you actually We currently build a package 584 00:28:03,205 --> 00:28:04,795 to determine compatibility. 585 00:28:04,795 --> 00:28:07,795 I'm not actually sure what happens if you run Swift Build on a. 586 00:28:08,995 --> 00:28:09,835 Plugin package. 587 00:28:10,825 --> 00:28:10,855 Okay. 588 00:28:10,855 --> 00:28:12,827 Will it just, will it actually build anything? 589 00:28:12,842 --> 00:28:16,082 Would you actually need to use it to, to determine compatibility? 590 00:28:16,082 --> 00:28:19,502 I'm, I'm a bit hazy what would actually happen, but I do recall that we had 591 00:28:19,502 --> 00:28:24,062 packages being flagged and people said, well, is this should be compatible, 592 00:28:24,062 --> 00:28:26,612 but sort of isn't doing the thing. 593 00:28:26,612 --> 00:28:30,952 But I think they had an example in, in their repository that we then built. 594 00:28:31,522 --> 00:28:33,462 But the plugin was actually attached to that. 595 00:28:33,792 --> 00:28:35,442 So I'm not sure what the state there is. 596 00:28:36,552 --> 00:28:39,012 I don't think it's a currently not a common enough problem 597 00:28:39,012 --> 00:28:40,833 to be, to be an issue. 598 00:28:40,995 --> 00:28:45,265 because plugins are sort of a dependency when you use them. 599 00:28:45,265 --> 00:28:45,355 Mm-hmm. 600 00:28:45,745 --> 00:28:46,105 , right? 601 00:28:46,315 --> 00:28:49,315 But then you're gonna also not because they, they do something in your 602 00:28:49,315 --> 00:28:54,375 project, but they're mostly not part of your built product in the end. 603 00:28:54,405 --> 00:28:54,675 Right? 604 00:28:55,180 --> 00:29:00,370 There is no code that lands in your, in your package from the plugin 605 00:29:00,370 --> 00:29:03,430 unless the plugin transforms code and that that's then gets added. 606 00:29:03,936 --> 00:29:06,891 So I think they're a bit weird in terms of are they, are they 607 00:29:06,891 --> 00:29:08,751 dependencies in that, in that sense? 608 00:29:08,806 --> 00:29:11,296 And how do you test for compatibility in that sense, I guess? 609 00:29:11,296 --> 00:29:11,506 Yeah, 610 00:29:12,106 --> 00:29:15,046 Dave Verwer (guest): and I think the other thing with compatibility around plugins is 611 00:29:15,828 --> 00:29:21,258 it's never going to be easy or potentially never even gonna be possible to represent 612 00:29:21,348 --> 00:29:26,778 the full spectrum of compatibility, of every part of every package. 613 00:29:26,778 --> 00:29:29,028 Is this Pluggin compatible with this platform? 614 00:29:29,268 --> 00:29:34,533 Like even just representing that data would be extremely challenging. 615 00:29:34,773 --> 00:29:37,538 And then for people to read that data and get what they need from, it 616 00:29:37,568 --> 00:29:39,668 also needs to be relatively simple. 617 00:29:39,668 --> 00:29:39,758 Right. 618 00:29:39,788 --> 00:29:43,448 And I, I would, ima I think in, in my head at least what we have right now 619 00:29:43,453 --> 00:29:46,178 with that grid is at the very top end. 620 00:29:47,023 --> 00:29:49,628 of how complex we want compatibility to look. 621 00:29:49,748 --> 00:29:52,808 I would not want it to be any more complex than it currently is. 622 00:29:52,898 --> 00:29:56,798 In fact, I would like to simplify that a little bit if we can over time. 623 00:29:56,803 --> 00:29:57,098 Right, right. 624 00:29:57,098 --> 00:29:57,848 And that makes sense. 625 00:29:58,268 --> 00:30:02,318 And so, yes, we may not capture some of the intricacies of, well, this 626 00:30:02,323 --> 00:30:07,478 package is compatible with iOS, but this plug-in needs macOS, or you know what? 627 00:30:07,508 --> 00:30:10,058 Whatever there are, there are always gonna be things there that 628 00:30:10,058 --> 00:30:14,539 we might not be able to To people who are looking for a package. 629 00:30:14,730 --> 00:30:18,560 so there's a limit to how far we can really go down that path, 630 00:30:18,620 --> 00:30:21,230 or at least how far we can go without making things to companies, 631 00:30:21,540 --> 00:30:21,780 Leo Dion (host): right? 632 00:30:21,785 --> 00:30:22,550 Yeah, exactly. 633 00:30:23,000 --> 00:30:27,496 So I wanna talk a little bit about the future of the Swift Package Index. 634 00:30:27,525 --> 00:30:29,965 In our last episode one of the things we were talking about 635 00:30:29,965 --> 00:30:34,260 is registry is becoming more and more wide known and used. 636 00:30:34,260 --> 00:30:39,360 And it sounds like you're doing something with that for Swift package Index in 2023, 637 00:30:39,497 --> 00:30:39,727 Dave Verwer (guest): Yeah. 638 00:30:39,727 --> 00:30:43,334 So think 2023 will be the year that people start to hear a little 639 00:30:43,334 --> 00:30:44,734 bit more about package registries. 640 00:30:45,138 --> 00:30:48,728 registries have been, or the idea for a package registry in Swift has 641 00:30:48,728 --> 00:30:53,198 been around for a few years now, and in fact, in 5.7 the client, 642 00:30:53,198 --> 00:30:54,668 the Swift Package manager client. 643 00:30:55,193 --> 00:31:00,593 Gained full support for package registries, but it's probably worth 644 00:31:00,593 --> 00:31:03,383 talking a little bit about what the difference is between a package 645 00:31:03,388 --> 00:31:05,123 registry and a package index. 646 00:31:05,123 --> 00:31:08,573 Before we go too further, but too much further, because that's certainly going 647 00:31:08,573 --> 00:31:13,103 to be something that people may not have been aware of yet because package 648 00:31:13,103 --> 00:31:17,153 registries have been, you would've heard of them if you were like super 649 00:31:17,153 --> 00:31:18,743 in the weeds on package manager. 650 00:31:19,148 --> 00:31:20,858 but most people are just using packages, right? 651 00:31:20,858 --> 00:31:20,918 Yeah. 652 00:31:20,918 --> 00:31:24,218 And they just put a git URL in and off it goes, and everything works. 653 00:31:24,458 --> 00:31:28,898 So a package registry and there can be multiple package registries. 654 00:31:29,018 --> 00:31:31,838 The Swift package manager supports multiple package registries. 655 00:31:31,838 --> 00:31:34,458 So GitHub could run a package registry. 656 00:31:34,458 --> 00:31:36,048 Apple could run a package registry. 657 00:31:36,048 --> 00:31:37,518 Amazon could run a package registry. 658 00:31:38,588 --> 00:31:41,298 BrightDigit could run their own internal package registry. 659 00:31:41,298 --> 00:31:42,138 You're in my mind. 660 00:31:42,138 --> 00:31:42,288 Yeah. 661 00:31:42,288 --> 00:31:43,528 I was just thinking about better. 662 00:31:43,528 --> 00:31:44,928 I was like, yeah, I should try that out. 663 00:31:45,928 --> 00:31:50,998 . The, the, the, the, the concept of a registry is, is there's no centralized 664 00:31:51,058 --> 00:31:53,305 place by definition for a registry. 665 00:31:53,785 --> 00:31:57,085 And the registry takes care of all the hard stuff, basically. 666 00:31:57,085 --> 00:31:57,835 So it takes. 667 00:31:58,420 --> 00:32:03,867 Delivering package data it takes care verifying that the contents of 668 00:32:03,867 --> 00:32:09,667 package data is, is signed and secure and, and verifiably not tampered with 669 00:32:09,697 --> 00:32:13,450 since the package author of certified it, which is a problem that is 670 00:32:13,450 --> 00:32:18,555 currently the current implementation package manager has that problem 671 00:32:18,555 --> 00:32:23,006 where basically if you tag a version That's the version that the package 672 00:32:23,006 --> 00:32:25,196 manager takes as a specific version. 673 00:32:25,466 --> 00:32:27,146 But with git tags, they're mutable, right? 674 00:32:27,146 --> 00:32:32,450 So you could move a tag around and, and potentially one person who's 675 00:32:32,450 --> 00:32:36,110 using your package at this version has different code to another person that's 676 00:32:36,110 --> 00:32:36,780 Leo Dion (host): using the packages. 677 00:32:36,780 --> 00:32:40,980 As somebody who's developed Swift packages, I've run, I've done, I've tagged 678 00:32:40,985 --> 00:32:42,270 something and then been like, oh crap. 679 00:32:42,270 --> 00:32:46,427 Like forgot to do this and this, and then I have to go in and I have to delete my. 680 00:32:46,982 --> 00:32:49,862 Package cash, which is horrible. 681 00:32:49,867 --> 00:32:51,752 If you've ever done that, don't ever do that unless you 682 00:32:51,757 --> 00:32:53,512 absolutely need to on your machine. 683 00:32:53,604 --> 00:32:56,424 yeah, I've totally, I, I totally know where you're coming from on that. 684 00:32:57,424 --> 00:32:58,894 Dave Verwer (guest): So, package registries are gonna 685 00:32:58,894 --> 00:33:00,574 solve a lot of these problems. 686 00:33:00,649 --> 00:33:04,524 But they, it, it'll mean that you're no longer putting git your URLs 687 00:33:04,524 --> 00:33:08,244 into your package manifest because instead of getting it from a Git 688 00:33:08,244 --> 00:33:12,564 repository, you'll be getting the package from a package registry. 689 00:33:12,697 --> 00:33:16,647 so there's some changes, you know, I mean, these are these changes even 690 00:33:16,652 --> 00:33:20,082 though they're supported by the current version of package manager, they're 691 00:33:20,442 --> 00:33:23,082 probably a little way down the road because what Apple announced recently 692 00:33:23,082 --> 00:33:28,620 was that they are going to build a implementation of the package, a 693 00:33:28,620 --> 00:33:32,755 package registry server that will be compatible with the package manager. 694 00:33:32,885 --> 00:33:36,678 So apple are open source developing this package. 695 00:33:36,678 --> 00:33:37,138 The only 696 00:33:37,143 --> 00:33:38,658 Leo Dion (host): catch is they get 15%. 697 00:33:39,468 --> 00:33:42,738 You know, I don't know if you, you wanna use that, registry? 698 00:33:43,008 --> 00:33:44,388 Sorry, I had to make that joke. 699 00:33:44,388 --> 00:33:44,928 15%. 700 00:33:44,928 --> 00:33:45,438 I had to make that 701 00:33:45,443 --> 00:33:45,528 Dave Verwer (guest): joke. 702 00:33:46,248 --> 00:33:50,808 15% of all the, of all the revenue goes to open sources and actually got brought 703 00:33:52,058 --> 00:33:54,498 Leo Dion (host): somebody, one of the, one of the owners is just 704 00:33:54,498 --> 00:33:55,728 like, oh yeah, that's a good idea. 705 00:33:55,728 --> 00:33:58,548 Without any knowledge of, you know, that's open sources. 706 00:33:59,628 --> 00:34:02,413 Dave Verwer (guest): It's a little bit different to the app store where where it 707 00:34:02,413 --> 00:34:04,963 is a, a, a platform based on transactions. 708 00:34:05,153 --> 00:34:10,573 It open source software is, is a little different that .So what, how, 709 00:34:10,643 --> 00:34:11,687 where does that leave the package? 710 00:34:11,730 --> 00:34:15,970 . good news is we are going to fully support package registries as soon as they 711 00:34:15,972 --> 00:34:17,819 become a thing that's out in the wild. 712 00:34:17,968 --> 00:34:19,018 So we will. 713 00:34:19,288 --> 00:34:22,318 Obviously you have to, and the Swift package manager will also 714 00:34:22,778 --> 00:34:24,478 continue to support, get your URLs. 715 00:34:24,483 --> 00:34:28,078 I I can imagine it's going to support get your URLs probably forever. 716 00:34:28,078 --> 00:34:28,878 Yeah, hopefully. 717 00:34:28,878 --> 00:34:33,348 Leo Dion (host): I, just sort of segue question, but like, one of the things I've 718 00:34:33,348 --> 00:34:37,278 found with a lot of other registries out there, well not registries, but other. 719 00:34:37,818 --> 00:34:42,119 Languages, especially npm and know Cocoapods had run into this too, is like, 720 00:34:42,119 --> 00:34:47,339 anytime you have one central registry, there's always like room for trouble. 721 00:34:47,339 --> 00:34:50,429 And what I've liked about Swift is that it relies, and you probably like this 722 00:34:50,434 --> 00:34:55,330 too, but like it relies on get repo URLs, whereas's so it sounds to me like what 723 00:34:55,330 --> 00:34:56,890 what you're saying is like a registry. 724 00:34:56,895 --> 00:35:01,690 You can add that as a dependency with like, A qualifier saying that 725 00:35:01,690 --> 00:35:05,980 it's this specific package in this registry as opposed to the github url. 726 00:35:05,980 --> 00:35:06,760 Is that correct? 727 00:35:07,510 --> 00:35:07,810 Okay. 728 00:35:07,890 --> 00:35:08,090 Yes. 729 00:35:08,620 --> 00:35:08,910 Okay. 730 00:35:09,492 --> 00:35:13,282 Dave Verwer (guest): And, then you, it'll pull in so the, the, they'll 731 00:35:13,282 --> 00:35:14,442 still, we will, we will still use. 732 00:35:14,992 --> 00:35:18,562 Get repositories to store our source code, but they'll, there will now 733 00:35:18,562 --> 00:35:20,332 be this kind of intermediate step. 734 00:35:20,332 --> 00:35:23,962 And how that all falls out is probably, we're probably a little bit premature 735 00:35:23,962 --> 00:35:27,272 talking about that now because we, we, we haven't seen what they're gonna develop. 736 00:35:27,585 --> 00:35:29,315 the package index. 737 00:35:30,170 --> 00:35:34,679 Is going to be a centralized place because at some point if you are 738 00:35:34,679 --> 00:35:39,479 gonna deal with discovery and search for multiple package registries, you 739 00:35:39,479 --> 00:35:43,469 need to have one place where all of those registries can be searched. 740 00:35:43,499 --> 00:35:44,939 Otherwise, you'd need to go. 741 00:35:44,944 --> 00:35:47,504 If you were looking for a package, you'd need to go to each registry. 742 00:35:47,570 --> 00:35:49,625 Not that searches even a part of a registry. 743 00:35:49,625 --> 00:35:51,505 It's not part of the, the registry spec. 744 00:35:51,505 --> 00:35:53,353 It search is search is not there. 745 00:35:54,733 --> 00:35:58,603 , we'll still need something to gather metadata from. 746 00:35:58,663 --> 00:36:02,023 Get your URLs and package registries, bring it all together and make it 747 00:36:02,023 --> 00:36:06,228 searchable and allow packages to be discovered matter where they're hosted. 748 00:36:06,288 --> 00:36:06,768 Awesome. 749 00:36:07,608 --> 00:36:08,238 And that's what we'll 750 00:36:08,238 --> 00:36:08,508 Leo Dion (host): take down. 751 00:36:08,508 --> 00:36:09,063 That's awesome. 752 00:36:10,093 --> 00:36:10,413 Yeah. 753 00:36:10,643 --> 00:36:13,728 haven't dived into, but now I think I might dive into 754 00:36:13,728 --> 00:36:15,028 registries on how they work. 755 00:36:15,692 --> 00:36:18,782 like that I think will increase obviously your audience. 756 00:36:18,782 --> 00:36:20,732 I assume your audience continues to grow. 757 00:36:20,732 --> 00:36:21,762 You can see that, right? 758 00:36:21,919 --> 00:36:24,299 people are using swift packages more and more. 759 00:36:24,415 --> 00:36:25,205 definitely. 760 00:36:26,140 --> 00:36:29,680 Dave Verwer (guest): Yeah, we, we've seen consistent and, and 761 00:36:29,680 --> 00:36:31,790 steady ever since we launched. 762 00:36:31,790 --> 00:36:32,090 Really. 763 00:36:32,090 --> 00:36:35,360 And in fact, I was just looking at something earlier today, and 764 00:36:35,360 --> 00:36:39,060 our traffic has increased by over 50% since August last year. 765 00:36:39,602 --> 00:36:43,602 So we are growing, we're, we're, we are growing really nicely, which is great. 766 00:36:43,662 --> 00:36:47,502 What, and that, I mean, that I think proves two things. 767 00:36:47,502 --> 00:36:52,032 It proves that what we're producing is useful, but it also. 768 00:36:52,632 --> 00:36:55,512 I think mirrors the adoption of sif Package Manager. 769 00:36:55,542 --> 00:37:02,601 I think as we go through you CocoaPods was, and still is totally dominant 770 00:37:02,691 --> 00:37:04,894 in terms of and macOS projects. 771 00:37:04,894 --> 00:37:09,064 It was just, that was the way that you imported Carthridge was there as 772 00:37:09,064 --> 00:37:12,774 well, but I, Carthage never really got the adoption that Cocoa Pods did. 773 00:37:12,866 --> 00:37:16,509 And, I think we can see clearly. 774 00:37:16,533 --> 00:37:20,493 Now that package manager is, is gaining huge amounts of adoption. 775 00:37:20,733 --> 00:37:23,883 CocoaPods is gonna be around for a very, very long time because 776 00:37:23,883 --> 00:37:27,693 there are lots of projects that will not upgrade until there's a 777 00:37:27,693 --> 00:37:28,993 reason that they have to upgrade. 778 00:37:28,993 --> 00:37:29,703 Leo Dion (host): Right, right. 779 00:37:29,708 --> 00:37:32,223 You still have objective C stuff out that will be different there. 780 00:37:32,373 --> 00:37:34,503 If you have anything that's subjective based course, like 781 00:37:34,503 --> 00:37:36,483 you have to be on Cocoa Pods. 782 00:37:36,843 --> 00:37:37,203 That's it. 783 00:37:37,203 --> 00:37:38,163 There's nothing out there. 784 00:37:40,053 --> 00:37:42,093 , Dave Verwer (guest): but I think we're certainly seeing package 785 00:37:42,093 --> 00:37:45,030 manager take more share of that market 786 00:37:45,718 --> 00:37:48,338 Leo Dion (host): Anything else you want to talk about that's coming out this year? 787 00:37:48,590 --> 00:37:54,322 Dave Verwer (guest): think we could talk a little bit about maybe what yeah, yeah. 788 00:37:54,392 --> 00:37:56,102 Let's talk a little bit about what we're planning to do over this. 789 00:37:56,222 --> 00:37:56,462 Yeah. 790 00:37:57,572 --> 00:37:57,962 , Leo Dion (host): go ahead. 791 00:37:58,022 --> 00:37:58,152 Yeah, 792 00:37:58,577 --> 00:38:02,117 , . Dave Verwer (guest): think one thing that, that, oh, sorry. 793 00:38:02,117 --> 00:38:02,327 Go on. 794 00:38:02,327 --> 00:38:02,537 Sorry. 795 00:38:03,977 --> 00:38:06,321 Sven A. Schmidt (guest): No, I was just maybe picking up on the DocC 796 00:38:06,346 --> 00:38:09,976 stuff that we talked about earlier because seen a lot of adoption. 797 00:38:10,093 --> 00:38:13,953 just checked earlier, we've got 270 packages now that are 798 00:38:13,953 --> 00:38:17,286 hosting documentation with us, which is, that's great. 799 00:38:17,291 --> 00:38:22,094 That's more than We have, however, seen some issues with some of those packages 800 00:38:22,094 --> 00:38:26,114 because they are, they generate very large dock setss and that is something that 801 00:38:26,114 --> 00:38:30,714 is, that is a , a feature of, of DocC. 802 00:38:30,734 --> 00:38:36,524 It produces a lot of small files and they, they add up. 803 00:38:37,064 --> 00:38:41,614 one package in particular has, is, is so large and has so many files that it, it. 804 00:38:42,589 --> 00:38:46,339 in our current setup, impossible to manage, to upload it within our timeouts 805 00:38:46,819 --> 00:38:50,209 that we currently, can you tell me what it is In our bill system ? is swift syntax. 806 00:38:50,209 --> 00:38:51,919 It's Apple Swift Syntax package. 807 00:38:51,983 --> 00:38:52,171 Okay. 808 00:38:52,641 --> 00:38:52,821 Okay. 809 00:38:52,881 --> 00:38:55,221 And it's the nature of the package. 810 00:38:55,221 --> 00:38:58,911 I mean, there's, it's, it's not, it's not the authors or the packages 811 00:38:58,911 --> 00:39:00,711 fold, it's just the nature Yeah. 812 00:39:00,771 --> 00:39:01,461 If a package, 813 00:39:01,461 --> 00:39:02,391 Leo Dion (host): I've looked at that before. 814 00:39:02,391 --> 00:39:04,171 Yeah, I can, I can see where that's coming from. 815 00:39:05,541 --> 00:39:05,811 . Sven A. Schmidt (guest): Yeah. 816 00:39:06,141 --> 00:39:08,811 Every symbol that's so committed generates a adjacent file. 817 00:39:08,841 --> 00:39:08,931 Mm-hmm. 818 00:39:09,351 --> 00:39:10,191 with data in it. 819 00:39:10,191 --> 00:39:12,531 It's like, like a couple hundred kilobytes. 820 00:39:12,651 --> 00:39:17,361 It's not, but because every function has that, every method, every attribute, 821 00:39:18,051 --> 00:39:23,211 it's, it has 117,000 files that doc set and is, is, is a gigabyte large, 822 00:39:23,231 --> 00:39:28,836 which, isn't crazy, but because we need to build the package, build 823 00:39:28,836 --> 00:39:33,126 the documentation, and upload it all within a maximum of 15 minutes. 824 00:39:34,086 --> 00:39:38,303 that that is just not enough So we have to work around that sort of stuff. 825 00:39:38,303 --> 00:39:42,725 And we're also hoping that so we are part of the documentation working group we have 826 00:39:42,785 --> 00:39:47,405 flagged this, and they are, people are aware that it's, they are some problems 827 00:39:47,410 --> 00:39:51,860 with the, with the size, the sheer size of Doxies doc sets tremendously. 828 00:39:51,885 --> 00:39:55,215 If, if, you know, that would be one way to, to, you know, 829 00:39:55,215 --> 00:39:56,325 bring the size down a bit. 830 00:39:57,135 --> 00:40:00,525 But there are also things that we can do to offload that whole 831 00:40:00,825 --> 00:40:06,105 process and, you know, not try and sync 117,000 files in that job. 832 00:40:06,105 --> 00:40:06,225 Yeah. 833 00:40:07,155 --> 00:40:10,575 But rather zip it up, upload one file elsewhere, and then have 834 00:40:10,575 --> 00:40:14,295 a, have a job with more time budget, deal with the upload. 835 00:40:14,295 --> 00:40:15,435 And that's what we're currently working. 836 00:40:16,525 --> 00:40:19,915 , but these are the sort of things that pop up when you've shipped the feature and 837 00:40:19,915 --> 00:40:25,408 then it gains adoption and you, you see all sorts of, you know, Edge cases pop 838 00:40:25,408 --> 00:40:26,938 up, and that's, that's just the way it is. 839 00:40:26,938 --> 00:40:29,268 So that's something we are, we are dealing with right now. 840 00:40:29,315 --> 00:40:32,650 another very interesting thing that came out of our participation in a 841 00:40:32,650 --> 00:40:36,465 documentation working group, and that's preview of upcoming DocC features. 842 00:40:37,035 --> 00:40:39,436 So DocC shipped in its first version 843 00:40:39,436 --> 00:40:41,271 That's two WWDC. 844 00:40:41,291 --> 00:40:41,771 Yeah, of course. 845 00:40:41,771 --> 00:40:45,311 Because in June, June last year, we shipped the, the DocC hosting. 846 00:40:45,311 --> 00:40:48,154 So it was a year old But it's, it's still pretty young. 847 00:40:48,159 --> 00:40:51,439 So there has have been lots of things that have been added since. 848 00:40:51,576 --> 00:40:57,014 most recently there was a, a feature by Sophia Rodriguez which is a, a 849 00:40:57,019 --> 00:40:58,284 search popup, which is really nice. 850 00:40:58,284 --> 00:41:01,872 So if you are on a DocC Works set, you can I think it's just forward 851 00:41:01,872 --> 00:41:06,937 slash you know, Command popups you get when you have Launch bar or Raycast. 852 00:41:07,387 --> 00:41:09,787 So you have a dedicated search that you can bring up and then you 853 00:41:09,787 --> 00:41:11,557 just start, you know, type search. 854 00:41:11,557 --> 00:41:12,907 As you type, you get results. 855 00:41:13,587 --> 00:41:14,847 You know, that's awesome. 856 00:41:15,297 --> 00:41:16,587 Which is really great. 857 00:41:16,587 --> 00:41:16,767 Yeah. 858 00:41:16,767 --> 00:41:20,367 And we've, so we've set up a preview system of that 859 00:41:20,397 --> 00:41:22,777 feature with a preview of DocC. 860 00:41:22,797 --> 00:41:26,972 This is like a nightly five eight chain where we've, where we're, we are 861 00:41:27,272 --> 00:41:31,652 previewing that and we hope, we hope to get this rolled out potentially before 862 00:41:31,652 --> 00:41:33,912 five, eight chips in, I guess the spring. 863 00:41:34,492 --> 00:41:34,573 Right. 864 00:41:34,573 --> 00:41:36,675 that's the sort of stuff we're working towards and hoping. 865 00:41:37,140 --> 00:41:40,450 Do you able to pull forward so people can, can have this feature 866 00:41:40,450 --> 00:41:43,057 you on the Swift package index as as. 867 00:41:44,292 --> 00:41:47,202 Leo Dion (host): Are you doing anything with like quality or maintenance scores? 868 00:41:47,202 --> 00:41:48,252 Because that's a big thing. 869 00:41:48,252 --> 00:41:53,382 I use Shields io and I like to post those badges in my repos showing how 870 00:41:53,382 --> 00:41:57,325 good, good of a developer what is it, a well-behaved developer I am when 871 00:41:57,325 --> 00:41:59,425 it comes to maintenance and quality 872 00:41:59,425 --> 00:41:59,815 Dave Verwer (guest): scores. 873 00:41:59,820 --> 00:42:02,485 Well, I can vouch for how, for how Well that, yeah, yeah, yeah. 874 00:42:02,485 --> 00:42:02,825 Thank you. 875 00:42:03,119 --> 00:42:05,499 Leo Dion (host): you wanna do something like that with Swift package Index? 876 00:42:07,224 --> 00:42:07,854 Dave Verwer (guest): It certainly. 877 00:42:07,854 --> 00:42:13,464 So I, I think one thing that is on my mind at the moment is that we 878 00:42:13,464 --> 00:42:18,254 built the Swift package Index where it shows metadata and we built that. 879 00:42:19,104 --> 00:42:22,554 , you know, a couple of years ago now, and then we decided to 880 00:42:22,554 --> 00:42:24,139 tackle compatibility systems. 881 00:42:24,139 --> 00:42:29,719 So we ended up going deep into this, this huge build system that we have 882 00:42:29,719 --> 00:42:31,039 hanging off the back of the packaging. 883 00:42:31,039 --> 00:42:33,953 Then index and it, it feeds compatibility results back. 884 00:42:34,223 --> 00:42:37,433 And then we added to that with documentation generation. 885 00:42:37,943 --> 00:42:40,733 , we've not, I mean, there's been various improvements of course, 886 00:42:40,913 --> 00:42:46,043 but I, I, I'm conscious that we haven't done much on the actual core 887 00:42:46,103 --> 00:42:47,633 package page for a little while now. 888 00:42:48,231 --> 00:42:51,237 for example, we did some initial work on dependencies. 889 00:42:51,237 --> 00:42:55,005 And we are pulling in resolved dependencies for every package and 890 00:42:55,010 --> 00:42:56,385 we have that stored in the database. 891 00:42:56,495 --> 00:42:59,845 we're not really doing a lot with that data. 892 00:42:59,966 --> 00:43:03,408 we also, that data kind of comes with some tricky things. 893 00:43:03,408 --> 00:43:05,808 Like for example, if. 894 00:43:07,188 --> 00:43:12,948 test target declares a dependency, and we are maybe showing how 895 00:43:12,948 --> 00:43:15,258 many dependencies a package has. 896 00:43:15,978 --> 00:43:19,158 Do people want to know about test dependencies? 897 00:43:19,163 --> 00:43:24,018 I think most people are primarily concerned with what dependencies a package 898 00:43:24,018 --> 00:43:26,178 has that might ev eventually end up 899 00:43:26,418 --> 00:43:28,818 Leo Dion (host): in their application products, executables, et cetera. 900 00:43:28,878 --> 00:43:29,148 Yeah. 901 00:43:31,098 --> 00:43:34,803 Dave Verwer (guest): And so there's a lot work to be done there on. 902 00:43:35,343 --> 00:43:39,783 A, an, an intelligent display of how those dependencies actually affect 903 00:43:40,053 --> 00:43:41,913 what you bring in with a package. 904 00:43:41,918 --> 00:43:42,173 Okay? 905 00:43:42,363 --> 00:43:44,793 We, we certainly shouldn't just ignore test dependencies. 906 00:43:44,793 --> 00:43:45,933 That's not the way to do it. 907 00:43:46,263 --> 00:43:54,064 But to, to, to represent that data in a readable and a, a, form that elects 908 00:43:54,069 --> 00:43:55,494 people, make intelligent decisions. 909 00:43:56,489 --> 00:43:57,444 what packages to use. 910 00:43:57,714 --> 00:44:00,632 So that's something that, that think we're, we're looking to 911 00:44:00,632 --> 00:44:02,374 get back to in the next year. 912 00:44:02,507 --> 00:44:07,817 as you say, you, you know, there's a lot of these metrics that we are 913 00:44:07,817 --> 00:44:12,047 already pulling into the package page could be determined to give some 914 00:44:12,047 --> 00:44:19,060 kind quick glanceable rating of how well maintained or how, you know, 915 00:44:19,060 --> 00:44:20,830 what, what's the, you know, how. 916 00:44:22,585 --> 00:44:25,945 It's, it's, I don't really wanna say how good is this package, but because 917 00:44:25,945 --> 00:44:31,716 it's not about this, but, but certainly some kind of glanceable metadata that 918 00:44:31,716 --> 00:44:34,636 says, yeah, this is something that I wanna look a little deeper into. 919 00:44:34,705 --> 00:44:36,425 it, that can come from all sorts of stuff. 920 00:44:36,425 --> 00:44:37,985 Some of that will come from dependencies. 921 00:44:38,165 --> 00:44:39,275 Some of it will come from. 922 00:44:39,550 --> 00:44:43,936 The, the metadata we have about how well maintained packages in terms of our 923 00:44:43,966 --> 00:44:47,566 issues being closed, our pull requests being merged, that kind of thing. 924 00:44:47,571 --> 00:44:47,626 Yeah. 925 00:44:48,106 --> 00:44:49,186 Does it have a read me file? 926 00:44:49,186 --> 00:44:50,446 Does it have documentation? 927 00:44:50,446 --> 00:44:51,526 Does it have tests? 928 00:44:51,646 --> 00:44:55,576 There's a lot of things that we could expose in, first of all, on 929 00:44:55,576 --> 00:45:00,106 the package page, and then maybe infer from some kind of quality 930 00:45:00,106 --> 00:45:01,486 score or something like that from it. 931 00:45:01,636 --> 00:45:03,821 It was something that Cocoapods did. 932 00:45:03,821 --> 00:45:04,861 They don't do it anymore. 933 00:45:05,246 --> 00:45:07,806 But they Cocoapods had a quality index. 934 00:45:07,809 --> 00:45:11,520 And you, you could go to a, a little webpage for every mm-hmm. 935 00:45:12,300 --> 00:45:16,110 that had like five or six different metrics of like, this is 936 00:45:16,110 --> 00:45:17,700 something that it is doing right. 937 00:45:17,730 --> 00:45:20,585 This is something that's that, that it maybe could improve And it was 938 00:45:20,610 --> 00:45:23,730 things like how complex is the readme? 939 00:45:23,730 --> 00:45:27,282 There was a package that, there was tool they used Try and get a handle 940 00:45:27,282 --> 00:45:32,317 on how good a readme There's lots of possibilities for that kind of 941 00:45:32,740 --> 00:45:34,666 be To be used by the package index. 942 00:45:34,666 --> 00:45:35,968 So some something I'm interested 943 00:45:35,968 --> 00:45:36,388 Leo Dion (host): in working on. 944 00:45:36,448 --> 00:45:39,748 Yeah, I mean, one thing I always look at, and I've done this actually 945 00:45:39,748 --> 00:45:43,908 more with npm, is just like, has this package actually been maintained 946 00:45:43,913 --> 00:45:45,778 in the last, like two years? 947 00:45:45,778 --> 00:45:48,988 Cuz that's usually a decent indication that it's either a 948 00:45:48,988 --> 00:45:51,658 dead product or, or still active. 949 00:45:51,658 --> 00:45:54,238 But it sounds like, yeah, you want to add some of those 950 00:45:54,238 --> 00:45:55,858 metrics, which, which is awesome. 951 00:45:55,858 --> 00:45:56,668 I'm looking forward to that. 952 00:45:58,483 --> 00:46:01,544 . Dave Verwer (guest): And the other thing that we won't be able to is a lot of 953 00:46:01,544 --> 00:46:08,531 these package NPM and and others because they are both the registry and the index 954 00:46:08,536 --> 00:46:14,068 in most cases, like mpm for example, is, is, is vans, the, the, the package 955 00:46:14,068 --> 00:46:20,419 data or the, the dependency data and it is the search engine, so it can use how 956 00:46:20,424 --> 00:46:22,069 many people are downloading or using. 957 00:46:22,269 --> 00:46:22,789 Right? 958 00:46:22,789 --> 00:46:22,909 Right. 959 00:46:23,404 --> 00:46:25,714 Dependency as some kind of indicator. 960 00:46:25,834 --> 00:46:29,854 Now we absolutely don't have that because we have no, we have no way 961 00:46:29,854 --> 00:46:32,083 to to who's using each package. 962 00:46:32,113 --> 00:46:37,194 We don't even know really, you know, all we can see is, is on how many 963 00:46:37,284 --> 00:46:38,994 visits each package page has, basically. 964 00:46:39,054 --> 00:46:39,414 Right, right. 965 00:46:39,564 --> 00:46:41,784 So we have none of that information. 966 00:46:43,044 --> 00:46:45,834 Maybe that's something that registry eventually, I don't think it 967 00:46:45,834 --> 00:46:49,104 supports it in its current form, but maybe it could potentially 968 00:46:49,434 --> 00:46:50,844 start gathering some of that data. 969 00:46:50,849 --> 00:46:53,094 But again, there's good arguments for it, not I agree. 970 00:46:53,099 --> 00:46:53,454 Yeah. 971 00:46:53,454 --> 00:46:57,089 Leo Dion (host): I'm not sure that that is useful necessarily but it 972 00:46:57,089 --> 00:47:00,629 sounds like you have already a lot going on with Swift Package Index. 973 00:47:00,629 --> 00:47:03,451 It sounds like you have a lot coming this Yeah. 974 00:47:04,771 --> 00:47:04,991 people. 975 00:47:05,011 --> 00:47:08,401 Have I been to Swift Package Index and you have a sponsorship as well? 976 00:47:08,731 --> 00:47:13,954 Definitely take some time and some support financially and maybe put in a pull 977 00:47:13,954 --> 00:47:15,694 request if there's something you can fix. 978 00:47:17,119 --> 00:47:18,709 . Dave Verwer (guest): Well, there are many ways to support it. 979 00:47:18,714 --> 00:47:18,889 Yeah. 980 00:47:18,889 --> 00:47:22,183 And, and, and before I go into this, I think like to say, or we 981 00:47:22,183 --> 00:47:25,710 would like to say thank you so much for the little advertisement 982 00:47:25,715 --> 00:47:27,350 you've been, been running for us. 983 00:47:27,375 --> 00:47:28,984 That's, that's very much appreciated. 984 00:47:28,984 --> 00:47:30,957 And we, yes, we do have a GitHub. 985 00:47:31,542 --> 00:47:34,852 Sponsors account, which you can find on any of the GitHub repositories. 986 00:47:34,882 --> 00:47:38,858 Or on the package index page itself, there's a little, a little pink heart 987 00:47:38,863 --> 00:47:42,162 in the top menu bar that you can click to go to our GitHub sponsors. 988 00:47:42,327 --> 00:47:43,547 also there's many ways to help. 989 00:47:43,552 --> 00:47:47,285 You could also like many people have done this here as you could 990 00:47:47,384 --> 00:47:52,391 involved in the development, we have a discord server where we meet 991 00:47:52,391 --> 00:47:54,681 with all of the contributors of. 992 00:47:55,265 --> 00:47:58,175 so far and other people who are just generally interested in what 993 00:47:58,175 --> 00:47:59,825 we're doing on the package index. 994 00:47:59,825 --> 00:48:02,585 So the link to that discord is on our. 995 00:48:02,654 --> 00:48:03,934 Main repositories. 996 00:48:03,954 --> 00:48:04,254 We, and 997 00:48:04,564 --> 00:48:05,814 Leo Dion (host): we'll put that as well in the show notes. 998 00:48:05,814 --> 00:48:06,774 Of course notes. 999 00:48:06,804 --> 00:48:07,824 Thank you so much Dave. 1000 00:48:07,824 --> 00:48:08,934 It's fun for coming on the show. 1001 00:48:08,934 --> 00:48:10,054 I really appreciate it. 1002 00:48:10,054 --> 00:48:11,584 It's glad to have you both on. 1003 00:48:11,584 --> 00:48:14,039 Thank you so much for your work on Swift package decks. 1004 00:48:14,057 --> 00:48:17,093 dunno what else I have to say, but yeah, it's been wonderful 1005 00:48:17,098 --> 00:48:17,483 Dave Verwer (guest): chatting. 1006 00:48:17,513 --> 00:48:18,503 Thanks so much for having us. 1007 00:48:18,508 --> 00:48:19,943 I'm, yeah, thanks having us on show again. 1008 00:48:20,103 --> 00:48:20,363 Yeah. 1009 00:48:20,529 --> 00:48:23,444 Leo Dion (host): As a double actor, where could people find both of you online? 1010 00:48:23,945 --> 00:48:26,165 Dave Verwer (guest): Best place to find me is daveverwer.com. 1011 00:48:26,165 --> 00:48:27,205 ev Links to everything from there 1012 00:48:27,445 --> 00:48:29,635 Sven A. Schmidt (guest): I am on Mastodon these days. 1013 00:48:29,785 --> 00:48:32,436 finestructure@mastodon, oh God. 1014 00:48:32,436 --> 00:48:33,456 Master on social. 1015 00:48:33,456 --> 00:48:33,756 Yes. 1016 00:48:34,836 --> 00:48:35,876 . . Don't even know the domain. 1017 00:48:36,416 --> 00:48:39,566 It's the, the main side, but fine structure is, is the username 1018 00:48:39,566 --> 00:48:44,156 fine as in, you know, fine and structure if I any structure. 1019 00:48:44,336 --> 00:48:45,476 Leo Dion (host): Well, thank you so much. 1020 00:48:45,481 --> 00:48:47,846 People can find me on Twitter at Leo g Dion. 1021 00:48:48,166 --> 00:48:53,369 Maam, I'm Leo g Dion, c dot i m if you are listening to this 1022 00:48:53,369 --> 00:48:55,069 podcast, please take some time. 1023 00:48:55,549 --> 00:49:01,189 To post a review and also subscribe to the Swift Package Index Podcast as well. 1024 00:49:01,719 --> 00:49:05,197 And if you're watching this on YouTube, subscribe and like, thank 1025 00:49:05,197 --> 00:49:08,047 you so much for joining me and I look forward to talking to you again. 1026 00:49:08,137 --> 00:49:08,587 Bye everyone.