1
00:00:00,000 --> 00:00:06,560
Remember last week we talked about dependencies and in the course of the conversation I sort of

2
00:00:06,560 --> 00:00:14,400
apologetically, is that a word? I sort of feel, I felt embarrassed when I mentioned that

3
00:00:14,400 --> 00:00:22,800
SPI server, so the package that drives the Swift package index webpage is the one with the most

4
00:00:22,800 --> 00:00:28,320
dependencies in the index at 56. And when I was listening back to the episode, I thought,

5
00:00:28,880 --> 00:00:34,240
I've been approaching this all wrong. This is the Swift package index server package. The server,

6
00:00:34,240 --> 00:00:38,960
the package that's hosting the package index, it should be using as many packages as possible.

7
00:00:38,960 --> 00:00:46,640
We need to embrace the index, right? Embrace the index. That's probably a tagline we should have

8
00:00:46,640 --> 00:00:52,080
on the site. So if anything, that number is too low. We should be aiming to have at least 1% of

9
00:00:52,080 --> 00:00:58,720
our packages that we use. I have a mission. Yeah, I have a mission. I'm going to get all the

10
00:00:58,720 --> 00:01:02,400
dependencies. Maybe we should just include every dependency just in case we need it.

11
00:01:02,400 --> 00:01:06,960
Well, at least a few more we could do, right? Maybe we should remember when Steve Jobs announced the

12
00:01:06,960 --> 00:01:13,120
iPhone and said, you know, once to have 1% market share, we should maybe have 1% package share in a

13
00:01:13,120 --> 00:01:18,960
year. Yeah. And maybe then in the future, we could aim for two or 3% long-term, but you know, 1%,

14
00:01:18,960 --> 00:01:26,880
we're close. We're at 56, 63, 10% is 1%. So we're right there. I mean, it doesn't take much.

15
00:01:26,880 --> 00:01:31,280
who else is going to test whether all these packages work together? I think we are the only

16
00:01:31,280 --> 00:01:37,120
answer to that question. I mean, I'm sure there's a couple of easy ones we can pull in

17
00:01:37,120 --> 00:01:42,320
without bending over backwards too much. I'm sure something can be done.

18
00:01:42,320 --> 00:01:49,360
Anyway, so that was that. And then the other interesting bit of feedback we got was from

19
00:01:50,240 --> 00:01:58,160
Joe Heck, so he sent us a follow-up email. We've talked about JavaScript dependency trees,

20
00:01:58,160 --> 00:02:05,760
how they tend to be big and self-referencing in ways we found puzzling. And he suspects

21
00:02:05,760 --> 00:02:15,760
the reason is that the dependency trees in JavaScript are independent. So, and my understanding

22
00:02:15,760 --> 00:02:23,680
was if this is as if Swift package manager, when you do package resolution, it looks at the whole

23
00:02:23,680 --> 00:02:33,280
thing and resolves one version and one version only per package that is used for your artifact.

24
00:02:33,280 --> 00:02:38,800
And sometimes that doesn't work, right? There is no package resolution because one package has a

25
00:02:38,800 --> 00:02:44,640
certain range for a dependency and another package has another incompatible range and then package

26
00:02:44,640 --> 00:02:49,600
resolution fails entirely. My understanding is in JavaScript, that would still work because

27
00:02:49,600 --> 00:02:56,160
you have two independent subtrees that both use that dependency, just at different versions.

28
00:02:56,160 --> 00:03:06,320
And I think the analogy in Swift is as if every dependency was built like a binary artifact,

29
00:03:06,320 --> 00:03:10,640
and then you pull those binary artifacts in and link them into your binary at the end,

30
00:03:11,200 --> 00:03:16,400
such that they're sort of opaque. Yeah. Yeah, pretty much, but it's not binary, of course,

31
00:03:16,400 --> 00:03:21,600
it's just source code. So the slightly annoying thing is, I actually knew this already and I just

32
00:03:21,600 --> 00:03:28,480
completely slipped my mind completely when we were talking about it last week. And it is an

33
00:03:28,480 --> 00:03:35,680
interesting approach, but it brings with it as many problems as it solves. Yeah, it's interesting

34
00:03:35,680 --> 00:03:40,640
how these different approaches potentially lead to different outcomes. I mean, we don't have the

35
00:03:40,640 --> 00:03:48,000
numbers. There were some similarities between JavaScript's ecosystem and Rust. And Rust,

36
00:03:48,000 --> 00:03:55,200
I believe, doesn't have that same approach. So the fact that they also have circular

37
00:03:55,200 --> 00:04:03,600
references might indicate that that would happen in Swift as well. Again, we'll do this at some

38
00:04:03,600 --> 00:04:10,060
point and then we'll find out. I still can't explain why some packages reference

39
00:04:10,060 --> 00:04:14,280
themselves. Wasn't that a thing? Yeah not only that, I think even directly,

40
00:04:14,280 --> 00:04:20,180
which I found super baffling. Yeah so the two dependency

41
00:04:20,180 --> 00:04:25,800
cycle is now explained more readily, but the one package dependency cycle is

42
00:04:25,800 --> 00:04:30,380
still a mystery to me. Yeah that pretty much is a mystery. I wonder if

43
00:04:30,380 --> 00:04:34,860
something that was wrong with him. But you know his analysis looked very

44
00:04:34,860 --> 00:04:42,220
thorough and considered so it doesn't look like this was a data mess-up

45
00:04:42,220 --> 00:04:46,820
or anything like it. We'll see. And if you're wondering what we're talking

46
00:04:46,820 --> 00:04:50,820
about, you should go back and listen to the previous episode where we

47
00:04:50,820 --> 00:04:56,420
talk about this blog post about JavaScript dependencies and

48
00:04:56,420 --> 00:04:59,780
you'll hear all the background to what we're following up here.

49
00:04:59,780 --> 00:05:05,880
here. Yeah, exactly. Yeah, right. That was the follow-up that I have in my

50
00:05:05,880 --> 00:05:12,100
notes. One thing we can talk about this week is we had a pull request merged as

51
00:05:12,100 --> 00:05:17,020
a result of the SWIFT mentorship program. So we've been participating in the

52
00:05:17,020 --> 00:05:22,340
mentorship program for three years now. This is our third year of participation

53
00:05:22,340 --> 00:05:30,440
and I've been working with Cindy Chin to work on some of our package scoring

54
00:05:30,440 --> 00:05:36,420
code. And so there's actually been a couple of pull requests merged by Cindy

55
00:05:36,420 --> 00:05:42,380
already. The project that we're working on is all around package score and how

56
00:05:42,380 --> 00:05:46,320
we determine it and how we surface what the package score is and so package

