1
00:00:00,000 --> 00:00:05,600
But we should probably start by saying it's been a while, because it has.

2
00:00:05,600 --> 00:00:08,840
It's been a little while since we did an episode of the podcast.

3
00:00:08,840 --> 00:00:14,920
A few things came up and we we ended up having to postpone a couple of episodes.

4
00:00:14,920 --> 00:00:17,680
But we are back now. Yeah, we better late than never.

5
00:00:17,680 --> 00:00:20,400
We I think we skipped one because it was slow news.

6
00:00:20,400 --> 00:00:26,000
And now we've racked up a whole list of news items such that we get into the habit

7
00:00:26,000 --> 00:00:27,720
of skipping them. It's easy to continue.

8
00:00:27,720 --> 00:00:31,600
Yeah, yeah, that's what we want. We want a skipping streak there.

9
00:00:31,600 --> 00:00:38,240
And also, I mean, I think it's probably worth just briefly saying that the

10
00:00:38,240 --> 00:00:43,600
I think after our last recording, we both agreed that we would reduce

11
00:00:43,600 --> 00:00:47,160
the frequency of the podcast a little bit from every two weeks.

12
00:00:47,160 --> 00:00:52,560
And we didn't intend it to be this long between episodes.

13
00:00:54,040 --> 00:00:59,240
But but we may we may switch to maybe every three weeks or even every four weeks,

14
00:00:59,240 --> 00:01:03,240
occasionally a schedule, but certainly more frequent than it has been over the last couple of months.

15
00:01:03,240 --> 00:01:04,920
Yeah, definitely.

16
00:01:04,920 --> 00:01:08,760
So we should probably start with our plans around Swift 6.

17
00:01:08,760 --> 00:01:13,400
We just finished processing all of the Swift 5.10

18
00:01:13,400 --> 00:01:18,080
builds, and so we're fully up to date with the release version of 5.10,

19
00:01:18,080 --> 00:01:19,840
which came out a few weeks ago.

20
00:01:19,840 --> 00:01:21,920
I forget exactly when, but it was a few weeks ago.

21
00:01:22,320 --> 00:01:25,040
And the next version of Swift will be Swift 6.

22
00:01:25,040 --> 00:01:28,880
And we actually have some quite big plans for Swift 6.

23
00:01:28,880 --> 00:01:34,280
So as well as, you know, our kind of standard

24
00:01:34,280 --> 00:01:40,120
routine for a new version of Swift is that some point during the beta cycle,

25
00:01:40,120 --> 00:01:45,440
we will update the system so that it can accept packages with the next version of Swift.

26
00:01:45,440 --> 00:01:49,600
And then as we get towards the final release of it,

27
00:01:49,640 --> 00:01:54,520
then we upgrade the systems to to fully support the release version

28
00:01:54,520 --> 00:01:57,640
and process all of the builds at that point.

29
00:01:57,640 --> 00:02:02,800
And we're going to do something a little bit different.

30
00:02:02,800 --> 00:02:07,080
This one, because Swift 6 is a is a obviously a major version release,

31
00:02:07,080 --> 00:02:09,160
which is always a big event.

32
00:02:09,160 --> 00:02:12,640
And there are some breaking changes coming in Swift 6,

33
00:02:12,640 --> 00:02:14,520
which you've probably heard about already.

34
00:02:15,800 --> 00:02:20,280
They're all around structured concurrency and strict concurrency.

35
00:02:20,280 --> 00:02:24,600
And you can actually switch on all the warnings around that you will

36
00:02:24,600 --> 00:02:26,680
that will become errors in Swift 6.

37
00:02:26,680 --> 00:02:29,760
You can switch them all on now in Swift 5.10.

38
00:02:29,760 --> 00:02:32,440
And how do you do that exactly, Dave?

39
00:02:32,440 --> 00:02:33,640
Would you would you tell us?

40
00:02:33,640 --> 00:02:38,600
You use you use one of two flags.

41
00:02:38,600 --> 00:02:43,080
And one of them is enable experimental feature.

42
00:02:43,080 --> 00:02:45,640
And one of them is enable upcoming feature.

43
00:02:45,640 --> 00:02:47,960
And if you get them wrong, as I did,

44
00:02:47,960 --> 00:02:53,760
it appears like your entire project is perfect.

45
00:02:53,760 --> 00:02:56,120
One of them will make you happy, the other one will make you sad.

46
00:02:56,120 --> 00:03:02,440
The one that made me happy was was it that it showed me that there was nothing to do.

47
00:03:02,440 --> 00:03:08,240
Yeah, what Sven is referring to there is that I did try

48
00:03:08,240 --> 00:03:10,800
and switch this feature on and I got it wrong.

49
00:03:10,800 --> 00:03:14,440
And if you want the full story behind that, it's on the the apology

50
00:03:14,440 --> 00:03:18,520
for my mistake is on the latest iOS Dev Weekly introduction.

51
00:03:18,520 --> 00:03:20,200
So you can go and read it there.

52
00:03:20,200 --> 00:03:28,160
But yes, we can we can as of Swift 5.10, we can get a preview of all these

53
00:03:28,160 --> 00:03:32,920
what will become errors.

54
00:03:32,920 --> 00:03:38,280
And what we want to do is track the compatibility of packages

55
00:03:38,280 --> 00:03:41,600
over the Swift 6 beta period.

56
00:03:42,280 --> 00:03:46,120
So we actually was it the end of last week

57
00:03:46,120 --> 00:03:51,360
kicked off our very first Swift 6 preview build, which is not

58
00:03:51,360 --> 00:03:52,760
it's not in beta yet.

59
00:03:52,760 --> 00:03:56,360
This is a nightly build of the tool chain.

60
00:03:56,360 --> 00:03:58,920
But yeah, we are.

61
00:03:58,920 --> 00:04:01,000
Well, I think I think it actually just finished processing.

62
00:04:01,000 --> 00:04:03,440
Yeah, it did. Yeah, it finished earlier this morning.

63
00:04:03,440 --> 00:04:08,320
And this is not the the whole compatibility matrix, because right now

64
00:04:08,320 --> 00:04:12,400
the nightlies have trouble building with Xcode build.

65
00:04:12,400 --> 00:04:17,240
So it's currently only testing the Swift PM platforms, which is Mac OS and Linux

66
00:04:17,240 --> 00:04:18,960
by Swift PM platforms.

67
00:04:18,960 --> 00:04:21,320
I mean, builds that you run with Swift build.

68
00:04:21,320 --> 00:04:25,720
And that obviously doesn't work for iOS builds and the like.

69
00:04:25,720 --> 00:04:29,600
So it's it's a slice of what we'll eventually build.

70
00:04:29,600 --> 00:04:36,000
Yeah, and we got the results in and what we're tracking really is the error count.

71
00:04:36,000 --> 00:04:39,760
So there's a instrumentation in the tool chains

72
00:04:39,760 --> 00:04:43,080
where the compiler spits out lots of diagnostics.

73
00:04:43,080 --> 00:04:46,600
And one of them is the number of Swift 6 errors

74
00:04:46,600 --> 00:04:49,480
that it counted when it did the compile.

75
00:04:49,480 --> 00:04:57,360
And what we're also planning to do is host a page on Swift Package Index,

76
00:04:57,360 --> 00:05:01,680
which shows compatibility of Swift 6 over time.

77
00:05:01,680 --> 00:05:05,880
Now, that page is not going to be released immediately.

78
00:05:05,880 --> 00:05:09,320
Partly because it doesn't exist yet, but partly because what we want to do

79
00:05:09,320 --> 00:05:13,680
by the time we launch that page is have some data to show, hopefully,

80
00:05:13,680 --> 00:05:16,560
the number of Swift 6 errors reducing already.

81
00:05:16,560 --> 00:05:19,920
And then throughout the beta period of Swift 6,

82
00:05:19,920 --> 00:05:25,120
we will maintain that page and keep it updated with how

83
00:05:25,120 --> 00:05:29,040
all the package ecosystem is doing with Swift 6 compatibility.

84
00:05:29,040 --> 00:05:30,640
Yeah. Yeah.

85
00:05:30,640 --> 00:05:34,160
And the idea there overall is to to sort of help a bit

86
00:05:34,560 --> 00:05:39,000
with the transition, just following people on social media.

87
00:05:39,000 --> 00:05:43,120
There's there's a lot of concern that this, you know, the 5/6 transition

88
00:05:43,120 --> 00:05:48,840
might be kind of similar to the 2/3, Swift 2 to 3 transition in the past,

89
00:05:48,840 --> 00:05:50,640
which I don't even recall.

90
00:05:50,640 --> 00:05:55,400
I don't think I was using Swift at the time in an actual product

91
00:05:55,400 --> 00:05:59,600
because the stuff we were working on didn't didn't really lend itself to be,

92
00:05:59,600 --> 00:06:02,640
you know, the adoption at that time.

93
00:06:03,240 --> 00:06:07,720
So I wasn't really one of those people who I guess were burned by that transition.

94
00:06:07,720 --> 00:06:10,800
And but but that's still lingers, right?

95
00:06:10,800 --> 00:06:12,760
That pain is still there.

96
00:06:12,760 --> 00:06:15,560
Yeah. In people's memory.

97
00:06:15,560 --> 00:06:18,280
I did have code that was affected by that transition.

98
00:06:18,280 --> 00:06:22,600
And while my code was not terribly painful to convert, it was certainly

99
00:06:22,600 --> 00:06:28,440
it's that thing where if you if you present the world in a certain way

100
00:06:28,440 --> 00:06:30,480
and then suddenly present the world in a different way,

101
00:06:30,480 --> 00:06:31,800
people are just going to get upset.

102
00:06:31,800 --> 00:06:36,760
And I remember the the the wailing and gnashing of teeth at the time.

103
00:06:36,760 --> 00:06:42,080
And and I think I think it's it's everything we can do to prevent

104
00:06:42,080 --> 00:06:45,480
that kind of situation, to just talk about it as much as we can

105
00:06:45,480 --> 00:06:48,880
before it happens is going to make the process smoother.

106
00:06:48,880 --> 00:06:49,920
Yeah. Yeah.

107
00:06:49,920 --> 00:06:53,680
And I think it bears, you know, stressing that there's no reason to believe

108
00:06:53,680 --> 00:06:57,160
it'll be like that because and for a number of reasons.

109
00:06:57,160 --> 00:07:01,080
So first off, there'll be they continue to be a Swift five mode.

110
00:07:01,080 --> 00:07:05,600
So even if you use the Swift six compiler on a module by module basis,

111
00:07:05,600 --> 00:07:10,280
you will be able to just compile your code in Swift five mode

112
00:07:10,280 --> 00:07:11,320
and nothing will change.

113
00:07:11,320 --> 00:07:14,840
So you you are not forced to do any of the things that are

114
00:07:14,840 --> 00:07:19,200
good ideas to do in general when when Swift six comes around.

115
00:07:19,200 --> 00:07:22,320
You know, it has benefits doing these things, but you're not forced to.

116
00:07:22,320 --> 00:07:24,760
You don't have to do that immediately.

117
00:07:24,760 --> 00:07:27,520
And you don't have to do it for the whole project at the same time.

118
00:07:27,520 --> 00:07:29,680
So you can pick your battles,

119
00:07:29,680 --> 00:07:35,400
pull the things ahead, you know, pick pick the ones that you want to tackle first,

120
00:07:35,400 --> 00:07:38,600
get get a feel for what it means, do it.

121
00:07:38,600 --> 00:07:42,760
And then, you know, by the end, over potentially a long period of time,

122
00:07:42,760 --> 00:07:44,720
you'll be able to transition over.

123
00:07:44,720 --> 00:07:49,800
And also, there's going to be like a host of resources to help you.

124
00:07:49,800 --> 00:07:53,480
I think a lot of these things are going to be quite mechanical

125
00:07:53,480 --> 00:07:57,040
just by following people, exploring what it means.

126
00:07:58,440 --> 00:08:00,880
Even if you have a large error count,

127
00:08:00,880 --> 00:08:05,840
often it's just a few root sources that need changing.

128
00:08:05,840 --> 00:08:10,600
That'll make that number dwindle like massively by just making a couple of tweaks.

129
00:08:10,600 --> 00:08:11,000
Yeah.

130
00:08:11,000 --> 00:08:15,400
So when I did find out how to switch around properly,

131
00:08:15,400 --> 00:08:19,800
we had around 500 and something errors.

132
00:08:19,800 --> 00:08:22,280
But as I took a quick look through our

133
00:08:22,280 --> 00:08:28,200
kind of list of of of warnings inside of Swift 5.10,

134
00:08:28,520 --> 00:08:32,080
and there were so many that would look like the same thing.

135
00:08:32,080 --> 00:08:36,280
Like once we fix one thing, I think, you know, it'll get rid of 100 errors.

136
00:08:36,280 --> 00:08:38,800
And once we fix another thing, it'll get rid of another hundred.

137
00:08:38,800 --> 00:08:40,360
Yeah. Yeah.

138
00:08:40,360 --> 00:08:43,080
Look, there were lots of common root causes.

139
00:08:43,080 --> 00:08:44,720
Yeah, it's actually interesting.

140
00:08:44,720 --> 00:08:47,880
I believe you mentioned they are around the current

141
00:08:47,880 --> 00:08:51,080
our dependency injection structure is some of them.

142
00:08:51,080 --> 00:08:56,800
Yeah. Which is actually interesting because this is something I wanted to update.

143
00:08:57,440 --> 00:08:59,280
I have been wanting to update for quite a while.

144
00:08:59,280 --> 00:09:01,880
So this is based on a quite,

145
00:09:01,880 --> 00:09:04,960
I wouldn't say old in the sense that it's outdated,

146
00:09:04,960 --> 00:09:07,640
but it's been a few years that we started adopting this.

147
00:09:07,640 --> 00:09:10,480
All this was published by Point Free Code.

148
00:09:10,480 --> 00:09:13,320
That's a sort of a mechanism to do a dependency injection.

149
00:09:13,320 --> 00:09:16,560
And it's valid. It works really well.

150
00:09:16,560 --> 00:09:20,440
It has allowed us to write tests that would otherwise have been really difficult to write.

151
00:09:20,440 --> 00:09:23,480
They have, however,

152
00:09:23,480 --> 00:09:26,400
so there are some downsides to this mechanism,

153
00:09:26,400 --> 00:09:30,400
and that's mainly around composing it between different packages and so on.

154
00:09:30,400 --> 00:09:35,280
Point Free Code have a new mechanism, a superseding mechanism

155
00:09:35,280 --> 00:09:39,400
with their dependency package that you can use instead of this,

156
00:09:39,400 --> 00:09:42,200
has the same features, allows easier composition.

157
00:09:42,200 --> 00:09:46,000
And I've always wanted to actually make a switch over

158
00:09:46,000 --> 00:09:48,080
because it's the better, the more modern system.

159
00:09:48,080 --> 00:09:50,360
But, you know, we have a working system.

160
00:09:50,360 --> 00:09:52,280
You have no real reason to change.

161
00:09:52,800 --> 00:09:54,400
So I haven't done it.

162
00:09:54,400 --> 00:09:57,680
This is actually an opportunity to do both at the same time, you know,

163
00:09:57,680 --> 00:10:01,320
get rid of that debt.

164
00:10:01,320 --> 00:10:06,280
And I have sort of a bigger reason to do it at the same time.

165
00:10:06,280 --> 00:10:07,760
I actually quite like that.

166
00:10:07,760 --> 00:10:10,280
So I'm not aware of the new system that they've come up with,

167
00:10:10,280 --> 00:10:14,000
but I just hope it's as easy as this one, because I really like the

168
00:10:14,000 --> 00:10:16,680
the way that that works at the moment.

169
00:10:16,680 --> 00:10:20,520
It is simple to, for a method that you need to

170
00:10:21,360 --> 00:10:23,640
kind of step out for testing.

171
00:10:23,640 --> 00:10:26,040
It's a really easy way to do that.

172
00:10:26,040 --> 00:10:27,920
Yeah, it'll be similarly easy.

173
00:10:27,920 --> 00:10:30,920
I mean, it's it's really just using macros

174
00:10:30,920 --> 00:10:33,920
to facilitate the same thing, really.

175
00:10:33,920 --> 00:10:36,600
Oh, macros. OK. I think it's based on macros.

176
00:10:36,600 --> 00:10:40,040
Yeah, it's like it's like the environment system in Swift UI

177
00:10:40,040 --> 00:10:43,000
in that you sort of import them.

178
00:10:43,000 --> 00:10:47,920
You import customization points via a dependency clause.

179
00:10:49,280 --> 00:10:53,000
You have sort of a variable that points to this dependency, which you can then

180
00:10:53,000 --> 00:10:56,520
it's automatically populated with a default.

181
00:10:56,520 --> 00:11:00,920
And in tests, you can override those and you don't have any of these typical

182
00:11:00,920 --> 00:11:05,240
downsides of a dependency injection system in that you have initializers

183
00:11:05,240 --> 00:11:08,040
that need to populate all these things, you know, for your types

184
00:11:08,040 --> 00:11:11,080
because you attach it to the type, so to speak. Right.

185
00:11:11,080 --> 00:11:13,520
Not sorry. I said macros.

186
00:11:13,520 --> 00:11:14,880
I meant property wrappers.

187
00:11:14,880 --> 00:11:17,360
That's OK. That makes more sense. Yeah.

188
00:11:18,280 --> 00:11:21,640
But all of that is that's kind of quite deep in the weeds of

189
00:11:21,640 --> 00:11:25,200
of I think we've fallen out a couple of rabbit holes there.

190
00:11:25,200 --> 00:11:31,200
I mean, I think I think we'll we'll talk about Swift 6 more as time goes on.

191
00:11:31,200 --> 00:11:35,880
And we'll probably talk about our progress

192
00:11:35,880 --> 00:11:38,480
in fixing these 500 and something warnings that we've got

193
00:11:38,480 --> 00:11:43,120
in subsequent editions of the podcast, because it is something

194
00:11:43,120 --> 00:11:46,520
that's going to be a common theme over this summer.

195
00:11:46,520 --> 00:11:47,520
Yeah, definitely.

196
00:11:47,800 --> 00:11:49,800
All right.

197
00:11:49,800 --> 00:11:51,800
I think that was it for Swift 6, wasn't it?

198
00:11:51,800 --> 00:11:52,840
It was. Yeah.

199
00:11:52,840 --> 00:11:56,480
Cool. I have a couple of points that I wanted to bring up.

200
00:11:56,480 --> 00:12:01,840
Blog posts and social media posts that I found really interesting

201
00:12:01,840 --> 00:12:03,840
that I've sort of accumulated over the last

202
00:12:03,840 --> 00:12:09,120
well, few weeks that we've been on hiatus.

203
00:12:09,120 --> 00:12:13,360
And the first one is a blog post by Daniel Kennett,

204
00:12:13,360 --> 00:12:17,400
a great blog post called Combining Swift and Swift 6.

205
00:12:17,400 --> 00:12:21,000
And C# on Windows with Swift to CLR.

206
00:12:21,000 --> 00:12:24,000
I I don't recall where I saw this.

207
00:12:24,000 --> 00:12:27,360
I believe it might have been on the Swift forums that he posted this.

208
00:12:27,360 --> 00:12:30,960
This article. Yeah. Great.

209
00:12:30,960 --> 00:12:32,480
It's really well written.

210
00:12:32,480 --> 00:12:36,360
I just read it again because this is from February,

211
00:12:36,360 --> 00:12:39,400
I think early February. So it's been a while.

212
00:12:39,400 --> 00:12:43,600
And I reread it and I liked it all over again.

213
00:12:43,600 --> 00:12:45,760
It's really worth the read.

214
00:12:45,760 --> 00:12:49,240
Even if you, like me, aren't deep into ABI's,

215
00:12:49,240 --> 00:12:54,760
runtimes and C++ translation layers, but he just paints a really nice picture

216
00:12:54,760 --> 00:12:59,360
of of this proof of concept job that he started over the Christmas break.

217
00:12:59,360 --> 00:13:02,680
You were just speaking about rabbit holes.

218
00:13:02,680 --> 00:13:05,280
I think Daniel was quite deep in one there

219
00:13:05,280 --> 00:13:08,800
and tells a really nice story about it.

220
00:13:08,800 --> 00:13:14,960
The story about building a three layer contraption to bridge C# to Swift.

221
00:13:15,520 --> 00:13:20,120
Right. And not only that, he somehow managed to create a helpful image

222
00:13:20,120 --> 00:13:24,280
of these layers, like an actual image with source code and IDEs

223
00:13:24,280 --> 00:13:26,400
and stuff showing how they interact.

224
00:13:26,400 --> 00:13:28,000
It's it's really well done.

225
00:13:28,000 --> 00:13:29,280
That's great. And I read it, too.

226
00:13:29,280 --> 00:13:31,680
And I did think it was it was interesting.

227
00:13:31,680 --> 00:13:34,640
It's also more low level than I like to go normally as well.