57
00:05:46,320 --> 00:05:51,400
authors can see their package score and things like that. And we got started with

58
00:05:51,400 --> 00:05:55,900
with one pull request almost at the beginning of the program and then this

59
00:05:55,900 --> 00:06:04,080
week we merged another pull request which is part of the scoring mechanism.

60
00:06:04,080 --> 00:06:10,620
So we're adding an extra dimension to scoring. So we have this internal package

61
00:06:10,620 --> 00:06:15,000
score which is what we use. It's not entirely the sort order for search

62
00:06:15,000 --> 00:06:21,380
results but it contributes to the sort order for search results and we want to

63
00:06:21,380 --> 00:06:27,040
make that package score represent or should we say we want to make that

64
00:06:27,040 --> 00:06:34,700
package score increase when good quality packages should naturally increase that

65
00:06:34,700 --> 00:06:42,820
package score. So for example, if a package has been maintained recently, it

66
00:06:42,820 --> 00:06:46,460
had an issue closed or a pull request closed or a commit or something like

67
00:06:46,460 --> 00:06:51,860
that, then we count that as a recently maintained package and that

68
00:06:51,860 --> 00:06:58,500
adds to the score. If the package repository is archived, we don't give any

69
00:06:58,500 --> 00:07:01,860
points for that, but if it's not archived, we get some points for that. And there's

70
00:07:01,860 --> 00:07:05,120
several. You can have a look at the source. In fact, we'll give a link to the

71
00:07:05,120 --> 00:07:12,920
source code in the show notes because the algorithm is transparent and open.

72
00:07:12,920 --> 00:07:20,640
and we've added to it or Cindy has added to it this week by adding a

73
00:07:20,640 --> 00:07:28,940
score increase if your package has a test target. Now there's pros and cons to

74
00:07:28,940 --> 00:07:34,580
this score increase for test targets. It is just about the simplest

75
00:07:34,580 --> 00:07:40,040
implementation of are there tests in this package and what it does is it looks

76
00:07:40,040 --> 00:07:45,900
through the targets in the package manifest and if you have a test target

77
00:07:45,900 --> 00:07:50,440
then it says then you probably have some tests. Now depending on how you made your

78
00:07:50,440 --> 00:07:54,480
package you might have got a test target for free and might have never added any

79
00:07:54,480 --> 00:08:00,080
actual test to it. So there's an element of this which we would like to improve

80
00:08:00,080 --> 00:08:05,440
again in the future but this progress towards a better system right? This is

81
00:08:05,440 --> 00:08:09,440
that how software development works, we step one foot in front of another.

82
00:08:09,440 --> 00:08:17,920
Yeah, I think it would be good as a second step to try and at least reject the common case where

83
00:08:17,920 --> 00:08:26,080
someone has just created a template package and sort of got the points for free and someone who

84
00:08:26,080 --> 00:08:30,640
actually cleaned up the template and removed stuff they weren't using would actually be sort of

85
00:08:31,200 --> 00:08:40,160
punished for doing the tidying up, that's probably something we can do at some point. It doesn't

86
00:08:40,160 --> 00:08:45,120
sound like it's... I could imagine there are ways to do that that aren't overly complicated.

87
00:08:45,120 --> 00:08:51,920
Just briefly thinking about it, Devel might be in the details, but it's the sort of thing that is

88
00:08:51,920 --> 00:08:57,040
probably one metric that is going to be really interesting for someone looking for a package,

89
00:08:57,040 --> 00:09:02,640
test coverage one way or another, if it's by counting targets or number of tests,

90
00:09:02,640 --> 00:09:09,200
or ideally actual coverage is a really interesting metric, but obviously it's also hard to get,

91
00:09:09,200 --> 00:09:14,480
right? Test coverage is really hard to obtain unless you run the tests and running the tests

92
00:09:14,480 --> 00:09:20,800
isn't something we'll probably ever do or be able to do because ACI system isn't

93
00:09:20,800 --> 00:09:25,880
notoriously difficult to set up even if you own the project and probably

94
00:09:25,880 --> 00:09:32,980
impossible to do if you don't own it. So yeah CI is hard to set up if you're

95
00:09:32,980 --> 00:09:39,280
being paid to set it up. Let alone us setting up for every project that

96
00:09:39,280 --> 00:09:46,160
exists. I really like messing with tests and CI but the prospect of

97
00:09:46,160 --> 00:09:52,780
managing hundreds of CI systems of packages I don't own isn't one I cherish.

98
00:09:52,780 --> 00:09:58,280
Yeah, yeah it's interesting. It's the kind of thing that I also don't

99
00:09:58,280 --> 00:10:03,860
think we'll ever go to that level with the package index compatibility system.

100
00:10:03,860 --> 00:10:11,420
But we could certainly do more to start actually looking for

101
00:10:11,420 --> 00:10:17,020
number of tests. I probably wouldn't want to even report, even if we could, I mean

102
00:10:17,020 --> 00:10:20,260
obviously we'd need to run the tests, but even if we could find a way to do that, I

103
00:10:20,260 --> 00:10:25,900
wouldn't even particularly want to report code coverage. But I think a

104
00:10:25,900 --> 00:10:30,820
simple number of tests is a great metric that we'll potentially work

105
00:10:30,820 --> 00:10:36,760
towards going forward. Yeah, and I think that might be feasible with Swift

106
00:10:36,760 --> 00:10:40,620
syntax if you really want to look at the source code or maybe even some

107
00:10:40,620 --> 00:10:47,500
simple heuristics that might be wrong, but you know in some edge cases, but generally have

108
00:10:47,500 --> 00:10:52,300
a good result that might work too. I think there are ways to arrive there that aren't overly

109
00:10:52,300 --> 00:11:02,700
complicated. And then the next stage of Cindy's work on the mentorship program is to explain that

110
00:11:02,700 --> 00:11:09,420
score. So I said a few minutes ago, I said we put a link to the source code in. Linking to the source

111
00:11:09,420 --> 00:11:15,420
code is one way to tell people how their package is scored, but it's not a great

112
00:11:15,420 --> 00:11:20,640
way. It is, however, the way that we've been relying on so far. But the

113
00:11:20,640 --> 00:11:23,580
next piece of work that Cindy is currently working on - in fact I had a

114
00:11:23,580 --> 00:11:28,460
meeting with her about an hour ago where we looked at a prototype of this

115
00:11:28,460 --> 00:11:35,860
working on her branch - is to - so we have a page for package maintainers

116
00:11:35,860 --> 00:11:42,240
where we give people the markdown for the compatibility badges that they can

117
00:11:42,240 --> 00:11:46,180
put in their readme and links to how to configure the documentation and things

118
00:11:46,180 --> 00:11:51,100
like that. And at the bottom of that page we're going to have a section where it