228
00:13:34,640 --> 00:13:39,240
And what's really nice is so he sets out this goal where you think, oh, wow,

229
00:13:39,240 --> 00:13:43,000
is he going to manage that or is that going to be the proposed about the

230
00:13:43,480 --> 00:13:46,080
aspirational, but he actually succeeds.

231
00:13:46,080 --> 00:13:49,000
So he lays out nicely at the start what he's trying to do.

232
00:13:49,000 --> 00:13:53,320
And he he managed it in the end, which is to build both a Swift UI

233
00:13:53,320 --> 00:13:58,960
and a C# Windows app that sort of interfaces with a common back end

234
00:13:58,960 --> 00:14:03,760
that is written in in Swift and sort of is targeted by both these front ends

235
00:14:03,760 --> 00:14:06,800
as the instrumentation to to what the back end does.

236
00:14:06,800 --> 00:14:09,720
And the back end is a camera API.

237
00:14:10,200 --> 00:14:13,720
So to manage camera feeds and that sort of thing,

238
00:14:13,720 --> 00:14:19,240
which is just to give some context to that, that's what Daniel's apps do.

239
00:14:19,240 --> 00:14:20,760
Yeah, exactly.

240
00:14:20,760 --> 00:14:26,000
Yeah. And even not only did he write this post and, you know,

241
00:14:26,000 --> 00:14:31,160
talk about his journey, he even managed to generalize everything

242
00:14:31,160 --> 00:14:37,280
into a tool that does the automation of generating these translation layers.

243
00:14:37,280 --> 00:14:40,800
So it's not just all, you know, hand assembled stuff that sort of

244
00:14:40,800 --> 00:14:44,160
managed to work together somehow.

245
00:14:44,160 --> 00:14:47,560
But he actually managed to to productize it in a sense

246
00:14:47,560 --> 00:14:52,960
so that a lot of the mechanics of it are hidden away and done by a tool,

247
00:14:52,960 --> 00:14:55,240
which is really promising.

248
00:14:55,240 --> 00:14:57,200
And yeah, I mean, one thing I'd like to add,

249
00:14:57,200 --> 00:15:02,280
we've sort of seen some really interesting posts appear on Swift.org

250
00:15:02,280 --> 00:15:04,960
recently around Swift as a language

251
00:15:05,800 --> 00:15:08,880
appearing in outside the typical habitat.

252
00:15:08,880 --> 00:15:11,840
And I think that would be a would have been a post that had been

253
00:15:11,840 --> 00:15:14,680
really nice to see on Swift.org itself.

254
00:15:14,680 --> 00:15:16,920
Maybe it's not too late. Maybe that could still happen.

255
00:15:16,920 --> 00:15:20,600
But I think that would be worthwhile having and giving it,

256
00:15:20,600 --> 00:15:23,200
you know, another boost or more reach in general.

257
00:15:23,200 --> 00:15:27,680
I might bring that up at the Swift website workgroup meeting, actually,

258
00:15:27,680 --> 00:15:28,480
because I think you're right.

259
00:15:28,480 --> 00:15:30,440
I think that would I think it would be a good choice.

260
00:15:30,440 --> 00:15:33,640
Cool. Another bit of news

261
00:15:34,040 --> 00:15:37,600
since we're talking about Swift on Windows, I saw that the other day.

262
00:15:37,600 --> 00:15:43,560
Helge Hess posted that he managed to get Swift

263
00:15:43,560 --> 00:15:47,000
running on ARM Windows 11 via

264
00:15:47,000 --> 00:15:50,800
VMware's Fusion on Apple Silicon.

265
00:15:50,800 --> 00:15:55,560
And I found that really interesting because when I initially considered,

266
00:15:55,560 --> 00:15:59,760
you know, I think I was thinking about how to get started with Swift on Windows,

267
00:15:59,760 --> 00:16:01,840
you know, just to get a feel for how it works.

268
00:16:03,080 --> 00:16:06,520
I always run into I don't even have a Windows machine.

269
00:16:06,520 --> 00:16:07,600
And, you know, I have

270
00:16:07,600 --> 00:16:11,840
I have an old Intel Mac around, I think, but sort of

271
00:16:11,840 --> 00:16:16,280
my initial take would be my first step would be to to spin up a VM.

272
00:16:16,280 --> 00:16:19,160
But then you immediately run into the architecture problem, you know,

273
00:16:19,160 --> 00:16:24,000
ARM Windows and and Swift probably not working on it.

274
00:16:24,000 --> 00:16:27,440
And so I found that really interesting to see that it actually can be done.

275
00:16:27,440 --> 00:16:31,120
And Helge said, it's it's not all that involved.

276
00:16:31,120 --> 00:16:34,560
So actually might give that a spin.

277
00:16:34,560 --> 00:16:38,960
I doubt we'll do our compatibility testing on Windows on ARM,

278
00:16:38,960 --> 00:16:42,920
but it certainly would help to get a feel for how it how it could be set up

279
00:16:42,920 --> 00:16:48,960
if if it was possible to do that locally on a VM, just on my machine.

280
00:16:48,960 --> 00:16:51,200
So I found that really interesting to see.

281
00:16:51,200 --> 00:16:55,640
Yeah, I think it does bring up the the there's a little bit of a small

282
00:16:55,640 --> 00:17:00,200
a baby elephant in the room, which is we have Linux

283
00:17:00,720 --> 00:17:07,840
compatibility testing, but Linux is a is a many faceted beast.

284
00:17:07,840 --> 00:17:09,800
And there are many different Linuxes.

285
00:17:09,800 --> 00:17:14,680
And we don't we're not we are very unspecific

286
00:17:14,680 --> 00:17:16,800
about what type of Linux we are testing on.

287
00:17:16,800 --> 00:17:22,760
And and so as we come to think about Windows compatibility and Swift,

288
00:17:22,760 --> 00:17:25,880
that's one of those as well, where it's like, well, there's Windows

289
00:17:25,880 --> 00:17:28,480
compatibility and then there's Windows compatibility.

290
00:17:28,480 --> 00:17:33,480
Yeah. And I also I don't think we'll do ARM64 on Windows, mainly because

291
00:17:33,480 --> 00:17:37,640
ARM64 Windows has had a bit of a rocky

292
00:17:37,640 --> 00:17:40,600
start, I think.

293
00:17:40,600 --> 00:17:44,400
And I think it's the vast, vast majority of Windows

294
00:17:44,400 --> 00:17:47,920
is still Intel x86 Windows.

295
00:17:47,920 --> 00:17:51,600
That's not to say that there's no ARM64 Windows out there,

296
00:17:51,600 --> 00:17:55,080
but I think it's not it's not on the verge of becoming dominant

297
00:17:55,080 --> 00:17:56,040
or anything like that.

298
00:17:56,040 --> 00:17:56,840
Yeah, definitely.

299
00:17:56,840 --> 00:18:00,680
And it certainly is unlikely to be the cheapest way of actually

300
00:18:00,680 --> 00:18:02,520
hosting those builders. Right.

301
00:18:02,520 --> 00:18:07,280
Yeah. So I think going with Intel will be the wise choice there.

302
00:18:07,280 --> 00:18:13,200
While we're on the subject of Windows compatibility or sorry,

303
00:18:13,200 --> 00:18:15,960
Windows and Swift,

304
00:18:15,960 --> 00:18:19,800
there's a blog post, another blog post from Jeremy Day

305
00:18:19,800 --> 00:18:23,160
from the browser company who have been working on

306
00:18:24,120 --> 00:18:26,240
their Arc browser for Windows.

307
00:18:26,240 --> 00:18:29,240
And in fact, their Arc browser now is out in Windows,

308
00:18:29,240 --> 00:18:31,440
and that is a Swift application.

309
00:18:31,440 --> 00:18:34,840
And this blog post is called Swift Tooling Windows Edition.

310
00:18:34,840 --> 00:18:36,800
And in it, he talks about debugging.

311
00:18:36,800 --> 00:18:40,280
He talks about how he edits code and lots of stuff.

312
00:18:40,280 --> 00:18:45,160
And it's quite an extensive blog post, but definitely worth a read on this subject.

313
00:18:45,160 --> 00:18:47,600
Yeah, I think I saw that as well.

314
00:18:47,600 --> 00:18:48,360
That's really nice.

315
00:18:48,360 --> 00:18:52,640
I just love seeing Swift pop up in all these different places now.

316
00:18:52,920 --> 00:18:57,440
It seems to be happening more frequently, or is it just my imagination?

317
00:18:57,440 --> 00:19:01,240
I think it does. Yeah, I think I think certainly the work

318
00:19:01,240 --> 00:19:03,080
that the browser company have been doing has

319
00:19:03,080 --> 00:19:08,680
generated. Genuine interest in Swift on Windows,

320
00:19:08,680 --> 00:19:13,640
I think that's been really instrumental in what we've been seeing, I think.

321
00:19:13,640 --> 00:19:16,960
Yeah. We'll include links to all of those articles in the show notes.

322
00:19:16,960 --> 00:19:17,960
Yeah, definitely.

323
00:19:17,960 --> 00:19:21,240
And just to wrap this up, the new section.

324
00:19:21,840 --> 00:19:25,520
And I think you've you had this in iOS Dev Weekly as well, didn't you?

325
00:19:25,520 --> 00:19:29,440
The Playdate blog post on Swift.org.

326
00:19:29,440 --> 00:19:31,240
I did. Yeah.

327
00:19:31,240 --> 00:19:34,040
Yeah. This is a blog post about

328
00:19:34,040 --> 00:19:38,080
running in the scene of Swift in unusual places,

329
00:19:38,080 --> 00:19:41,800
writing Playdate games in Swift.

330
00:19:41,800 --> 00:19:44,760
And Playdate is a well, how would you describe Playdate?

331
00:19:44,760 --> 00:19:49,680
Playdate is a is a handheld gaming

332
00:19:50,920 --> 00:19:56,320
console, I guess, which is it has a little cortex chip in it

333
00:19:56,320 --> 00:19:59,840
and it has a one bit, so black and white only

334
00:19:59,840 --> 00:20:04,640
screen in it, which is quite high resolution,

335
00:20:04,640 --> 00:20:07,800
but obviously just a monochromatic display.

336
00:20:07,800 --> 00:20:14,600
And it is made by Panic, who make things like Transmit,

337
00:20:14,600 --> 00:20:19,280
which is the FTP and SFTP client and Nova, the text editor,

338
00:20:19,600 --> 00:20:21,000
which is really good.

339
00:20:21,000 --> 00:20:23,760
And in fact, they've made so many apps over the years.

340
00:20:23,760 --> 00:20:27,000
They're cornerstone of independent Mac development.