119
00:11:51,100 --> 00:11:56,480
tells people what the package score is and then has a table underneath that

120
00:11:56,480 --> 00:12:01,820
score to also explain how the points were tallied and why the points were

121
00:12:01,820 --> 00:12:05,820
tallied so that you can take a look at your package if you have a package in

122
00:12:05,820 --> 00:12:09,980
the index and see okay well this is why I got this score and if I would like to

123
00:12:09,980 --> 00:12:16,260
improve my score this is what I need to do and if if all of this works then

124
00:12:16,260 --> 00:12:19,700
those things that you do to improve your score will also make your package better

125
00:12:19,700 --> 00:12:22,880
so hopefully there'll be no gaming of the system. I was just gonna say we're

126
00:12:22,880 --> 00:12:30,980
going to publish the recipe to game the system. Well I think there's obviously

127
00:12:30,980 --> 00:12:35,100
gonna be a little bit of that and we can't we can't stop that nor would I

128
00:12:35,100 --> 00:12:42,340
particularly be interested in stopping it. But I think as long as we are, I think

129
00:12:42,340 --> 00:12:46,220
we should be transparent with what the score is. I mean we are being

130
00:12:46,220 --> 00:12:50,460
transparent by definition because it's an open source project so we can't, we

131
00:12:50,460 --> 00:12:53,780
could hide it, we could put it in a private package but I definitely don't

132
00:12:53,780 --> 00:13:01,180
want to do that. So it is already open. This is just explaining it

133
00:13:01,180 --> 00:13:05,260
- Yeah, and you know, if we get people to add documentation

134
00:13:05,260 --> 00:13:07,060
to their package, even if it's bare bones,

135
00:13:07,060 --> 00:13:07,900
that's still a win.

136
00:13:07,900 --> 00:13:12,580
If that's the level of gaming we arrive at, that's fine.

137
00:13:12,580 --> 00:13:15,380
That's good, because then it's easier next time around

138
00:13:15,380 --> 00:13:17,380
to just do a little more,

139
00:13:17,380 --> 00:13:19,300
that other little bit of documentation,

140
00:13:19,300 --> 00:13:21,540
because you've already set it up, why not use it?

141
00:13:21,540 --> 00:13:24,060
- It's like a broccoli eating competition.

142
00:13:24,060 --> 00:13:26,560
You know, you can cheat and eat a load of broccoli,

143
00:13:26,560 --> 00:13:28,380
and at the end of it, you're just more healthy.

144
00:13:28,380 --> 00:13:30,640
(laughing)

145
00:13:30,640 --> 00:13:32,880
(laughing)

146
00:13:32,880 --> 00:13:35,600
That doesn't work at all.

147
00:13:35,600 --> 00:13:37,880
- It sounds like you don't like broccoli.

148
00:13:37,880 --> 00:13:38,920
I actually love broccoli.

149
00:13:38,920 --> 00:13:39,880
That didn't sound like--

150
00:13:39,880 --> 00:13:41,400
- I actually, I love broccoli.

151
00:13:41,400 --> 00:13:43,080
I think I would even go as far as to say

152
00:13:43,080 --> 00:13:44,920
broccoli is my favorite vegetable.

153
00:13:44,920 --> 00:13:49,600
Ah, that's funny.

154
00:13:49,600 --> 00:13:51,200
I don't know whether that'll make the edit.

155
00:13:51,200 --> 00:13:52,320
(laughing)

156
00:13:52,320 --> 00:13:53,160
- Leave it in.

157
00:13:53,160 --> 00:13:58,520
- The last thing to mention here is that Cindy was very keen

158
00:13:58,520 --> 00:14:03,520
with her mentorship to do a feature end to end.

159
00:14:03,520 --> 00:14:06,480
And so we started off with some planning of it.

160
00:14:06,480 --> 00:14:07,760
We talked about possibilities.

161
00:14:07,760 --> 00:14:10,200
We talked about, should we even display the score?

162
00:14:10,200 --> 00:14:11,240
Where should we display it?

163
00:14:11,240 --> 00:14:12,840
We toyed with having it on the package page.

164
00:14:12,840 --> 00:14:16,380
So we did a little kind of feature design at the beginning.

165
00:14:16,380 --> 00:14:21,140
We also wanted at least one more kind of indicator

166
00:14:21,140 --> 00:14:23,720
into that score, which is this test target,

167
00:14:23,720 --> 00:14:25,420
pull request that got merged.

168
00:14:25,420 --> 00:14:28,240
But I think the other thing which is really nice to see

169
00:14:28,240 --> 00:14:31,180
is that she wanted to take this feature

170
00:14:31,180 --> 00:14:33,280
right through to launching it.

171
00:14:33,280 --> 00:14:38,080
And the last pull request on this project for her

172
00:14:38,080 --> 00:14:40,620
will hopefully be a blog post announcing the thing.

173
00:14:40,620 --> 00:14:44,240
So it's literally from what are we even going to do

174
00:14:44,240 --> 00:14:48,440
through to several pull requests to add some functionality

175
00:14:48,440 --> 00:14:51,040
through to launching it and publicizing it

176
00:14:51,040 --> 00:14:52,720
and getting the word out about what we're doing.

177
00:14:52,720 --> 00:14:53,540
- Very nice.

178
00:14:53,540 --> 00:14:55,560
- Which I think is just, it's such a great attitude.

179
00:14:55,560 --> 00:14:57,560
It's been, I mean, it's not over yet,

180
00:14:57,560 --> 00:15:00,160
but it's been a pleasure working with Cindy so far.

181
00:15:00,160 --> 00:15:01,280
- That sounds great.

182
00:15:01,280 --> 00:15:04,420
All right, in other news,

183
00:15:04,420 --> 00:15:07,480
we have upgraded our build system

184
00:15:07,480 --> 00:15:10,920
to the release version of Swift 5.9,

185
00:15:10,920 --> 00:15:15,060
which is probably not a big change for most packages.

186
00:15:15,060 --> 00:15:18,120
We were still running on a early version

187
00:15:18,120 --> 00:15:19,960
of the Swift 5.9 beta,

188
00:15:19,960 --> 00:15:22,800
but I don't think there were many packages

189
00:15:22,800 --> 00:15:25,480
that had any build differences between the two.

190
00:15:25,480 --> 00:15:31,440
The biggest change is probably that we're also now generating a documentation by default

191
00:15:31,440 --> 00:15:38,040
with 5.9, because the documentation generation always happens on the latest release version

192
00:15:38,040 --> 00:15:39,200
in our system.

193
00:15:39,200 --> 00:15:44,320
And as long as we're on a pre-release version, we don't switch documentation generation over

194
00:15:44,320 --> 00:15:46,040
yet.