341
00:20:27,000 --> 00:20:32,880
And they a few years ago decided to.

342
00:20:32,880 --> 00:20:36,680
I think the original story is, if I remember rightly,

343
00:20:36,680 --> 00:20:39,280
I may be getting this wrong, but the original story, if I remember rightly,

344
00:20:39,280 --> 00:20:42,880
is that they wanted to make a

345
00:20:42,880 --> 00:20:47,160
kind of long service gift for some of their employees

346
00:20:47,160 --> 00:20:49,040
that had been there a very long time.

347
00:20:49,040 --> 00:20:51,760
And they they thought about making a little a little

348
00:20:51,760 --> 00:20:54,080
because they actually do publish some games as well.

349
00:20:54,080 --> 00:20:59,120
They publish several games on Steam and on various different platforms.

350
00:20:59,120 --> 00:21:02,760
And I think they they want the initial idea was this,

351
00:21:02,760 --> 00:21:05,160
that it started as one of those.

352
00:21:05,160 --> 00:21:09,640
And then they decided to do a kind of public release of it.

353
00:21:09,640 --> 00:21:13,600
And they hit that public release right during

354
00:21:13,600 --> 00:21:17,280
all the kind of development of it right during Covid.

355
00:21:17,560 --> 00:21:20,120
And also the chip shortage.

356
00:21:20,120 --> 00:21:24,640
So I think it's had in fact, I know it's had quite a difficult

357
00:21:24,640 --> 00:21:27,720
journey to being released.

358
00:21:27,720 --> 00:21:30,320
Actually, just I won't go any further into the story.

359
00:21:30,320 --> 00:21:33,480
But if you're interested in the story behind Playdate,

360
00:21:33,480 --> 00:21:37,760
the Panic podcast, which is a not a regular podcast,

361
00:21:37,760 --> 00:21:41,240
but they did a series of, I think, six or seven podcasts.

362
00:21:41,240 --> 00:21:43,600
And a couple of them, at least, were on the history

363
00:21:43,600 --> 00:21:45,160
and the development of Playdate.

364
00:21:45,160 --> 00:21:47,920
And they are a fantastic lesson.

365
00:21:47,920 --> 00:21:49,760
I really thoroughly enjoyed them.

366
00:21:49,760 --> 00:21:54,400
So that's what the Playdate is.

367
00:21:54,400 --> 00:21:58,160
And they have an SDK so that anybody can write

368
00:21:58,160 --> 00:22:01,560
software or games for the platform.

369
00:22:01,560 --> 00:22:03,800
They also have a little app store.

370
00:22:03,800 --> 00:22:06,320
So if you do write a game, you can publish it to the app store.

371
00:22:06,320 --> 00:22:12,960
And I think the primary language for games is either C

372
00:22:13,280 --> 00:22:15,720
and they have a C SDK or Lua,

373
00:22:15,720 --> 00:22:20,240
which is a commonly used in gaming scripting language.

374
00:22:20,240 --> 00:22:25,200
But now they can add one more language to that SDK.

375
00:22:25,200 --> 00:22:27,400
Yeah, and that is Swift.

376
00:22:27,400 --> 00:22:30,240
And that's that's going via the C API.

377
00:22:30,240 --> 00:22:35,120
And I think what's worth calling out here is this is using the fairly

378
00:22:35,120 --> 00:22:37,560
new embedded language mode of Swift,

379
00:22:37,560 --> 00:22:42,400
which is sort of made for these devices with more

380
00:22:43,200 --> 00:22:45,880
constrained environments.

381
00:22:45,880 --> 00:22:49,440
And what it does, it spits out smaller binaries by stripping

382
00:22:49,440 --> 00:22:51,960
and all sorts of techniques like that.

383
00:22:51,960 --> 00:22:56,320
I think it has no or very tiny runtime and it's a language subset.

384
00:22:56,320 --> 00:22:59,840
So it doesn't have all the features of full blown Swift.

385
00:22:59,840 --> 00:23:02,120
In particular, there's no objective C interop.

386
00:23:02,120 --> 00:23:05,120
There's no reflection.

387
00:23:05,120 --> 00:23:08,960
And there are some limitations around Unicode.

388
00:23:08,960 --> 00:23:12,600
So I think the main thing is that it doesn't have the Unicode

389
00:23:12,600 --> 00:23:16,440
data tables, which means like Unicode point stuff,

390
00:23:16,440 --> 00:23:20,360
you know, like character width and traversing strings isn't isn't available.

391
00:23:20,360 --> 00:23:21,680
By default, you need to opt in.

392
00:23:21,680 --> 00:23:26,360
And then that pulls in that those data sets making the binary larger.

393
00:23:26,360 --> 00:23:31,600
And I think there are more constraints, but those are just the three

394
00:23:31,600 --> 00:23:36,800
that I found in in quickly looking through the description of that language

395
00:23:36,800 --> 00:23:37,720
language mode.

396
00:23:37,720 --> 00:23:42,560
And you would need to use a nightly tool chain to actually make use of that.

397
00:23:42,560 --> 00:23:45,040
And build and target the playdate with Swift.

398
00:23:45,040 --> 00:23:49,400
But it's really great to see that this is being being used

399
00:23:49,400 --> 00:23:52,560
and opens up Swift to yet another place.

400
00:23:52,560 --> 00:23:54,320
Yeah, fantastic to see.

401
00:23:54,320 --> 00:23:58,080
And I think as as Swift 6 arrives,

402
00:23:58,080 --> 00:24:03,000
I hope we'll see some Swift games on the Playdate store.

403
00:24:03,000 --> 00:24:08,400
Yeah, I think that's probably about it for Muse and kind of catching up.

404
00:24:08,400 --> 00:24:11,520
So why don't we do some package recommendations?

405
00:24:11,520 --> 00:24:13,160
Let's do some packages.

406
00:24:13,160 --> 00:24:14,440
Do you want to kick us off?

407
00:24:14,440 --> 00:24:16,560
Sure thing.

408
00:24:16,560 --> 00:24:22,160
The first package I want to talk about this week is called Threadcrum

409
00:24:22,160 --> 00:24:25,120
by Alexander Cohen, and

410
00:24:25,120 --> 00:24:28,720
the description of it is a Swift, sorry, Swift,

411
00:24:28,720 --> 00:24:31,920
no nonsense, dependency free breadcrumb logger.

412
00:24:31,920 --> 00:24:36,520
And I really like the idea of this.

413
00:24:36,760 --> 00:24:41,840
It's probably something that you can already do

414
00:24:41,840 --> 00:24:46,520
if you have all of your symbolication set up in your project

415
00:24:46,520 --> 00:24:50,480
so that you can get fully symbolicated crash reports whenever you want them.

416
00:24:50,480 --> 00:24:56,760
But I really like the technique that Alexander is using here, which is to

417
00:24:56,760 --> 00:25:01,280
you get the API to the developer, to you,

418
00:25:01,280 --> 00:25:06,200
as threadcrum.log, and you can put a string in

419
00:25:07,000 --> 00:25:09,640
a log message and there's your logging.

420
00:25:09,640 --> 00:25:14,280
But the way that these log messages appear is, I think, quite clever.

421
00:25:14,280 --> 00:25:19,360
What it actually does is it inserts stack frames into the backtrace

422
00:25:19,360 --> 00:25:24,440
with the log messages in the method names of the stack frames.

423
00:25:24,440 --> 00:25:29,600
So you can get these log messages out regardless of symbolication.

424
00:25:29,600 --> 00:25:30,880
OK.

425
00:25:30,880 --> 00:25:34,960
And I thought that was a really clever little idea.

426
00:25:35,960 --> 00:25:36,960
Interesting.

427
00:25:36,960 --> 00:25:41,960
OK, so even if something's messed up, you could still see enough in the stack trace

428
00:25:41,960 --> 00:25:45,280
to sort of piece together where things were at.

429
00:25:45,280 --> 00:25:46,280
Yeah.

430
00:25:46,280 --> 00:25:54,560
And there's a good screenshot on the readme file that you can,

431
00:25:54,560 --> 00:25:58,160
if you check it out on the Swift Package Index, that you can see how it kind of

432
00:25:58,160 --> 00:26:01,520
manifests itself in a real world environment.

433
00:26:03,080 --> 00:26:06,400
Actually, there's an interesting story behind that screenshot.

434
00:26:06,400 --> 00:26:08,080
I was going to ask.

435
00:26:08,080 --> 00:26:15,200
So this screenshot up until, I think, yesterday,

436
00:26:15,200 --> 00:26:19,240
well, actually overnight, last night, it fixed itself.

437
00:26:19,240 --> 00:26:23,080
But up until yesterday, this screenshot, if you'd have checked the screenshot

438
00:26:23,080 --> 00:26:26,560
on the Swift Package Index, it would have been a broken image

439
00:26:26,560 --> 00:26:32,960
because we had a situation with some readme file screenshots

440
00:26:33,800 --> 00:26:36,200
that were not making it through to the package index.

441
00:26:36,200 --> 00:26:42,520
And it's a fix that we deployed to the system yesterday, which was...

442
00:26:42,520 --> 00:26:49,200
So there's several ways to include an image in a GitHub readme file.

443
00:26:49,200 --> 00:26:53,960
Some of them you can just refer to a file, like if you include the file

444
00:26:53,960 --> 00:26:58,120
in your repository, sometimes people put a .readmeimages directory

445
00:26:58,120 --> 00:27:00,720
in the root of their repository or something like that,

446
00:27:01,920 --> 00:27:06,480
and then just reference that file on raw.github.com, whatever it is.

447
00:27:06,480 --> 00:27:08,280
That will work just fine.

448
00:27:08,280 --> 00:27:12,080
And whenever we pull the readme in from GitHub's API,

449
00:27:12,080 --> 00:27:15,840
those images just load off GitHub servers.

450
00:27:15,840 --> 00:27:20,320
But some of the images, depending on how you upload them to GitHub,

451
00:27:20,320 --> 00:27:24,960
when we request the readme file via their API,

452
00:27:24,960 --> 00:27:28,400
they come back with a JWT attached.

453
00:27:28,400 --> 00:27:32,200
And that JWT has an expiration date of five minutes.

454
00:27:32,200 --> 00:27:36,080
So as we ingest the readme file into our system

455
00:27:36,080 --> 00:27:41,800
and we hold a cache of that ingested readme file, so we upload that to S3.

456
00:27:41,800 --> 00:27:50,440
That cached readme file has an image in it with a JWT on it, which has expired.

457
00:27:50,440 --> 00:27:54,800
And so those images are never going to display for us