195
00:15:46,040 --> 00:15:52,080
So if you haven't specified a Swift version for your doc generation from now on, your

196
00:15:52,080 --> 00:15:59,760
will be generated with 5.9. That's also probably not a big change between 5.8, 5.9. Do you actually

197
00:15:59,760 --> 00:16:04,880
know what the docc differences are between the two versions? I don't think there was any.

198
00:16:04,880 --> 00:16:08,080
The quick navigation was 5.8, right?

199
00:16:08,080 --> 00:16:15,120
Yeah, that was a very user-facing feature that came with 5.8, but 5.9, I don't think there's

200
00:16:15,120 --> 00:16:22,320
anything in the UI. I believe there was a default change when it comes to generating documentation

201
00:16:22,320 --> 00:16:28,880
for extensions but I'm always a bit hazy on what goes in when and what default is enabled when.

202
00:16:28,880 --> 00:16:35,920
But it might be a good idea if you have documentation and you release a new version

203
00:16:35,920 --> 00:16:42,960
or just the main branch, have a look at your docs for that version to make sure that everything

204
00:16:42,960 --> 00:16:50,560
looks as you expect it to. And if you see any issues, make sure you generate your documentation

205
00:16:50,560 --> 00:16:56,400
locally with Swift 5.9 to see if they get the same result. And if there's any discrepancy,

206
00:16:56,400 --> 00:17:00,160
let us know. If there are any errors, let us know and we'll take a closer look.

207
00:17:00,160 --> 00:17:05,200
Yeah, that's just the heads up around that change.

208
00:17:05,200 --> 00:17:05,760
Absolutely.

209
00:17:05,760 --> 00:17:08,000
Shall we do some packages?

210
00:17:08,800 --> 00:17:17,040
Yeah, let's do some packages. And I will start us off this week with a package by Miguel de Icaza

211
00:17:17,040 --> 00:17:25,760
called Swift Godot or Godot, which is something that I've been paying a little bit of attention

212
00:17:25,760 --> 00:17:29,440
to for a little while now. So I don't know whether you heard in the last couple of weeks,

213
00:17:30,640 --> 00:17:38,640
Unity put their foot squarely in their mouth with a change of business plan that really

214
00:17:38,640 --> 00:17:47,760
was not very well thought through and was to say the least badly received by the Unity community.

215
00:17:47,760 --> 00:17:50,480
One could say there was discord in the Unity community.

216
00:17:50,480 --> 00:17:55,520
One could if one wanted to, yes. But let's hope one doesn't want to.

217
00:17:59,920 --> 00:18:09,360
Yeah, it was a terrible PR disaster. And I'm not a Unity user. I've downloaded it and had a very,

218
00:18:09,360 --> 00:18:15,200
very cursory play with it, but I definitely wouldn't call myself a user of it. But one

219
00:18:15,200 --> 00:18:23,600
thing that I had been kind of keeping my eye on is this open source game framework called Guddo,

220
00:18:23,600 --> 00:18:30,320
or "G'not" I'm not quite sure what the pronunciation is. And I think they had a

221
00:18:30,320 --> 00:18:36,800
huge boost in publicity when this unity announcement went bad because everyone

222
00:18:36,800 --> 00:18:43,040
suddenly starts looking for well maybe what else is available. Yeah. And yeah and

223
00:18:43,040 --> 00:18:52,440
Miguel has put together some bindings for the framework using Swift. So there

224
00:18:52,440 --> 00:18:58,720
is apparently a new extension system in the framework that you can hook into

225
00:18:58,720 --> 00:19:06,800
and then interact with the game object. So the default language for this

226
00:19:06,800 --> 00:19:12,400
framework is actually a language called GDScript, which it's a little like Python

227
00:19:12,400 --> 00:19:17,800
in that it uses indentation for structure, but also it's a little...

228
00:19:17,800 --> 00:19:22,320
there's certainly a couple of shades of Swift in there with, you know, VAR

229
00:19:22,320 --> 00:19:27,400
statements and funk statements and things like that. So it's GDScript

230
00:19:27,400 --> 00:19:33,080
itself is one option for interacting with this framework, but now you can

231
00:19:33,080 --> 00:19:40,360
actually also use Swift. And I just want to call out what a fantastic job - I don't

232
00:19:40,360 --> 00:19:44,160
know how I haven't used this package - but what a fantastic job Miguel has

233
00:19:44,160 --> 00:19:50,560
done with documenting this package, even down to hosting a tutorial, a 50 minute

234
00:19:50,560 --> 00:19:57,960
long tutorial using the Doxy tutorial framework to get you started with

235
00:19:57,960 --> 00:20:01,560
building a game with Swift using this framework.

236
00:20:01,560 --> 00:20:07,960
Nice. Yeah, this was actually also on my list, actually the first one.

237
00:20:07,960 --> 00:20:09,960
Oh, I sniped you!

238
00:20:09,960 --> 00:20:15,400
sniped, got in first, yeah, and I picked it for the same reason, with the Unity stuff going on.

239
00:20:15,400 --> 00:20:20,840
It's really interesting, yeah, I saw, I didn't actually see that there was this

240
00:20:20,840 --> 00:20:27,320
long tutorial in it, and I think tutorials can be quite fiddly to generate, so creating a tutorial

241
00:20:27,320 --> 00:20:34,520
that long is quite the task. That's amazing. So from the readme file, if you click through to the

242
00:20:34,520 --> 00:20:40,400
API documentation you'll end up on a Doxy generated documentation set which is

243
00:20:40,400 --> 00:20:44,740
unfortunately not hosted with package index but we'll forgive Miguel that just

244
00:20:44,740 --> 00:20:51,440
this one time. And the very first link on that on that documentation is to the

245
00:20:51,440 --> 00:20:57,480
tutorial it's called meet Swift Godot and it is estimated at 50 minutes of

246
00:20:57,480 --> 00:21:03,880
development. Nice. The other thing perhaps worth mentioning is there is a binary

247
00:21:03,880 --> 00:21:10,680
package that also comes with Swift Go, or is associated with Swift Go though, and the advantage

248
00:21:10,680 --> 00:21:16,360
here is that he has packaged the underlying library up in a binary artifact, so you don't need

249
00:21:16,360 --> 00:21:22,680
to actually build the whole framework to use it, and that should probably help with your just user

250
00:21:22,680 --> 00:21:27,800
experience using that package. I haven't tried this, I don't know how this worked. I did have

251
00:21:27,800 --> 00:21:33,240
have a quick look into how to set this up, but I quickly gave up when I saw what

252
00:21:33,240 --> 00:21:38,640
all is needed to do this, and game dev is a bit like cooking for me. I've