458
00:27:54,800 --> 00:27:58,480
because it's unlikely that you would ever look at a readme file

459
00:27:58,480 --> 00:28:00,400
within five minutes of us caching it.

460
00:28:00,400 --> 00:28:07,640
So that has been a little project that I've been working on last week or so,

461
00:28:07,640 --> 00:28:10,920
which is to, as we ingest the readme files now,

462
00:28:10,920 --> 00:28:16,160
we also look through for any of these images that have JWTs attached

463
00:28:16,160 --> 00:28:18,000
and we cache those to S3 as well.

464
00:28:18,000 --> 00:28:22,640
So the good news is you should now no longer see any

465
00:28:23,720 --> 00:28:27,040
broken images on any of the readme files in the package index.

466
00:28:27,040 --> 00:28:32,400
And it wasn't, this wasn't affecting a huge number of packages.

467
00:28:32,400 --> 00:28:38,040
It was 611 images across 148 repositories.

468
00:28:38,040 --> 00:28:41,560
So as a percentage of our total, it was fairly minor.

469
00:28:41,560 --> 00:28:45,360
But where people have included an image in their readme file,

470
00:28:45,360 --> 00:28:48,160
it's usually quite an important part of what the package does.

471
00:28:48,160 --> 00:28:50,480
And so I'm really glad that we were able to get it fixed.

472
00:28:50,720 --> 00:28:53,720
Yeah, that's really great to have in.

473
00:28:53,720 --> 00:28:58,400
So, yeah, that's Threadcrumb by Alexander Cohen.

474
00:28:58,400 --> 00:29:03,680
And yeah, go check out the shiny new image on the readme file.

475
00:29:03,680 --> 00:29:06,040
Nice.

476
00:29:06,040 --> 00:29:12,280
Right, my first pick is called Flying Fox by Simon Whitty.

477
00:29:12,280 --> 00:29:18,480
Flying Fox is a lightweight HTTP server with async weight APIs.

478
00:29:19,440 --> 00:29:24,200
And I came across that recently because I needed to write a small proxy.

479
00:29:24,200 --> 00:29:29,600
And I normally would have reached for Python, I think,

480
00:29:29,600 --> 00:29:32,000
because, you know, it has stuff like that built in.

481
00:29:32,000 --> 00:29:38,320
But I have been moving more and more of my scripting jobs over to Swift lately.

482
00:29:38,320 --> 00:29:39,760
And I really like it.

483
00:29:39,760 --> 00:29:42,760
So I looked around when I needed to write this little proxy.

484
00:29:42,760 --> 00:29:47,040
And I recall that I had looked for HTTP servers a while back

485
00:29:47,040 --> 00:29:54,920
and I came across Flying Fox again and tried it and it did it perfectly.

486
00:29:54,920 --> 00:30:01,040
It's really concise, a really nice API, really easy to integrate and write that proxy.

487
00:30:01,040 --> 00:30:06,160
Why I really like Swift over Python in situations like this

488
00:30:06,160 --> 00:30:10,480
is obviously the type safety, which helps you write it.

489
00:30:10,480 --> 00:30:17,080
But I found that it's much easier to pick up projects with large time gaps in between

490
00:30:17,080 --> 00:30:22,200
because the type safety helps you understand what you were doing at the time.

491
00:30:22,200 --> 00:30:25,440
You know, like these little scripts, I don't write lots of comments and stuff.

492
00:30:25,440 --> 00:30:30,840
They're off the cuff written things that you write in the moment when you know what's going on.

493
00:30:30,840 --> 00:30:34,680
And when you revisit those sort of things is when you lack all the context.

494
00:30:34,680 --> 00:30:39,560
And I feel Swift really adds a lot of context out of the box

495
00:30:39,560 --> 00:30:43,040
because you are sort of putting it in the types.

496
00:30:43,040 --> 00:30:45,800
That makes it really nice to work in these projects.

497
00:30:45,800 --> 00:30:47,080
That's why I really like it.

498
00:30:47,080 --> 00:30:47,880
Right.

499
00:30:47,880 --> 00:30:51,360
So the thing explains itself via the documented types

500
00:30:51,360 --> 00:30:55,240
rather than having to guess at what it is from the outside.

501
00:30:55,240 --> 00:30:59,680
And in Python, you always have this thing, you know, I guess it's a dictionary.

502
00:30:59,680 --> 00:31:01,120
Yeah, but you know, how deep is it?

503
00:31:01,120 --> 00:31:01,960
What's in it?

504
00:31:01,960 --> 00:31:04,640
You know, that's always kind of weird.

505
00:31:04,640 --> 00:31:07,040
So yeah, that's a really nice aspect.

506
00:31:07,040 --> 00:31:12,280
I'm sort of digressing a bit from this nice package.

507
00:31:12,280 --> 00:31:13,680
I mean, I wouldn't really say much about that.

508
00:31:13,680 --> 00:31:18,000
I digress into a bug fix.

509
00:31:18,000 --> 00:31:23,280
Yeah, and while I'm doing this, I might as well mention the one downside I found

510
00:31:23,280 --> 00:31:27,360
when writing scripts and wanting to use dependencies like here,

511
00:31:27,360 --> 00:31:32,680
you know, I want to use Flying Fox in a script, obviously to try it out.

512
00:31:32,680 --> 00:31:37,840
I can't not mention our feature on the package index,

513
00:31:37,840 --> 00:31:40,440
try in a package where you can click a button

514
00:31:40,440 --> 00:31:44,160
and get a ready-made playground to actually use the package,

515
00:31:44,160 --> 00:31:45,280
which is nice to try it out.

516
00:31:45,280 --> 00:31:47,080
But if you actually want to run the script,

517
00:31:47,080 --> 00:31:50,640
that's not really the way you would want to be doing it.

518
00:31:50,640 --> 00:31:54,840
So then you hit the problem of how would you use a dependency in a script?

519
00:31:54,840 --> 00:31:59,920
And you're kind of either forced to create a package, which is not too hard,

520
00:31:59,920 --> 00:32:01,280
but it's also kind of tedious.

521
00:32:01,280 --> 00:32:10,200
And the other thing you can do is use the package SwiftSH by Max Howell.

522
00:32:10,200 --> 00:32:12,920
SwiftSH is a package where you can write scripts

523
00:32:12,920 --> 00:32:16,640
and pull in dependencies via comments on your import line.

524
00:32:16,640 --> 00:32:20,480
And then under the hood, it does all the package creation,

525
00:32:20,480 --> 00:32:23,680
executable target definition for you.

526
00:32:23,680 --> 00:32:28,120
So you can use a dependency in a script as if it was a package.

527
00:32:28,120 --> 00:32:30,160
And that's really nice.

528
00:32:30,160 --> 00:32:33,400
So long story short, if you need to write--

529
00:32:33,400 --> 00:32:36,360
if you need to do anything with an HTTP server,

530
00:32:36,360 --> 00:32:42,240
imagine you're writing an app and you want to stand up a very simple API

531
00:32:42,240 --> 00:32:43,240
to play around with it.

532
00:32:43,240 --> 00:32:46,480
That would be a really nice use case for something like Flying Fox,

533
00:32:46,480 --> 00:32:49,880
where you can spin up a server and easily instrument it

534
00:32:49,880 --> 00:32:52,640
on a fake back end, that sort of thing.

535
00:32:52,640 --> 00:32:59,360
And these are the tools you could use to help you with that sort of problem.

536
00:32:59,360 --> 00:33:02,640
Yeah, again, Flying Fox by Simon Witte.

537
00:33:02,640 --> 00:33:04,200
It couldn't be any simpler either.

538
00:33:04,200 --> 00:33:05,920
I'm looking at the readme file right now.

539
00:33:05,920 --> 00:33:10,040
And to start up the server is literally two lines of code.

540
00:33:10,040 --> 00:33:14,760
Instantiate a HTTP server and call the start method on it.

541
00:33:14,760 --> 00:33:16,040
Yeah, yeah, exactly.

542
00:33:16,040 --> 00:33:17,120
That's what I really liked.

543
00:33:17,120 --> 00:33:21,800
And it was one of the few ones that I looked at that had, like,

544
00:33:21,800 --> 00:33:28,200
modern async/await interface, which made it just appealing.

545
00:33:28,200 --> 00:33:34,600
My next package is a package for testing.

546
00:33:34,600 --> 00:33:40,240
And it's called Expect to Eventually Equal,

547
00:33:40,240 --> 00:33:46,320
which is what caught my eye in kind of browsing through the packages that

548
00:33:46,320 --> 00:33:48,040
were new to the index.

549
00:33:48,040 --> 00:33:49,520
It is a fairly new package.

550
00:33:49,520 --> 00:33:51,920
Only been in development for a couple of months.

551
00:33:51,920 --> 00:33:58,080
And it's by Jon Reid, who is a kind of cornerstone of testing knowledge

552
00:33:58,080 --> 00:33:59,400
in the Swift community.

553
00:33:59,400 --> 00:34:04,840
He's been writing about testing in Swift for many, many years now.

554
00:34:04,840 --> 00:34:08,160
And so this--

555
00:34:08,160 --> 00:34:10,800
I mean, it's going to be no surprise what this does,

556
00:34:10,800 --> 00:34:20,120
is it adds an additional assertion where you can specify a block to execute

557
00:34:20,120 --> 00:34:26,800
and an expected value for that block at some point in the future.

558
00:34:26,800 --> 00:34:32,440
And what it does is it calls that block many times with a timeout of one second.

559
00:34:32,440 --> 00:34:35,480
I presume the timeout is probably customizable,

560
00:34:35,480 --> 00:34:39,640
although I don't actually see a method to customize it in the readme.

561
00:34:39,640 --> 00:34:41,960
So maybe it's not.

562
00:34:41,960 --> 00:34:49,520
And it will continually repeat the call to that block

563
00:34:49,520 --> 00:34:55,120
until the value is as expected or the timeout of one second is here.

564
00:34:55,120 --> 00:35:00,040
And it's quite clear when it does fail--

565
00:35:00,040 --> 00:35:02,760
I'll read you out one of the kind of failure messages here.

566
00:35:02,760 --> 00:35:09,960
It says, expected to, but was one after 93 tries, timing out after one second.

567
00:35:09,960 --> 00:35:15,800
So it gives you a really nice reason that the assertion failed, if it failed.

568
00:35:15,800 --> 00:35:18,360
Or if it passed within that second, then you just

569
00:35:18,360 --> 00:35:20,120
get a test pass, which is great.

570
00:35:20,120 --> 00:35:21,240
Nice.

571
00:35:21,240 --> 00:35:23,760
Yeah, I mean, there's the whole expectation thing, right,