253
00:21:38,640 --> 00:21:43,640
sort of chosen to specialize in eating, so I'm much better at playing games than

254
00:21:43,640 --> 00:21:49,080
doing anything around creating them, so I pretty much waved the flag

255
00:21:49,080 --> 00:21:55,840
immediately. I have had a play with the framework itself way before the Unity

256
00:21:55,840 --> 00:22:01,360
stuff. I investigated it maybe six months ago, but I didn't do anything apart from

257
00:22:01,360 --> 00:22:06,680
write a little GD script, which is just the default. So that's, yeah, that's

258
00:22:06,680 --> 00:22:09,760
my first package recommendation. I think we are going with Godot, right?

259
00:22:09,760 --> 00:22:17,160
I think so. That's how I had it in my head. Probably needs some sort of

260
00:22:17,160 --> 00:22:23,440
phonetic spelling out as a metadata field on all these packages.

261
00:22:23,440 --> 00:22:31,000
So that's SwiftGido by Miguel de Icaza. Right, my first pick is called Swift SDK

262
00:22:31,000 --> 00:22:37,760
Generator by that little company called Apple and this is of particular

263
00:22:37,760 --> 00:22:43,340
interest to me. It's a package about or for cross compilation. It's a cross

264
00:22:43,340 --> 00:22:50,000
compilation toolkit and was I think released just last week or the week

265
00:22:50,000 --> 00:22:54,680
before. So there have been some Swift proposals around this Swift proposals

266
00:22:54,680 --> 00:23:00,880
that went through a while back, but this is the first part of the whole cross

267
00:23:00,880 --> 00:23:07,440
compilation story that is actually usable and does work but in limited

268
00:23:07,440 --> 00:23:12,640
ways. So currently what it supports is cross compilation from Mac OS to Linux

269
00:23:12,640 --> 00:23:23,480
And the way this works is use this SDK generator to create a Swift SDK toolkit.

270
00:23:23,480 --> 00:23:25,420
So it's sort of a bundle.

271
00:23:25,420 --> 00:23:31,300
You can bundle up, it's 2.5 gigabytes of stuff, essentially Linux stuff that you bundle together

272
00:23:31,300 --> 00:23:33,200
and it's by Linux version.

273
00:23:33,200 --> 00:23:37,800
So there are slight differences between different Linux distributions.

274
00:23:37,800 --> 00:23:41,640
So you need to do this typically per Linux distribution.

275
00:23:41,640 --> 00:23:45,500
I've tried this for Ubuntu Jammy, for instance, and obviously also by platform.

276
00:23:45,500 --> 00:23:52,020
And then you, you package this together and then you can import this into the, into

277
00:23:52,020 --> 00:23:54,060
your Swift compiler tool chain effectively.

278
00:23:54,060 --> 00:23:59,060
And after you've done that, you can run Swift build and it's currently an

279
00:23:59,060 --> 00:24:04,120
experimental flag, so you do it Swift build dash dash experimental dash Swift

280
00:24:04,120 --> 00:24:09,080
dash SDK, and then you reference the SDK you've just created and effectively give

281
00:24:09,080 --> 00:24:16,300
it a Swift version number, a platform version label and architecture.

282
00:24:16,300 --> 00:24:22,860
So like 5.9 release, Ubuntu, Jammy, AR64 for the ARM version of it.

283
00:24:22,860 --> 00:24:28,000
You specify that as the identifier for that SDK, and then you can cross compile

284
00:24:28,000 --> 00:24:36,200
on Mac as a Linux binary, and you can copy that over to Linux Docker image, for

285
00:24:36,200 --> 00:24:38,240
instance, a Docker container and then run it.

286
00:24:38,240 --> 00:24:39,960
And after that, it works just fine.

287
00:24:39,960 --> 00:24:41,420
Really nice.

288
00:24:41,420 --> 00:24:48,160
And, um, I mean, obviously this is probably not the most interesting path yet, right?

289
00:24:48,160 --> 00:24:53,760
Compiling from macOS to Linux, because if you are looking to perhaps save some money

290
00:24:53,760 --> 00:25:01,040
on your CI, the macOS as the platform to run stuff on is probably not the cheapest option you have.

291
00:25:01,040 --> 00:25:06,160
I don't know what the plans are, if it's ever going to be possible to do it the other way around.

292
00:25:06,160 --> 00:25:10,300
like on Linux to cross compile to macOS.

293
00:25:10,300 --> 00:25:13,140
I'm not sure how that would work with licensing and all that.

294
00:25:13,140 --> 00:25:17,320
But that would be for us, for instance, that would be really interesting.

295
00:25:17,320 --> 00:25:22,600
Because currently Linux is a very easy platform for us to manage and, and, and

296
00:25:22,600 --> 00:25:24,760
maintain with respect to Swift versions.

297
00:25:24,760 --> 00:25:28,880
Whereas macOS interestingly is, is the most complicated one.

298
00:25:28,880 --> 00:25:34,580
We might have a little story to tell in the future, how that might be possible

299
00:25:34,580 --> 00:25:41,300
to make it a bit easier, but currently it's a bit of a fiddly system with respect to macOS

300
00:25:41,300 --> 00:25:49,220
versions and Xcode versions to manage. I really hope that at some point these SDK setups become

301
00:25:49,220 --> 00:25:54,740
really universal and that they support lots of different combinations. I mean, ideally all of

302
00:25:54,740 --> 00:26:01,380
them, but that might never be possible. But the more combinations are covered by this, the better,

303
00:26:01,380 --> 00:26:01,780
really.

304
00:26:01,780 --> 00:26:08,900
- And I think that's the key thing here is that this may be a package which will become more useful

305
00:26:08,900 --> 00:26:14,740
and or more used in the future, but it's good to see that there's thought and planning going into

306
00:26:14,740 --> 00:26:19,940
this now. - Yeah, I mean, just the effort that this exists and works is amazing. I think this

307
00:26:19,940 --> 00:26:26,100
is a really great and strong indicator of where we're heading here because I mean, none of the

308
00:26:26,100 --> 00:26:33,700
the Apple packages strike you as efforts that happen now and then don't go anywhere. I think

309
00:26:33,700 --> 00:26:44,180
these are all long-term strategic things that are just being started now and are intended to be used

310
00:26:44,180 --> 00:26:52,700
and to grow. So this is really exciting and the fact that this already works and is usable is

311
00:26:52,700 --> 00:26:59,500
compelling. I'm not sure it's something that would help us immediately. I mean, I could see how it

312
00:26:59,500 --> 00:27:06,780
could make some of our build system easy. So if we were to use this, it would make actually parts

313
00:27:06,780 --> 00:27:13,980
of our setup easier. It would make other parts of our setup harder. So it currently would be a