572
00:35:23,760 --> 00:35:25,080
that comes with XCTests.

573
00:35:25,080 --> 00:35:28,240
But it can be sometimes a bit awkward to set up.

574
00:35:28,240 --> 00:35:32,440
You have to put the fulfill thing somewhere.

575
00:35:32,440 --> 00:35:36,800
And a block-based interface is just nicer for some APIs.

576
00:35:36,800 --> 00:35:39,320
Yeah, and that's why I liked it.

577
00:35:39,320 --> 00:35:41,720
Because you look at this code sample here, and it is just--

578
00:35:41,720 --> 00:35:49,120
it is so simple to do tests that may not be the correct value immediately.

579
00:35:49,120 --> 00:35:50,000
Yeah.

580
00:35:50,000 --> 00:35:52,480
Yeah, ergonomics in tests I find really important,

581
00:35:52,480 --> 00:35:59,880
because anything that distracts you from writing tests is sort of--

582
00:35:59,880 --> 00:36:01,680
yeah, it's bad.

583
00:36:01,680 --> 00:36:07,280
Because you really want to be encouraged to write as many variants

584
00:36:07,280 --> 00:36:09,600
and different tests and that sort of thing.

585
00:36:09,600 --> 00:36:13,840
So it should be as easy as possible, really.

586
00:36:13,840 --> 00:36:18,760
And the other thing that I liked about this is that quite often when you look

587
00:36:18,760 --> 00:36:19,600
at--

588
00:36:19,600 --> 00:36:21,280
well, it's not when you look at packages, actually.

589
00:36:21,280 --> 00:36:22,800
It's when you think about making a package.

590
00:36:22,800 --> 00:36:25,440
You maybe think, well, if I'm going to write a package that's

591
00:36:25,440 --> 00:36:29,840
around test assertions, then maybe I need to rewrite all the test assertions

592
00:36:29,840 --> 00:36:32,360
so that people can use all my test assertions.

593
00:36:32,360 --> 00:36:34,400
I really like that this is just one thing.

594
00:36:34,400 --> 00:36:40,440
It's just like, this is a better way to do this kind of testing.

595
00:36:40,440 --> 00:36:41,640
It's just one assertion.

596
00:36:41,640 --> 00:36:44,240
This package is probably kind of done.

597
00:36:44,240 --> 00:36:44,760
Yeah.

598
00:36:44,760 --> 00:36:45,840
Yeah.

599
00:36:45,840 --> 00:36:49,480
It may never get another update.

600
00:36:49,480 --> 00:36:52,360
And nor would it necessarily need one unless that's something

601
00:36:52,360 --> 00:36:55,800
changed in the underlying code.

602
00:36:55,800 --> 00:37:00,480
So yeah, I really like that these kind of focused, small packages,

603
00:37:00,480 --> 00:37:01,680
I think they're great.

604
00:37:01,680 --> 00:37:05,000
Yeah, you said something there that just reminded me.

605
00:37:05,000 --> 00:37:08,320
Either quick or nimble, I always confuse which one does which.

606
00:37:08,320 --> 00:37:12,960
One of them has alternative assert syntax.

607
00:37:12,960 --> 00:37:13,600
Nimble, yeah.

608
00:37:13,600 --> 00:37:14,640
Nimble is the matcher, yeah.

609
00:37:14,640 --> 00:37:15,840
Which makes it really nice.

610
00:37:15,840 --> 00:37:17,040
I really like the package.

611
00:37:17,040 --> 00:37:19,280
I even used it a bit at the start.

612
00:37:19,280 --> 00:37:22,640
But the problem is, not for every project

613
00:37:22,640 --> 00:37:27,040
are you going to pull in a test dependency like that.

614
00:37:27,040 --> 00:37:30,000
And then when you do, you're sort of

615
00:37:30,000 --> 00:37:31,280
faced with that conundrum.

616
00:37:31,280 --> 00:37:34,600
Well, do I now switch everything over or just the new tests?

617
00:37:34,600 --> 00:37:37,000
And then I have a mix, and it's all weird.

618
00:37:37,000 --> 00:37:41,640
And yeah, I mean, we also have different--

619
00:37:41,640 --> 00:37:43,720
we use different patterns in our tests.

620
00:37:43,720 --> 00:37:45,320
And that sort of annoys me sometimes

621
00:37:45,320 --> 00:37:47,280
that they aren't all the same.

622
00:37:47,280 --> 00:37:50,040
But there's only so much you can do.

623
00:37:50,040 --> 00:37:53,040
But if it's something as fundamental how you assert,

624
00:37:53,040 --> 00:37:54,680
it's really tough.

625
00:37:54,680 --> 00:37:57,720
It's a tough sell then to do one or the other.

626
00:37:57,720 --> 00:37:58,320
Yeah.

627
00:37:58,320 --> 00:38:00,520
Yeah, one of the slight odd ones out

628
00:38:00,520 --> 00:38:02,840
is our use of snapshot testing.

629
00:38:02,840 --> 00:38:05,080
That's a whole different mechanism

630
00:38:05,080 --> 00:38:10,040
to writing a test than the regular assertions.

631
00:38:10,040 --> 00:38:11,440
And I wouldn't change that.

632
00:38:11,440 --> 00:38:12,900
I wouldn't want to get rid of that.

633
00:38:12,900 --> 00:38:16,760
But it is one of those things where you have to kind of, oh,

634
00:38:16,760 --> 00:38:18,160
we're doing this kind of testing.

635
00:38:18,160 --> 00:38:19,440
OK, we're using this API.

636
00:38:19,440 --> 00:38:20,400
There we go.

637
00:38:20,400 --> 00:38:24,000
Yeah, although in its defense, at least it

638
00:38:24,000 --> 00:38:25,760
does sort of function.

639
00:38:25,760 --> 00:38:28,280
And then it has two expectation values, right?

640
00:38:28,280 --> 00:38:32,680
The nimble one is different in that it's almost

641
00:38:32,680 --> 00:38:36,120
like a statement that you write.

642
00:38:36,120 --> 00:38:38,680
I don't recall off the top of my head.

643
00:38:38,680 --> 00:38:40,520
It's not like a function call.

644
00:38:40,520 --> 00:38:42,680
It's different.

645
00:38:42,680 --> 00:38:46,480
It's expect something to equal something.

646
00:38:46,480 --> 00:38:49,280
Exactly, it's like a chained expression.

647
00:38:49,280 --> 00:38:50,080
Yeah, yeah, yeah.

648
00:38:50,080 --> 00:38:51,800
It makes it stand out a little bit more.

649
00:38:51,800 --> 00:38:55,640
It's taken from a library which is literally

650
00:38:55,640 --> 00:38:58,680
the standard in Ruby development, which is RSpec.

651
00:38:58,680 --> 00:39:02,120
So there is an underlying testing library with Ruby,

652
00:39:02,120 --> 00:39:04,480
but almost everybody uses RSpec.

653
00:39:04,480 --> 00:39:09,000
And it's a behavioral BDD testing framework

654
00:39:09,000 --> 00:39:12,200
where you describe what the thing should do,

655
00:39:12,200 --> 00:39:14,120
and then you write some expectations in there

656
00:39:14,120 --> 00:39:18,160
to assert that it is behaving correctly.

657
00:39:18,160 --> 00:39:21,320
And that is what Quick and Nimble are effectively

658
00:39:21,320 --> 00:39:24,480
porting across to Swift.

659
00:39:24,480 --> 00:39:29,000
I'm really hopeful that with the new Swift testing package that

660
00:39:29,000 --> 00:39:34,000
is coming soon or later at some point,

661
00:39:34,000 --> 00:39:37,920
that Xcode starts to get better support

662
00:39:37,920 --> 00:39:40,560
for different types of testing.

663
00:39:40,560 --> 00:39:42,520
One of the reasons that Quick and Nimble

664
00:39:42,520 --> 00:39:49,120
is challenging to adopt is that effectively your entire test

665
00:39:49,120 --> 00:39:53,840
suite collapses down into one Xcode test.

666
00:39:53,840 --> 00:39:57,200
And so you only get one green tick in Xcode

667
00:39:57,200 --> 00:40:00,520
because your entire test suite is one test.

668
00:40:00,520 --> 00:40:01,920
And then within that test, you've

669
00:40:01,920 --> 00:40:04,760
got potentially thousands of expectations

670
00:40:04,760 --> 00:40:08,480
or even sections and everything.

671
00:40:08,480 --> 00:40:11,040
And I'm really hopeful that what they're

672
00:40:11,040 --> 00:40:15,640
doing with Swift testing leads into slightly more

673
00:40:15,640 --> 00:40:20,360
flexible reporting of those test results within Xcode.

674
00:40:20,360 --> 00:40:20,920
Right.

675
00:40:20,920 --> 00:40:23,480
I've actually used-- which one was it?

676
00:40:23,480 --> 00:40:24,160
Quick, right?

677
00:40:24,160 --> 00:40:25,520
That's the behavioral part.

678
00:40:25,520 --> 00:40:26,120
Correct, yeah.

679
00:40:26,120 --> 00:40:27,840
I've only used Nimble, the expectations.

680
00:40:27,840 --> 00:40:29,800
Yeah.

681
00:40:29,800 --> 00:40:32,520
Because I really like writing tests.

682
00:40:32,520 --> 00:40:35,520
It's a very nice way to structure your test suite.

683
00:40:35,520 --> 00:40:37,880
You can have nice sections.

684
00:40:37,880 --> 00:40:41,080
And one thing that we're also not perfect at,

685
00:40:41,080 --> 00:40:43,400
because nobody's perfect at this, I'm pretty sure,

686
00:40:43,400 --> 00:40:48,720
is our consistent naming of our test methods.

687
00:40:48,720 --> 00:40:54,360
We kind of use underscores to indicate that there's obviously

688
00:40:54,360 --> 00:40:57,200
the word test and then maybe the type name

689
00:40:57,200 --> 00:40:59,120
and then maybe an underscore in the method name

690
00:40:59,120 --> 00:41:01,000
if we're testing a specific method.

691
00:41:01,000 --> 00:41:03,200
But it's very inconsistent how we name those.

692
00:41:03,200 --> 00:41:07,480
And one thing that BDD does is it gives you a really nice way

693
00:41:07,480 --> 00:41:11,120
to just use English to describe what you're testing.

694
00:41:11,120 --> 00:41:14,240
And that becomes effectively your test name.

695
00:41:14,240 --> 00:41:16,040
Right.

696
00:41:16,040 --> 00:41:16,760
Right.

697
00:41:16,760 --> 00:41:18,040
So where were we at?

698
00:41:18,040 --> 00:41:20,000
We've gone down lots of rabbit holes.

699
00:41:20,000 --> 00:41:20,840
Whose turn is it?

700
00:41:20,840 --> 00:41:23,680
Is it my turn?

701
00:41:23,680 --> 00:41:24,720
I think that was mine.

702
00:41:24,720 --> 00:41:25,640
So I think it's your turn.

703
00:41:25,640 --> 00:41:26,120
Right.

704
00:41:26,120 --> 00:41:29,960
My second package, and I think probably also my final package,

705
00:41:29,960 --> 00:41:33,760
right, given where we're at in the recording.

706
00:41:33,760 --> 00:41:37,160
My second package is called Swift Package Info

707
00:41:37,160 --> 00:41:38,560
by Felipe Marino.

708
00:41:38,560 --> 00:41:42,320
That's an interesting tool.

709
00:41:42,320 --> 00:41:45,440
It's a tool that provides info about a package, most notable

710
00:41:45,440 --> 00:41:49,200
about its binary size.

711
00:41:49,200 --> 00:41:52,080
I sort of think we've talked about this in the past,

712
00:41:52,080 --> 00:41:57,000
but I don't think we've had it as a package pick yet.

713
00:41:57,000 --> 00:42:01,280
If we did, then we'd just do this whole thing again.

714
00:42:01,280 --> 00:42:02,840
I saw this again, and I thought this

715
00:42:02,840 --> 00:42:04,320
would be an interesting metric for us

716
00:42:04,320 --> 00:42:07,040
to expose at some point.

717
00:42:07,040 --> 00:42:09,360
So this we have definitely discussed in the past,

718
00:42:09,360 --> 00:42:12,280
whether we would have means and ways

719
00:42:12,280 --> 00:42:17,000
to expose binary size on the package page.

720
00:42:17,000 --> 00:42:19,480
The interesting part there is the question

721
00:42:19,480 --> 00:42:23,960
is, how much will my binary grow if I

722
00:42:23,960 --> 00:42:26,480
use this package or a product?

723
00:42:26,480 --> 00:42:28,080
It's a bit of a problem if a package

724
00:42:28,080 --> 00:42:29,840
has more than one product.

725
00:42:29,840 --> 00:42:31,160
That's not a one-to-one question,

726
00:42:31,160 --> 00:42:34,920
but let's leave those details aside for the moment.

727
00:42:34,920 --> 00:42:39,840
Just roughly, what would that mean for my app

728
00:42:39,840 --> 00:42:43,720
to use this package?

729
00:42:43,720 --> 00:42:48,000
And the concern has been, well, in order

730
00:42:48,000 --> 00:42:49,800
to actually assess that properly,

731
00:42:49,800 --> 00:42:52,240
we would have to build that package with a release build.

732
00:42:52,240 --> 00:42:54,880
And we're not doing release builds right now

733
00:42:54,880 --> 00:42:57,760
because they're much slower than debug builds,

734
00:42:57,760 --> 00:43:02,560
and they're not really key to determine compatibility.

735
00:43:02,560 --> 00:43:04,840
It's a fair assumption-- not a perfect assumption,

736
00:43:04,840 --> 00:43:07,800
but a fair assumption if a debug build succeeds.

737
00:43:07,800 --> 00:43:12,760
So with the release build, again, not certain,

738
00:43:12,760 --> 00:43:17,080
but it's a good starting assumption.

739
00:43:17,080 --> 00:43:18,360
So we're not doing release builds

740
00:43:18,360 --> 00:43:21,320
because we're already on a constrained time

741
00:43:21,320 --> 00:43:24,240
budget for our builds, and that would just squeeze that

742
00:43:24,240 --> 00:43:25,720
further.

743
00:43:25,720 --> 00:43:30,760
But I had a thought how we could potentially work with that

744
00:43:30,760 --> 00:43:33,640
and get to use it at least initially,

745
00:43:33,640 --> 00:43:37,280
and that's if we made this an opt-in for packages.

746
00:43:37,280 --> 00:43:39,480
Because as I just said, it's--

747
00:43:39,480 --> 00:43:43,320
so this tool looks at products in a package,

748
00:43:43,320 --> 00:43:45,240
and you have to specify the product if you want

749
00:43:45,240 --> 00:43:47,160
to get binary info out of it.

750
00:43:47,160 --> 00:43:51,840
So we would sort of need to have a way for the authors

751
00:43:51,840 --> 00:43:55,360
to tell us which product is the one that we should measure.

752
00:43:55,360 --> 00:43:58,040
And that would go via our SPI.yaml file, right?

753
00:43:58,040 --> 00:44:00,960
That's currently-- well, that's not just currently.

754
00:44:00,960 --> 00:44:04,240
It's probably always going to be the only way for authors

755
00:44:04,240 --> 00:44:06,800
to express that interest.

756
00:44:06,800 --> 00:44:11,040
And that could be a way for us to signal to us, right,

757
00:44:11,040 --> 00:44:13,520
I actually want to expose this metric.

758
00:44:13,520 --> 00:44:16,760
Run a release build instead of the debug build,

759
00:44:16,760 --> 00:44:17,800
maybe in addition.

760
00:44:17,800 --> 00:44:21,720
I mean, we would have to deal with the implications,

761
00:44:21,720 --> 00:44:24,280
I guess.

762
00:44:24,280 --> 00:44:27,040
And authors would then also know, right, we're on a budget.

763
00:44:27,040 --> 00:44:31,000
And if you already have a package that's quite large,

764
00:44:31,000 --> 00:44:34,040
you kind of would know you can't opt-in.

765
00:44:34,040 --> 00:44:38,080
So that might be a way of dealing with that.

766
00:44:38,080 --> 00:44:40,080
And that's why I found this package interesting.

767
00:44:40,080 --> 00:44:45,280
It sort of sparked the idea to maybe look at this again.

768
00:44:45,280 --> 00:44:49,720
It is a very commonly requested feature of Package Index.

769
00:44:49,720 --> 00:44:53,400
This has come up several times over the years.

770
00:44:53,400 --> 00:44:57,320
And it always comes down to that release build thing.

771
00:44:57,320 --> 00:45:02,280
And we always kind of say, OK, well, we'll put it to one side.

772
00:45:02,280 --> 00:45:05,680
But I remember as soon as we launched the build system back

773
00:45:05,680 --> 00:45:06,720
in 20--

774
00:45:06,720 --> 00:45:11,480
end of 2020, we were instantly asked about this feature.

775
00:45:11,480 --> 00:45:12,640
Yeah.

776
00:45:12,640 --> 00:45:13,400
Yeah.

777
00:45:13,400 --> 00:45:16,600
You think it's feasible if we do it this way to sort of opt it

778
00:45:16,600 --> 00:45:17,120
in?

779
00:45:17,120 --> 00:45:20,400
Would that still be worthwhile, even though the opt-in probably

780
00:45:20,400 --> 00:45:22,480
isn't going to be huge?

781
00:45:22,480 --> 00:45:23,560
But, you know.

782
00:45:23,560 --> 00:45:24,160
Yeah.

783
00:45:24,160 --> 00:45:28,680
And I think the more--

784
00:45:28,680 --> 00:45:31,520
I think you're right that this mechanism of having

785
00:45:31,520 --> 00:45:35,360
a file in the repository that we read is a good mechanism.

786
00:45:35,360 --> 00:45:38,920
I don't want to change anything about that mechanism.

787
00:45:38,920 --> 00:45:43,440
Of course, it is always a struggle

788
00:45:43,440 --> 00:45:48,480
to get people to read anything.

789
00:45:48,480 --> 00:45:52,160
And so communicating that this is a thing

790
00:45:52,160 --> 00:45:55,400
that we can do is always going to be a difficult-- yes,

791
00:45:55,400 --> 00:45:59,120
we can do a blog post, but nobody reads blog posts.

792
00:45:59,120 --> 00:46:00,720
Yes, we can talk about it on a podcast.

793
00:46:00,720 --> 00:46:02,000
And people do listen to podcasts,

794
00:46:02,000 --> 00:46:03,000
but they're not on their computer

795
00:46:03,000 --> 00:46:04,200
when they listen to podcasts.

796
00:46:04,200 --> 00:46:05,400
And so they rarely do it.

797
00:46:05,400 --> 00:46:06,240
They rarely act.

798
00:46:06,240 --> 00:46:07,720
Like, it's hard to get people to act.

799
00:46:07,720 --> 00:46:10,040
It's hard to get people to do things.

800
00:46:10,040 --> 00:46:11,000
Because people are busy.

801
00:46:11,000 --> 00:46:15,360
And it's not a criticism of people.

802
00:46:15,360 --> 00:46:16,080
People are busy.

803
00:46:16,080 --> 00:46:18,280
There's a million things that need your attention

804
00:46:18,280 --> 00:46:20,760
whenever you're working.

805
00:46:20,760 --> 00:46:27,360
And so getting that adoption up will be challenging for it.

806
00:46:27,360 --> 00:46:30,640
But as the Swift package index grows,

807
00:46:30,640 --> 00:46:38,000
and as it becomes kind of expected for a package

808
00:46:38,000 --> 00:46:39,400
to be on the Swift package index--

809
00:46:39,400 --> 00:46:42,560
and this is our hope, of course, that it becomes the place

810
00:46:42,560 --> 00:46:45,200
to look for packages.

811
00:46:45,200 --> 00:46:52,800
I think that as we see some packages adopt features

812
00:46:52,800 --> 00:46:53,800
like this--

813
00:46:53,800 --> 00:46:57,800
it's like we see with documentation, right?

814
00:46:57,800 --> 00:47:02,720
That is a process that we're going through

815
00:47:02,720 --> 00:47:04,960
to get people to consider hosting

816
00:47:04,960 --> 00:47:07,280
their documentation with us.

817
00:47:07,280 --> 00:47:10,240
And we actually have one very effective way

818
00:47:10,240 --> 00:47:11,640
of letting people know about that,

819
00:47:11,640 --> 00:47:14,720
which is whenever you add a package,

820
00:47:14,720 --> 00:47:18,920
we have an opportunity to tell people who--

821
00:47:18,920 --> 00:47:22,760
the package authors-- about the features that they can add.

822
00:47:22,760 --> 00:47:24,720
And that's where we talk about documentation.

823
00:47:24,720 --> 00:47:27,560
So we could add something there to also say,

824
00:47:27,560 --> 00:47:31,400
if you'd like to let people know what kind of size impact

825
00:47:31,400 --> 00:47:36,760
this is going to have on your users' applications,