314
00:27:13,980 --> 00:27:20,220
trade-off, but just the fact that this exists would give us an option in dealing with certain

315
00:27:20,220 --> 00:27:25,900
complexities in our system. And I can, you know, envision that in the future this might make lots

316
00:27:25,900 --> 00:27:31,340
of things just easier in general, where right now we have to do a lot of special casing. So I'm

317
00:27:31,340 --> 00:27:37,020
really looking forward to how this package develops in the future. Yeah, that's great. It's great to

318
00:27:37,020 --> 00:27:47,740
see. My next package is Zip Pinch by Alexey Bukhtin. And this package kind of blew my mind

319
00:27:48,700 --> 00:27:54,060
when I found it. It's actually not a new package at all. It's been in development

320
00:27:54,060 --> 00:27:57,660
for eight years so this is a very well established

321
00:27:57,660 --> 00:28:03,260
open source package. It's not a, I don't think it's a

322
00:28:03,260 --> 00:28:07,180
particularly terribly complicated package because

323
00:28:07,180 --> 00:28:09,820
in those eight years it's only had 48 commits but

324
00:28:09,820 --> 00:28:13,980
that's not to put it down at all. It's just

325
00:28:13,980 --> 00:28:18,540
you know some jobs are big, some jobs are small. But what blew my mind

326
00:28:18,540 --> 00:28:25,820
what it does and what it does is it's an extension for URL session to work with

327
00:28:25,820 --> 00:28:34,300
zip files remotely so you can open peek inside read and write to a zip file

328
00:28:34,300 --> 00:28:40,580
without downloading the file locally which absolutely blew my mind now it's

329
00:28:40,580 --> 00:28:47,140
been a very long time since I looked at the details of a PK zip file but I do

330
00:28:47,140 --> 00:28:52,660
do remember from when I did briefly look at it when I was a kid,

331
00:28:52,660 --> 00:28:59,420
basically, that it does have this kind of table of contents at the beginning,

332
00:28:59,420 --> 00:29:04,080
and you can reference into the file and you can get just the bits you need and

333
00:29:04,080 --> 00:29:09,260
all the rest of it. But to do that remotely over a UL session kind of blew

334
00:29:09,260 --> 00:29:17,060
my mind a little bit. Now you might ask, well, how useful is that? And it became

335
00:29:17,060 --> 00:29:21,340
more useful in my mind when I read that it was also compatible with watchOS.

336
00:29:21,340 --> 00:29:27,460
So I can absolutely see a situation where on the watch you're trying not to

337
00:29:27,460 --> 00:29:31,640
download an entire zip file, unzip it, try and poke through what the

338
00:29:31,640 --> 00:29:38,720
files are inside there, but to be able to access a remote zip file and access

339
00:29:38,720 --> 00:29:42,880
files within that, I can see this being useful.

340
00:29:42,880 --> 00:29:50,480
So is this PKZIP or ZIP or are they the same? I don't know. I thought PKZIP was different.

341
00:29:50,480 --> 00:29:58,400
PKZIP was the original file format. I mean I know that file format has been incredibly robust.

342
00:29:58,400 --> 00:30:02,800
I can't say there have been no changes to the zip file format since then, but I don't think there

343
00:30:02,800 --> 00:30:08,880
have been many changes to it. Right, so this is just a general zip file that you could like if

344
00:30:08,880 --> 00:30:13,320
you right-click and click compress, that's the same format. It's a zip file,

345
00:30:13,320 --> 00:30:19,080
yeah, absolutely. So how does that work? Does it just use HTTP offset like

346
00:30:19,080 --> 00:30:23,760
head requests and stuff like that? I haven't been digging through the source

347
00:30:23,760 --> 00:30:28,880
code, but that's the only way that I can think that it can work. So it must do a

348
00:30:28,880 --> 00:30:33,680
request to get the beginning of the file, read a little bit, read the table of

349
00:30:33,680 --> 00:30:40,280
contents and then do a separate request at an offset to read the file and then

350
00:30:40,280 --> 00:30:49,520
unzip the content locally. So that's Zip Pinch by Alexey Bukhtin. Very nice.

351
00:30:49,520 --> 00:30:57,800
Right, my second pick is another package by Apple and it's called Swift Testing.

352
00:30:57,800 --> 00:31:03,040
People have probably heard about this because I believe you also referenced or

353
00:31:03,040 --> 00:31:07,960
mentioned this in Friday's newsletter, didn't you? Yes, in fact I wrote my

354
00:31:07,960 --> 00:31:12,040
opening comment on it. Ah right, yes, yes. You actually had a link to the

355
00:31:12,040 --> 00:31:19,040
Vision document about the package in your opening and it's actually, that

356
00:31:19,040 --> 00:31:23,260
document is hard to find. I wanted to check it out again and the best way to

357
00:31:23,260 --> 00:31:27,600
find it was to go back and find that issue because it's not actually linked

358
00:31:27,600 --> 00:31:30,920
from... Well the best way to find anything is to go to iOS.com. Here we go.

359
00:31:30,920 --> 00:31:40,760
our sponsors this week. I really love this package. When I saw this announced on the

360
00:31:40,760 --> 00:31:48,840
Swift forums, I was so excited because I've long felt that that XC test assert and the whole XC test

361
00:31:48,840 --> 00:31:58,840
framework is great. I mean, I've used this for literally decades now. I mean, this is ancient,

362
00:31:58,840 --> 00:32:05,320
right? And it hasn't changed really. The word I used to describe it was "fine". It's fine.

363
00:32:05,320 --> 00:32:12,520
It does exactly what it needs to do. Yeah. And you know, at the surface, it's the same old. I learned

364
00:32:12,520 --> 00:32:18,120
unit testing with Java in, I still know the year because it was at a conference in 2001

365
00:32:18,120 --> 00:32:24,680
where I first heard about unit testing and I was immediately taken by it. And the concept is

366
00:32:24,680 --> 00:32:31,000
exactly the same since then. You have a runner and you have asserts that you effectively something

367
00:32:31,000 --> 00:32:38,920
equals another comparison function or macro or however it's implemented and something that

368
00:32:38,920 --> 00:32:47,880
prints out if they differ and to various degrees they print it nicely or perhaps in the case of

369
00:32:47,880 --> 00:32:57,160
XCT_ASSERT less nicely the actual difference. And what this does, it gives, it uses macros to

370
00:32:57,160 --> 00:33:06,920
revisit how all of this machinery is done. So for instance you have a #expect macro that unifies all

371
00:33:06,920 --> 00:33:14,680
of the XCT_ASSERT variants, so you no longer have different ones that you spell out like XCT_ASSERT

372
00:33:14,680 --> 00:33:22,040
equal and I think the other one is "exert equal accuracy" if you want to compare two

373
00:33:22,040 --> 00:33:29,080
doubles with a certain accuracy. XCT, assert true/false if you have boogalions that you

374
00:33:29,080 --> 00:33:37,560
compare. All these different variants you have to use. #expect is a single macro that you use,

375
00:33:37,560 --> 00:33:44,120
It can handle all these different variants and it gives you nicer printouts in case of

376
00:33:44,120 --> 00:33:52,360
error logging. I do hope that they sort of steal from the power assert library that we talked about

377
00:33:52,360 --> 00:33:58,600
in the past. I'll add a link to the show note. I'm sorry, I don't have the author's name to

378
00:33:58,600 --> 00:34:05,640
hand right now. It's called power assert. It's a macro library that gives amazing printouts of error

379
00:34:05,640 --> 00:34:11,200
messages when an expression is wrong. It actually details which part of the

380
00:34:11,200 --> 00:34:16,020
expression is what and uses ASCII-R to point to the different elements.

381
00:34:16,020 --> 00:34:20,000
Yeah it's super cool. So you can immediately see what's what it's an

382
00:34:20,000 --> 00:34:26,200
amazing library and I hope they they they you know steal or you know and some

383
00:34:26,200 --> 00:34:32,080
shape or form absorb the awesomeness of this package into the Swift testing

384
00:34:32,080 --> 00:34:35,780
package, so we have it available without having to import anything extra.

385
00:34:35,780 --> 00:34:40,900
It also adds an @test annotations to your test functions.

386
00:34:40,900 --> 00:34:48,220
So it's not any longer required to adhere to certain naming conventions to make tests

387
00:34:48,220 --> 00:34:52,340
discoverable. So there's no longer a test_naming of functions.

388
00:34:52,340 --> 00:34:57,460
They can be named anything and you have the @test annotation and you can even give your

389
00:34:57,460 --> 00:35:00,700
tests speaking names like proper descriptions what they do.

390
00:35:01,220 --> 00:35:06,140
By default, if you don't do anything, it'll just use the test name as the test name, but

391
00:35:06,140 --> 00:35:10,940
you can override that and even use like normal strings with spaces and all that to spell

392
00:35:10,940 --> 00:35:12,780
out what the test does.

393
00:35:12,780 --> 00:35:13,780
Really nice.

394
00:35:13,780 --> 00:35:15,540
It's just a modern test suite really.

395
00:35:15,540 --> 00:35:24,060
It has parameterized testing so you can run many tests that just differ in input parameters.

396
00:35:24,060 --> 00:35:25,780
And the recommendation is already great.

397
00:35:25,780 --> 00:35:29,060
There's a great guide on how to convert tests over.

398
00:35:29,060 --> 00:35:36,580
I've actually tried this out with one of our packages to see how this works and if it's

399
00:35:36,580 --> 00:35:37,580
already usable.

400
00:35:37,580 --> 00:35:38,580
And it is.

401
00:35:38,580 --> 00:35:45,860
I think the only thing I noticed is that there is no class setup function at the moment.

402
00:35:45,860 --> 00:35:53,780
So a class test up, if you have a XCTest case, if you have a class setup, it runs once per

403
00:35:53,780 --> 00:36:02,660
suite, whereas an instance setup runs before each test. So right now you'd have to sort of fake that

404
00:36:02,660 --> 00:36:08,500
by keeping a little Boolean around where you mark if it's run already, if you have need for that.

405
00:36:08,500 --> 00:36:14,740
But other than that, everything I needed to convert over that test was there, and the output is nice.

406
00:36:14,740 --> 00:36:23,140
You need a nightly toolchain right now to use it, but it's all documented how to use it and looks

407
00:36:23,140 --> 00:36:28,260
looks like really great. I'm excited about this. I can't wait to have this around. I

408
00:36:28,260 --> 00:36:34,100
suspect it'll be Swift 5.10 when this will come. I don't think this will be any of the

409
00:36:34,100 --> 00:36:41,520
dot releases of 5.9. So I think we're looking at Spring. But yeah, I mean, Spring can't

410
00:36:41,520 --> 00:36:43,300
come soon enough to be honest.

411
00:36:43,300 --> 00:36:51,500
Yeah, yeah, it does look really, really great. And I think the fact that this is being developed

412
00:36:51,500 --> 00:36:54,180
as an open source package rather than something.

413
00:36:54,180 --> 00:36:57,580
'Cause obviously testing is a big part

414
00:36:57,580 --> 00:37:01,960
of what iOS applications and macOS applications do.

415
00:37:01,960 --> 00:37:03,740
And it's a big part of what Xcode does.

416
00:37:03,740 --> 00:37:06,460
And there's obviously Xcode integration with XCTest

417
00:37:06,460 --> 00:37:09,980
in the current releases of Xcode.

418
00:37:09,980 --> 00:37:12,420
And I think that the fact that this is being released

419
00:37:12,420 --> 00:37:16,520
as a open source Swift package is a really good sign

420
00:37:16,520 --> 00:37:21,060
that that interface between test results

421
00:37:21,060 --> 00:37:23,320
and Xcode showing you test results

422
00:37:23,320 --> 00:37:25,460
might become a little more flexible.

423
00:37:25,460 --> 00:37:27,120
And that's mainly what I wrote about

424
00:37:27,120 --> 00:37:29,860
in the newsletter on Friday.

425
00:37:29,860 --> 00:37:33,940
My hope that that would be the case

426
00:37:33,940 --> 00:37:37,020
to enable things like different testing strategies

427
00:37:37,020 --> 00:37:38,220
and different testing libraries.

428
00:37:38,220 --> 00:37:40,440
And wouldn't it be wonderful if we could,

429
00:37:40,440 --> 00:37:45,860
if Swift could support lots of different testing approaches,

430
00:37:45,860 --> 00:37:48,520
not just one blessed testing approach,

431
00:37:48,520 --> 00:37:51,000
even if that bless testing approach is great.

432
00:37:51,000 --> 00:37:54,600
- Yeah, I mean, I'm pretty sure it will be

433
00:37:54,600 --> 00:37:57,480
because I mean, functionally it's a drop in replacement

434
00:37:57,480 --> 00:38:00,120
for the existing system and there's lots of,

435
00:38:00,120 --> 00:38:02,640
there are lots of other packages,

436
00:38:02,640 --> 00:38:05,880
quick and nimble that are built alongside at least,

437
00:38:05,880 --> 00:38:09,200
if not on top of XCTest,

438
00:38:09,200 --> 00:38:12,420
point three also have a number of test extension packages

439
00:38:12,420 --> 00:38:13,960
which make use of XCTest

440
00:38:13,960 --> 00:38:16,720
and all this should still just work