826
00:47:36,760 --> 00:47:38,440
we could put that in there.

827
00:47:38,440 --> 00:47:43,080
There is less incentive for them to add this feature

828
00:47:43,080 --> 00:47:44,960
than there is about the documentation,

829
00:47:44,960 --> 00:47:47,840
because if that number is big,

830
00:47:47,840 --> 00:47:52,040
it might stop people using the package.

831
00:47:52,040 --> 00:47:54,080
Yeah, that's true. It's true.

832
00:47:54,080 --> 00:48:00,040
But I think most packages will not have

833
00:48:00,040 --> 00:48:04,120
a significant effect on people's budget.

834
00:48:04,120 --> 00:48:06,920
And once you reach a tipping point of,

835
00:48:06,920 --> 00:48:08,960
well, why doesn't this package have that number,

836
00:48:08,960 --> 00:48:16,120
then that becomes much easier for people to kind of--

837
00:48:16,120 --> 00:48:18,320
there's going to be a little bit of peer pressure

838
00:48:18,320 --> 00:48:21,800
to adopt these features as they become more and more used.

839
00:48:21,800 --> 00:48:25,120
Yeah. Yeah, I mean, I could see this as some SDK

840
00:48:25,120 --> 00:48:28,520
having a good binary size and going forward

841
00:48:28,520 --> 00:48:31,640
and publishing that as an advantage

842
00:48:31,640 --> 00:48:33,840
and then sort of perhaps generating--

843
00:48:33,840 --> 00:48:36,800
because it's also not-- many packages won't need that, right?

844
00:48:36,800 --> 00:48:43,080
There's lots of dependencies that are sort of used

845
00:48:43,080 --> 00:48:45,640
in ways where binary size isn't that important.

846
00:48:45,640 --> 00:48:49,960
Like, we adopt packages in our server-side project

847
00:48:49,960 --> 00:48:53,400
where binary size isn't that crucial.

848
00:48:53,400 --> 00:48:56,520
I mean, we ship this thing in a Docker container.

849
00:48:56,520 --> 00:49:01,160
That package dependency is going to make no change whatsoever

850
00:49:01,160 --> 00:49:04,960
in our final product size.

851
00:49:04,960 --> 00:49:07,440
And there's also examples like the package

852
00:49:07,440 --> 00:49:09,840
we were talking about earlier, which is the testing package,

853
00:49:09,840 --> 00:49:11,280
expect to eventually equal.

854
00:49:11,280 --> 00:49:12,280
Exactly, yeah.

855
00:49:12,280 --> 00:49:14,720
Absolutely irrelevant to the size, yeah.

856
00:49:14,720 --> 00:49:18,040
Yeah. Here's a thought I had as you were talking about

857
00:49:18,040 --> 00:49:21,880
making it easier for people to act.

858
00:49:21,880 --> 00:49:26,200
I've actually just remembered because I had this thought before.

859
00:49:26,200 --> 00:49:31,280
What if we had little actions that--

860
00:49:31,280 --> 00:49:34,880
Yes, a button you click that opens up a pull request

861
00:49:34,880 --> 00:49:39,480
with a pre-configured SBI.yaml file against your repository.

862
00:49:39,480 --> 00:49:41,280
Like, for instance, adding documentation.

863
00:49:41,280 --> 00:49:43,120
We look at the thing.

864
00:49:43,120 --> 00:49:45,400
We could even read the package manifest,

865
00:49:45,400 --> 00:49:49,280
know what targets there are, generate an SBI.yaml file

866
00:49:49,280 --> 00:49:52,920
that's fully configured for the explicit repository,

867
00:49:52,920 --> 00:49:55,560
opens a pull request so that all they have to do

868
00:49:55,560 --> 00:49:57,840
is merge it into their repository

869
00:49:57,840 --> 00:50:00,560
if they don't have an SBI.yaml file already.

870
00:50:00,560 --> 00:50:03,640
So I've been thinking a little bit around this

871
00:50:03,640 --> 00:50:04,960
over the last couple of months as well.

872
00:50:04,960 --> 00:50:09,000
Not to the point of actually doing anything about it,

873
00:50:09,000 --> 00:50:11,120
but I do have a half-written note

874
00:50:11,120 --> 00:50:12,840
about how we might approach it.

875
00:50:12,840 --> 00:50:17,760
And one of the things that I think would--

876
00:50:17,760 --> 00:50:20,160
or one of the challenges that we have right now

877
00:50:20,160 --> 00:50:26,680
is that telling people, telling package authors--

878
00:50:26,680 --> 00:50:29,080
The package index at the moment has two groups

879
00:50:29,080 --> 00:50:30,920
of people who visit it.

880
00:50:30,920 --> 00:50:34,560
There is one which is people who are looking for a package,

881
00:50:34,560 --> 00:50:36,560
and they're the kind of obvious group.

882
00:50:36,560 --> 00:50:38,640
But there is also the group of package authors

883
00:50:38,640 --> 00:50:40,880
looking to look at their own packages

884
00:50:40,880 --> 00:50:44,720
and figure out what's happening with it or whatever it is.

885
00:50:44,720 --> 00:50:47,600
And we struggle--

886
00:50:47,600 --> 00:50:53,200
Our web pages are very much targeted at the first group.

887
00:50:53,200 --> 00:50:56,720
And the second group, they have their own page,

888
00:50:56,720 --> 00:50:59,600
and it's called Information for Package Maintainers

889
00:50:59,600 --> 00:51:00,720
or something like that.

890
00:51:00,720 --> 00:51:02,960
And there's a little, tiny little link to it

891
00:51:02,960 --> 00:51:06,040
halfway down the sidebar on the right-hand side of a page.

892
00:51:06,040 --> 00:51:08,560
And behind that is a whole load of information

893
00:51:08,560 --> 00:51:11,320
about adding badges, about how to configure documentation,

894
00:51:11,320 --> 00:51:15,160
links to all our documentation resources and things like that

895
00:51:15,160 --> 00:51:17,440
on this kind of subject.

896
00:51:17,440 --> 00:51:21,400
And that is a less than ideal place to put that.

897
00:51:21,400 --> 00:51:23,480
But of course, you don't want to overload the site

898
00:51:23,480 --> 00:51:26,000
with all that information being pushed down

899
00:51:26,000 --> 00:51:27,800
the throat of people who are only there just

900
00:51:27,800 --> 00:51:29,040
to find a package.

901
00:51:29,040 --> 00:51:31,960
And I think the ultimate answer to this

902
00:51:31,960 --> 00:51:37,320
is that at some point, we will have a logged-in area.

903
00:51:37,320 --> 00:51:40,880
And that area is entirely for package authors.

904
00:51:40,880 --> 00:51:43,040
Like, the whole point of that area

905
00:51:43,040 --> 00:51:48,840
is so that you can see that your packages are producing

906
00:51:48,840 --> 00:51:50,920
the compatibility you're expecting,

907
00:51:50,920 --> 00:51:53,640
that they are being indexed effectively,

908
00:51:53,640 --> 00:51:56,760
and showing the information that best highlights

909
00:51:56,760 --> 00:51:58,120
what that package does.

910
00:51:58,120 --> 00:52:01,840
And I don't think a authenticated area

911
00:52:01,840 --> 00:52:07,320
of the Swift Package Index is necessarily--

912
00:52:07,320 --> 00:52:09,640
I don't think the first thing that will come out of that

913
00:52:09,640 --> 00:52:11,800
will be for the people who are looking for packages.

914
00:52:11,800 --> 00:52:13,600
I think it will be for package authors.

915
00:52:13,600 --> 00:52:16,800
And this kind of stuff of generating an SPI YAML file,

916
00:52:16,800 --> 00:52:19,440
we'd have so much space for all that stuff

917
00:52:19,440 --> 00:52:23,240
if there was a way to let people authenticate

918
00:52:23,240 --> 00:52:25,000
and claim a package.

919
00:52:25,000 --> 00:52:27,840
And I've been thinking about how we would do the claiming as

920
00:52:27,840 --> 00:52:28,320
well.

921
00:52:28,320 --> 00:52:30,720
And this is now going into--

922
00:52:30,720 --> 00:52:34,160
this podcast is just full of rabbit holes today.

923
00:52:34,160 --> 00:52:40,520
But I think we could actually use the SPI YAML file to--

924
00:52:40,520 --> 00:52:45,240
yeah, to kind of say, these are the people who

925
00:52:45,240 --> 00:52:47,440
are authorized to maintain this package.

926
00:52:47,440 --> 00:52:49,880
And that way, you keep that responsibility

927
00:52:49,880 --> 00:52:57,600
with the repository of defining the data for that package.

928
00:52:57,600 --> 00:53:00,720
And then if we do a login with GitHub or whatever,

929
00:53:00,720 --> 00:53:03,000
that could-- it could just be a list of GitHub usernames

930
00:53:03,000 --> 00:53:03,880
or whatever it is.

931
00:53:03,880 --> 00:53:07,200
I mean, I haven't thought this through in that much detail

932
00:53:07,200 --> 00:53:07,680
yet.

933
00:53:07,680 --> 00:53:10,720
But I think that's potentially where we're heading

934
00:53:10,720 --> 00:53:11,800
with this kind of thing.

935
00:53:11,800 --> 00:53:13,320
Yeah.

936
00:53:13,320 --> 00:53:14,360
Right.

937
00:53:14,360 --> 00:53:14,720
Right.

938
00:53:14,720 --> 00:53:15,200
I think that's--

939
00:53:15,200 --> 00:53:16,160
Show me Bruce Dillard.

940
00:53:16,160 --> 00:53:17,160
--a long enough podcast.

941
00:53:17,160 --> 00:53:17,660
Yeah.

942
00:53:18,280 --> 00:53:20,520
[LAUGHTER]

943
00:53:20,520 --> 00:53:23,080
So we will be back in--

944
00:53:23,080 --> 00:53:25,760
last time that it took us to get this podcast out

945
00:53:25,760 --> 00:53:27,480
is as specific as I'm going to be.

946
00:53:27,480 --> 00:53:28,240
Big promises.

947
00:53:28,240 --> 00:53:31,200
[LAUGHTER]

948
00:53:31,200 --> 00:53:33,680
But until then, we will--

949
00:53:33,680 --> 00:53:35,640
well, we'll speak to you whenever that happens.

950
00:53:35,640 --> 00:53:37,360
It will probably be in three weeks' time.

951
00:53:37,360 --> 00:53:37,840
All right.

952
00:53:37,840 --> 00:53:38,680
See you next time.

953
00:53:38,680 --> 00:53:39,360
Bye bye.

954
00:53:39,360 --> 00:53:39,860
All right.