441
00:38:16,720 --> 00:38:18,880
and be possible to extend and build on top of.

442
00:38:18,880 --> 00:38:19,940
- Of course, yeah.

443
00:38:19,940 --> 00:38:24,120
But the problem with those things,

444
00:38:24,120 --> 00:38:25,160
especially QUIC and Nimble,

445
00:38:25,160 --> 00:38:28,360
is that the way that Xcode reports those tests

446
00:38:28,360 --> 00:38:30,480
is because everything has to effectively

447
00:38:30,480 --> 00:38:34,320
be done within one XC test.

448
00:38:34,320 --> 00:38:36,800
And so your test suite passes or fails,

449
00:38:36,800 --> 00:38:38,840
and they do things to make that a little easier.

450
00:38:38,840 --> 00:38:43,000
But I'm hoping that this ushers in a new era

451
00:38:43,000 --> 00:38:48,000
of decoupling the tight integration between that.

452
00:38:48,000 --> 00:38:50,960
- Yeah, I mean, just the fact that this is

453
00:38:50,960 --> 00:38:54,000
an open source package gives all these developers

454
00:38:54,000 --> 00:38:56,640
of these test extensions an opportunity to chime in.

455
00:38:56,640 --> 00:38:57,720
And they already have.

456
00:38:57,720 --> 00:39:02,720
I've seen Stephen Sellez too, listing their packages

457
00:39:02,720 --> 00:39:07,920
and highlighting in which ways they build on top of XC tests

458
00:39:10,000 --> 00:39:19,920
and sort of hinting at these would be potentially useful things to have inside this package.

459
00:39:19,920 --> 00:39:25,120
So you don't need to actually onboard different new test libraries. And he didn't say so,

460
00:39:25,120 --> 00:39:30,960
but I'm pretty sure that Stephen and Brandon would be happy to see functionality moved out of their

461
00:39:30,960 --> 00:39:36,240
packages into a core testing library such that they wouldn't have to maintain it anymore and

462
00:39:36,240 --> 00:39:41,920
could use it. So I'm really excited about this for all these reasons. It's built out in the open

463
00:39:41,920 --> 00:39:48,800
and gives all of these other test extension packages and authors a chance to influence

464
00:39:48,800 --> 00:39:52,880
the direction. And I think that looks really, really great and promising.

465
00:39:52,880 --> 00:40:02,320
Yeah, it is. It's great. Okay, I'm going to start my last package recommendation this week

466
00:40:02,320 --> 00:40:04,000
with a question for you, Sven.

467
00:40:05,360 --> 00:40:09,600
Howdy, is it quiz time again? Kind of, it's just a one question quiz.

468
00:40:09,600 --> 00:40:16,640
How many times have you written a regular expression to detect an email address?

469
00:40:16,640 --> 00:40:22,960
Not a lot to be honest. I don't know. Not a lot, but probably more than zero, right?

470
00:40:22,960 --> 00:40:33,120
Perhaps, yeah. I mean, I know I'd probably look for a... I know this is a hotly debated topic,

471
00:40:33,120 --> 00:40:39,120
you know, like using Regex stuff to parse certain things. And I know, especially the email spec is

472
00:40:39,120 --> 00:40:44,880
not as easy as you think it is, right? Even the domain name spec isn't as easy as you think it is.

473
00:40:44,880 --> 00:40:49,600
So. And you have to incorporate all the domain name spec plus the email spec, right? Yeah.

474
00:40:49,600 --> 00:40:55,520
I might even go so far as just to look for a single @ sign and make that the, you know,

475
00:40:55,520 --> 00:41:02,240
depending on how rigorous the check has to be. But sure. And that's the temptation. It feels like

476
00:41:02,240 --> 00:41:06,760
such an easy problem to solve. You just go, well we'll just split on the @ and

477
00:41:06,760 --> 00:41:12,600
then if it's got a dot on the right hand side and something of this kind of

478
00:41:12,600 --> 00:41:17,080
alphanumeric character on the left hand side, we're fine, right? It feels so easy

479
00:41:17,080 --> 00:41:23,360
but it's not it's never that easy. So my final recommendation for this week is by

480
00:41:23,360 --> 00:41:28,680
Dave Poirier and it's called Swift Email Validator and one thing that I didn't

481
00:41:28,680 --> 00:41:34,520
even realized till I read this readme is that you mentioned the email spec.

482
00:41:34,520 --> 00:41:45,120
Well actually there are five email specs. Of course there are. There is RFC 8222047

483
00:41:45,120 --> 00:41:54,200
5321 5322 for the stuff they forgot to put in 5321 and RFC 6531.

484
00:41:54,200 --> 00:42:00,800
So yeah, this email addresses are notoriously difficult to validate and

485
00:42:00,800 --> 00:42:05,520
most of the time you might just offload that functionality to your backend

486
00:42:05,520 --> 00:42:09,980
server. You might just say take your iOS app or your Mac app, pass whatever the

487
00:42:09,980 --> 00:42:14,000
input is back to your server. But if you do want to do some smart validation on

488
00:42:14,000 --> 00:42:21,120
the client, I think the comprehensive nature of this package by Dave Poirier

489
00:42:21,120 --> 00:42:27,960
is worth taking a look at. It certainly seems to be extremely

490
00:42:27,960 --> 00:42:32,880
comprehensive. You can have email addresses that have IP addresses in them.

491
00:42:32,880 --> 00:42:45,400
You can have email addresses that have IPv6 email addresses in them. And suddenly the can is open and the worms are

492
00:42:45,400 --> 00:42:53,460
everywhere. Yes so yes do not do not try and write a regular expression to validate

493
00:42:53,460 --> 00:42:58,640
email. You will get it wrong and I mean that doesn't even start to think about

494
00:42:58,640 --> 00:43:05,520
all the internationalization character sets and all sorts of stuff. They're all

495
00:43:05,520 --> 00:43:10,640
valid in email so yeah it's it's a difficult thing to do so maybe try this

496
00:43:10,640 --> 00:43:16,760
package by Dave instead. That's Swift email validator by Dave Poirier. Nice.

497
00:43:16,760 --> 00:43:21,640
Well at the very least you'll have someone to yell at if it doesn't work.

498
00:43:21,640 --> 00:43:27,000
Great. Well I don't have a third, well I did have a third package but you sniped

499
00:43:27,000 --> 00:43:36,700
that so I'm out. But I sniped it, yeah. So we will call that an episode and we

500
00:43:36,700 --> 00:43:39,460
We'll see you back here in a couple of weeks.

501
00:43:39,460 --> 00:43:41,520
- See you in two weeks, bye bye.

502
00:43:41,520 --> 00:43:42,720
- See you then, bye bye.