1
00:00:00,000 --> 00:00:05,520
We actually got some follow up to talk about. Because we know nothing Jon Snow.

2
00:00:05,520 --> 00:00:18,800
Remember we talked about extending our package usage popover last time.

3
00:00:18,800 --> 00:00:24,240
I do. We were going to add a product to it and we, even better than that, we followed through

4
00:00:24,240 --> 00:00:31,280
and actually did add a product clause to that use this package window. So tell me what went wrong, Sven.

5
00:00:31,280 --> 00:00:36,960
Well, we talked and we even ranted about package names and all that, remember?

6
00:00:36,960 --> 00:00:38,480
With the Swift prefix?

7
00:00:38,480 --> 00:00:45,120
Yeah, how people should name their repository one way and then use the name inside the package as

8
00:00:45,120 --> 00:00:49,040
something nice, you know, without the Swift prefix and stuff.

9
00:00:49,920 --> 00:00:56,320
Well, it turns out the product clause that you need to put into your dependencies, you know,

10
00:00:56,320 --> 00:01:03,680
when you have a, have a target depend on a product there, you specify the product name that you use

11
00:01:03,680 --> 00:01:12,400
and you specify something called package colon is the, is the label for the, um, for the product,

12
00:01:12,400 --> 00:01:16,960
thing, I said, this is the package name.

13
00:01:16,960 --> 00:01:19,880
It isn't, it isn't.

14
00:01:19,880 --> 00:01:23,520
We use the package name in the clause that we construct there, but it actually,

15
00:01:23,520 --> 00:01:28,760
that, that actually produces a wrong product clause because what actually

16
00:01:28,760 --> 00:01:33,880
needs to go in there is I think what Swift PM internally calls the package

17
00:01:33,880 --> 00:01:38,480
identifier, and this is derived from the repository.

18
00:01:39,960 --> 00:01:46,840
So I tried out a package which had a package name auto merge, but its repository is called

19
00:01:46,840 --> 00:01:53,080
Swift-automurge. And what needs to be in that product clause is Swift-automurge.

20
00:01:53,080 --> 00:02:01,800
I really, really hope that once we move to package registries, which will really have proper

21
00:02:01,800 --> 00:02:07,880
package identifiers, and I think there's a scheme proposed where you have like an owner slash

22
00:02:08,760 --> 00:02:16,120
package sort of scheme, which obviously then allows you to disambiguate in case,

23
00:02:16,120 --> 00:02:21,880
probably common case that there will be overlap in package names. Once that's there,

24
00:02:21,880 --> 00:02:27,320
that'll probably allow for better package names and still avoid clashes in names.

25
00:02:27,320 --> 00:02:31,400
But currently what seems to be happening, and I vaguely recall seeing this, is that

26
00:02:32,040 --> 00:02:39,480
Swift PM uses an identifier based on the repository name internally as a package ID,

27
00:02:39,480 --> 00:02:44,600
and that's the thing you need to specify. And I guess that's perhaps why it's called just

28
00:02:44,600 --> 00:02:49,240
"package colon" and not "package name", because it's not really the name but the identifier.

29
00:02:49,240 --> 00:02:53,160
- So hold on, it's coming from the Git repository, nothing to do with the package?

30
00:02:53,160 --> 00:02:56,680
- I think so. I can't think of another place where...

31
00:02:56,680 --> 00:02:57,880
- Okay, wow.

32
00:02:57,880 --> 00:03:03,320
As actually not Swift-automurge, it's automerge-swift is the name of the

33
00:03:03,320 --> 00:03:07,760
repository and what Swift PM says needs to be.

34
00:03:07,760 --> 00:03:15,680
So I tried this with just automerge as the package label there and Swift PM

35
00:03:15,680 --> 00:03:21,240
package resolve says the only valid package it knows about is automerge-swift.

36
00:03:21,240 --> 00:03:26,640
And the only place, the only other name, the manifest doesn't talk about

37
00:03:27,200 --> 00:03:30,960
AutoMerge-Swift, if I recall correctly.

38
00:03:30,960 --> 00:03:34,800
So the only other thing that has that name is the repository.

39
00:03:34,800 --> 00:03:37,700
- So I'm learning about this for the first time

40
00:03:37,700 --> 00:03:39,660
live on the podcast,

41
00:03:39,660 --> 00:03:41,300
because I knew that there was the issue,

42
00:03:41,300 --> 00:03:42,940
because you opened an issue this morning.

43
00:03:42,940 --> 00:03:45,660
But this is the first I've heard of the solution.

44
00:03:45,660 --> 00:03:48,580
And I think it says quite a lot that,

45
00:03:48,580 --> 00:03:51,620
I mean, I would say both you and I

46
00:03:51,620 --> 00:03:53,480
have a reasonably good understanding

47
00:03:53,480 --> 00:03:55,460
of Swift package manager at this point,

48
00:03:55,460 --> 00:03:57,720
after working on the package index for three years,

49
00:03:57,720 --> 00:04:00,920
and if we get it wrong, it's too confusing.

50
00:04:00,920 --> 00:04:02,280
- Well, maybe not.

51
00:04:02,280 --> 00:04:04,880
(both laughing)

52
00:04:04,880 --> 00:04:08,620
- So I guess are we gonna have to pass,

53
00:04:08,620 --> 00:04:11,180
I suppose we have the repository name already

54
00:04:11,180 --> 00:04:14,820
in our database, so this I think is fixable, isn't it?

55
00:04:14,820 --> 00:04:17,580
- It is fixable, I wonder if we should,

56
00:04:17,580 --> 00:04:20,940
so I'd love for the proper fix to be,

57
00:04:20,940 --> 00:04:25,240
I know, so for instance, if you look in package resolved,

58
00:04:25,240 --> 00:04:31,120
Um, the JSON file that gets, gets written out after you run Swift package resolve.

59
00:04:31,120 --> 00:04:36,640
In there, the struct, if I recall correctly has an identifier.

60
00:04:36,640 --> 00:04:41,260
So it says four packages, it has the URL and in the version two of that struct,

61
00:04:41,260 --> 00:04:43,320
um, there is also an identifier.

62
00:04:43,320 --> 00:04:49,240
And I, I think that's the thing I need to confirm this and I would rather try and

63
00:04:49,240 --> 00:04:54,960
and grab it from there or some official source than try and guess it from the

64
00:04:54,960 --> 00:05:00,240
repository name, you know, because that might change and then we have subtle breakage.

65
00:05:00,240 --> 00:05:05,280
I'd really like, because also this will, this will certainly change once we move to registries,

66
00:05:05,280 --> 00:05:11,120
because then I think the package format will use proper package identifiers and not, you know,

67
00:05:11,120 --> 00:05:17,280
these names that we're guessing. And we should really try and have some canonical source for

68
00:05:17,280 --> 00:05:22,640
what's actually used to identify what package you're looking at. And I think that'll solve

69
00:05:22,640 --> 00:05:28,800
everything in the end. And I truly hope the thing that we arrive at there isn't a Swift-Dash thing,

70
00:05:28,800 --> 00:05:36,080
but just a proper name that is disambiguated across projects and stuff, but is still

71
00:05:36,080 --> 00:05:43,040
nice and readable and has maybe a subcomponent or just a separate name that is descriptive and

72
00:05:43,040 --> 00:05:51,920
can be ambiguous because it's not the one used for identity matching, but can be the one that's

73
00:05:51,920 --> 00:05:57,200
displayed elsewhere. But this thing we thought it was isn't that.

74
00:05:57,200 --> 00:06:03,240
The downside is that we've already shipped and deployed the wrong version, but that's okay,

75
00:06:03,240 --> 00:06:09,480
we can fix it and get it working shortly. Yeah, I think it's not a common problem.

76
00:06:09,480 --> 00:06:13,520
The vast majority of the packages actually have those aligned anyway.

77
00:06:13,520 --> 00:06:15,240
Of course. Yes.

78
00:06:15,240 --> 00:06:19,440
It's probably we're punishing the ones that actually do the right thing, sort of.

79
00:06:19,440 --> 00:06:25,840
and we should absolutely fix it. No good deed goes unpunished. That's the way it

80
00:06:25,840 --> 00:06:32,640
is isn't it? There is another piece of news that we have this week which is we

81
00:06:32,640 --> 00:06:41,560
shipped a new feature to visualize the number of macros that a package includes.

82
00:06:41,560 --> 00:06:47,800
So we've had this data in the database for a little while now and a few weeks

83
00:06:47,800 --> 00:06:56,640
ago we shipped support for searching on whether a package has macro targets and

84
00:06:56,640 --> 00:07:03,120
now we have a new bullet point on the metadata section in the package page

85
00:07:03,120 --> 00:07:09,200
which shows you if it has any targets and if so how many targets it has and I

86
00:07:09,200 --> 00:07:13,360
already found it useful today when I was looking through package recommendations

87
00:07:13,360 --> 00:07:17,640
for the podcast and I looked at this one package and the name of this package

88
00:07:17,640 --> 00:07:23,340
suggested to me that it might include a macro and I instantly opened the package

89
00:07:23,340 --> 00:07:30,480
page and discovered that I was wrong and it didn't have a macro in it. But that was, you know,

90
00:07:30,480 --> 00:07:35,820
that saved me a whole load of digging through the package for manually

91
00:07:35,820 --> 00:07:40,340
trying to figure out that information. It was nice to be able to see that

92
00:07:40,340 --> 00:07:45,300
right there on the package page. So nice, yeah. That's another small but

93
00:07:45,300 --> 00:07:47,220
It's an important improvement.

94
00:07:47,220 --> 00:07:50,420
- Nice to have that on there and not just in the search.

95
00:07:50,420 --> 00:07:54,300
- It was a little bit of a struggle to come up with an icon

96
00:07:54,300 --> 00:07:56,360
to represent the concept of a macro.

97
00:07:56,360 --> 00:07:59,920
The closest I could get was macro photography.

98
00:07:59,920 --> 00:08:03,760
So it looks like a shutter in a camera,

99
00:08:03,760 --> 00:08:06,580
but I am aware that that is stretching it a little bit.

100
00:08:06,580 --> 00:08:09,980
- Yeah, it's a bit very obvious icon I'd say.

101
00:08:09,980 --> 00:08:12,900
- You try and represent macro better.

102
00:08:12,900 --> 00:08:21,460
I don't know maybe a puzzle piece now

103
00:08:21,460 --> 00:08:24,500
that I think of it. Okay with what what

104
00:08:24,500 --> 00:08:31,100
connection? Well it sort of expands and

105
00:08:31,100 --> 00:08:32,940
is a piece of a larger puzzle. That makes

106
00:08:32,940 --> 00:08:34,940
perfect sense doesn't it? I mean in my

107
00:08:34,940 --> 00:08:38,420
head that is. I'm very happy with a

108
00:08:34,940 --> 00:08:39,020
camera shutter yeah. All right well I'm too late now anyway.

109
00:08:39,020 --> 00:08:48,940
Right in in other news there's something worth mentioning and that is GitHub added

110
00:08:48,940 --> 00:08:54,380
CodeQL support recently and there was a really nice introductory post by Tim Condon on the

111
00:08:54,380 --> 00:09:04,780
Swift forums. I saw it yeah. And what this does is it allows you to add code quality checks

112
00:09:04,780 --> 00:09:08,780
that run automatically on pull requests and your main branch.

113
00:09:08,780 --> 00:09:12,780
So this is something, it's really simple, I just added this

114
00:09:12,780 --> 00:09:15,780
this morning to one of our repositories to try it out.

115
00:09:15,780 --> 00:09:20,780
It's really just a small YAML snippet that you put into a new

116
00:09:20,780 --> 00:09:25,780
workflow file in your .github/workflows directory.

117
00:09:25,780 --> 00:09:29,780
And then it runs a check automatically

118
00:09:29,780 --> 00:09:38,260
and I guess it checks for specific quality metrics in Swift code, common bugs and stuff like that.

119
00:09:38,260 --> 00:09:42,580
And the new thing is obviously that it now supports Swift. This has been around, I think,

120
00:09:42,580 --> 00:09:47,780
for other languages for quite a while. And it's new that this is supporting Swift now.

121
00:09:47,780 --> 00:09:52,500
As I said, we added this to a semantic version, one of our packages.

122
00:09:52,500 --> 00:09:58,500
And we'll also add a link in the show notes what this looks like. There's a little overview page

123
00:09:58,500 --> 00:10:04,100
for the most recent scan to show that it's working and it's done its job and

124
00:10:04,100 --> 00:10:09,380
hopefully not found anything. So that's quite nice. And another thing that GitHub

125
00:10:09,380 --> 00:10:17,740
added recently is in Dependabot there's now support for Swift. Now Dependabot

126
00:10:17,740 --> 00:10:23,160
also is a feature that has been around for a while for other languages which is

127
00:10:23,160 --> 00:10:27,160
a tool that checks for outdated dependencies in your package.

128
00:10:27,160 --> 00:10:31,920
And so if you add this to your repository, it'll go through.

129
00:10:31,920 --> 00:10:33,600
And now it's supporting Swift.

130
00:10:33,600 --> 00:10:36,400
It'll check if there are any Swift dependencies that are outdated

131
00:10:36,400 --> 00:10:37,560
that should be updated.

132
00:10:37,560 --> 00:10:41,920
We've actually had this for a while now with a different package,

133
00:10:41,920 --> 00:10:45,160
and that's a GitHub action by Mako Eidinger.

134
00:10:45,160 --> 00:10:48,400
It's called Swift Package Dependencies Checker,

135
00:10:48,400 --> 00:10:51,040
which is also really nice.

136
00:10:51,040 --> 00:10:56,200
And we'll actually keep using that tool because this tool is, uh, supports the

137
00:10:56,200 --> 00:10:57,120
latest Swift version.

138
00:10:57,120 --> 00:11:03,540
Now the GitHub, the Penderbot feature only supports Swift 5.9, but with our

139
00:11:03,540 --> 00:11:08,380
main repository, we're using it, we're already on the Swift 5.9 beta, so we

140
00:11:08,380 --> 00:11:09,740
can't actually use it there yet.

141
00:11:09,740 --> 00:11:17,020
So Marco's tool is, or action is still very useful for us and is also a really

142
00:11:17,020 --> 00:11:19,300
nice thing to get the same feature effectively.

143
00:11:19,300 --> 00:11:22,120
So what this does, it'll open a pull request on your repository when there

144
00:11:22,120 --> 00:11:23,680
are changes in your dependencies.

145
00:11:23,680 --> 00:11:28,920
You can review those and then just merge it if you're happy and have

146
00:11:28,920 --> 00:11:32,480
one to all your dependencies to move up to the latest version.

147
00:11:32,480 --> 00:11:33,780
Yeah, it's great.

148
00:11:33,780 --> 00:11:40,160
And, um, I think, I mean, there was macro script is, is really good.

149
00:11:40,160 --> 00:11:45,600
Um, and we've been using it happily for months now, if not maybe a year,

150
00:11:45,600 --> 00:11:47,160
something like that a long time anyway.

151
00:11:47,640 --> 00:11:52,020
Um, but obviously that takes, that takes investigation. And first of all,

152
00:11:52,020 --> 00:11:53,220
you have to have the, the,

153
00:11:53,220 --> 00:11:57,300
the idea to research whether anyone's figured out a way to do this.

154
00:11:57,300 --> 00:12:01,900
And then one thing that's really important about some company like

155
00:12:01,900 --> 00:12:06,380
GitHub taking a hold of this problem is that it

156
00:12:06,380 --> 00:12:11,340
raises this issue into people's kind of into the

157
00:12:11,340 --> 00:12:14,500
front of people's minds. You know, there'll be a lot of press around, um,

158
00:12:15,020 --> 00:12:18,620
blog posts and people talking about it and us talking about it on the

159
00:12:18,620 --> 00:12:21,100
podcast and other podcasts talking about it and that kind of thing.

160
00:12:21,100 --> 00:12:28,060
And half of the advantage of that is just letting people know, "Oh, if you haven't yet

161
00:12:28,060 --> 00:12:34,380
done this, then this is a great thing to think about for your projects or repositories."

162
00:12:34,380 --> 00:12:39,500
- Yeah, and in particular, because the onboarding is so easy, there's a couple of things you can

163
00:12:39,500 --> 00:12:46,700
just do with a click of a button. And the most extensive dependency check, because it can actually

164
00:12:46,700 --> 00:12:57,260
do a dependency check also beyond your major version. So it can actually alert you to a new

165
00:12:57,260 --> 00:13:02,700
latest major version that you're actually not opting into. And that requires additional

166
00:13:02,700 --> 00:13:07,500
configuration. But all the basic stuff is actually just a click of a button. So it's so easy to

167
00:13:07,500 --> 00:13:10,420
to configure that there's really no reason not to do it.

168
00:13:10,420 --> 00:13:16,080
Um, the only slight downside is that GitHub doesn't have a great history,

169
00:13:16,080 --> 00:13:21,220
um, supporting the latest, um, beta versions of stuff, you know, like macros

170
00:13:21,220 --> 00:13:26,360
version in particular, that runners are always a bit behind and the Swift version.

171
00:13:26,360 --> 00:13:30,400
I, it doesn't support it right now, but it's also a very new feature.

172
00:13:30,400 --> 00:13:33,360
So we can't judge it based on that.

173
00:13:33,360 --> 00:13:37,320
Um, we'll have to see how that goes, but I suspect if you're.

174
00:13:37,320 --> 00:13:45,000
tracking the latest beta version of Swift, that might not be the tool for you then in that case.

175
00:13:45,000 --> 00:13:51,240
- Yeah. Although there's another way to look at that, which is that now this tool supports Swift

176
00:13:51,240 --> 00:13:57,160
and more and more people would be relying on this tool. I don't think they'll go into beta versions

177
00:13:57,160 --> 00:14:05,320
just yet, but it might increase the urgency of upgrading to latest release versions because

178
00:14:05,320 --> 00:14:10,040
If they don't, then this tool will stop working for a certain amount of projects, and maybe that

179
00:14:10,040 --> 00:14:17,080
will slightly up the priority of those upgrades a little bit. I think there's one other thing worth

180
00:14:17,080 --> 00:14:22,360
mentioning here, which is part of this feature I think is actually switched on by default,

181
00:14:22,360 --> 00:14:28,360
and you have to opt out rather than opting in. And that is that if there is a security

182
00:14:29,160 --> 00:14:36,680
CVE raised against any Swift package, it will depend upon will automatically, without you opting

183
00:14:36,680 --> 00:14:42,280
into anything, it will automatically alert you to that problem. And you can then opt in as well to

184
00:14:42,280 --> 00:14:46,120
have it raise a pull request to increase the version of just that one package

185
00:14:46,120 --> 00:14:53,320
outside of the global dependency update thing. Oh, that's really nice. I wasn't aware of that.

186
00:14:53,320 --> 00:14:59,960
That's really cool. Yes. This whole automatic tracking and reporting is just so great because

187
00:14:59,960 --> 00:15:05,640
it's the thing, if you don't think about that and set up the schedules for that, it's really easy to

188
00:15:05,640 --> 00:15:13,160
just miss out on all of this. And you might have an idea to sometimes run Swift package update and

189
00:15:13,160 --> 00:15:18,360
absorb that, but you know, who does that manually? It's just something you easily forget. Yeah.

190
00:15:19,400 --> 00:15:26,520
Right. Another thing we might want to talk about is an upcoming feature.

191
00:15:26,520 --> 00:15:31,560
I mean, not upcoming in the sense of next week or the week after, but it's something that we've been

192
00:15:31,560 --> 00:15:37,720
working on for quite a while. And it got sort of pulled to the forefront again, because as part of

193
00:15:37,720 --> 00:15:46,040
Dependabot, there is something in GitHub that will obviously deal with dependencies. And I think

194
00:15:46,040 --> 00:15:53,320
there's also a way to see package dependencies of Swift projects. I haven't actually seen the UI,

195
00:15:53,320 --> 00:15:59,080
but I saw some mention of it. I need to go back and check if it's actually in the

196
00:15:59,080 --> 00:16:07,240
Git UI, but it reminded me that we had started work a while back on displaying dependencies

197
00:16:07,240 --> 00:16:13,320
on the package page in the Swift package index. Now we do something already. We do show the total

198
00:16:13,320 --> 00:16:20,600
dependency count of a package on the package page. And all of this is based on package resolved,

199
00:16:20,600 --> 00:16:26,520
which is the file that SwiftPM writes out when it does the package resolution.

200
00:16:26,520 --> 00:16:37,640
Now this dependency count is nice. It is useful, but it's also, it captures all dependencies.

201
00:16:38,520 --> 00:16:44,600
that is both the transient dependencies as well as the test dependencies. And

202
00:16:44,600 --> 00:16:52,840
that might not always be the thing you're looking for. And we certainly want to extend this. And

203
00:16:52,840 --> 00:16:58,920
we spent some time quite a while ago to look into how to extend this, in particular to

204
00:16:58,920 --> 00:17:06,600
break out the test targets so we can actually display these separately. I call them product

205
00:17:06,600 --> 00:17:11,960
dependencies, which are the dependencies that your products, your package products depend on,

206
00:17:11,960 --> 00:17:18,040
and the test dependencies separately, and in particular to make those dependencies navigatable

207
00:17:18,040 --> 00:17:25,240
on the package page. And I think it's just worth mentioning at this point how this problem is

208
00:17:25,240 --> 00:17:30,680
manifesting itself with the current implementation that we have. So if you look at a package at the

209
00:17:30,680 --> 00:17:37,400
moment, you might see this package has four package dependencies. And let's say, for example,

210
00:17:37,400 --> 00:17:45,080
that package uses one dependency in the actual package, and then QUIC and Nimble and maybe

211
00:17:45,080 --> 00:17:50,520
another test dependency to run their tests. Seeing on a package page, this package has

212
00:17:50,520 --> 00:17:55,320
four dependencies might put somebody in a frame of mind of like, oh, actually, that's quite a

213
00:17:55,320 --> 00:18:01,560
quite a lot of dependencies to have for what might be a small package, but actually three of them are

214
00:18:01,560 --> 00:18:09,640
only there to run the tests, which I mean, in my opinion, test dependencies are much less important

215
00:18:09,640 --> 00:18:17,720
when I'm choosing a potential dependency for my project than if it were a product dependency.

216
00:18:18,360 --> 00:18:22,360
And also, it's also not clear on our webpage

217
00:18:22,360 --> 00:18:26,240
whether those dependencies are direct or transient.

218
00:18:26,240 --> 00:18:29,740
And I think if I saw four dependencies

219
00:18:29,740 --> 00:18:30,900
or three dependencies or two,

220
00:18:30,900 --> 00:18:33,160
I'd assume that's two top level,

221
00:18:33,160 --> 00:18:37,640
but we have no current way of showing that information.

222
00:18:37,640 --> 00:18:38,920
- Yeah, and it'll be really nice

223
00:18:38,920 --> 00:18:42,400
if the top level dependencies were shown, right?

224
00:18:42,400 --> 00:18:43,440
And you could click through

225
00:18:43,440 --> 00:18:46,480
and then if there are actually a package in the index,

226
00:18:46,480 --> 00:18:48,120
it'll land on that package page.

227
00:18:48,120 --> 00:18:51,120
would be really nice to have that graph traversable.

228
00:18:51,120 --> 00:18:55,480
You know, obviously, if if it's not in the index, which is unlikely

229
00:18:55,480 --> 00:18:57,480
because we actually add them automatically,

230
00:18:57,480 --> 00:19:00,480
if we find we have a nightly job that goes through

231
00:19:00,480 --> 00:19:04,680
and if a package is referenced by another package that's in the index,

232
00:19:04,680 --> 00:19:09,240
it's then added to the index in the next day.

233
00:19:09,240 --> 00:19:14,880
So we should actually have a fully onboarded graph of packages.

234
00:19:14,880 --> 00:19:18,000
But it would be really nice to have those exposed

235
00:19:18,000 --> 00:19:20,080
and make them navigatable.

236
00:19:20,080 --> 00:19:24,600
So yeah, that's certainly something we want to do.

237
00:19:24,600 --> 00:19:27,040
And what we did first is look at package resolve

238
00:19:27,040 --> 00:19:28,840
because that's really easy to do.

239
00:19:28,840 --> 00:19:31,480
And Swift PM does all the heavy lifting

240
00:19:31,480 --> 00:19:34,380
of actually accounting for all those dependencies.

241
00:19:34,380 --> 00:19:35,320
But the problem is--

242
00:19:35,320 --> 00:19:36,960
- Actually doing the resolving.

243
00:19:36,960 --> 00:19:37,800
- Yeah, that's the problem.

244
00:19:37,800 --> 00:19:40,440
And there is nothing in package resolve

245
00:19:40,440 --> 00:19:45,100
that will tell you afterwards what are direct dependencies,

246
00:19:45,100 --> 00:19:46,620
What are transit dependencies?

247
00:19:46,620 --> 00:19:48,540
What are test dependencies?

248
00:19:48,540 --> 00:19:51,140
It's just a flat list of dependencies.

249
00:19:51,140 --> 00:19:56,180
And that's why we have that fixed number and we can't really separate those out.

250
00:19:56,180 --> 00:19:58,380
There is a way of doing that.

251
00:19:58,380 --> 00:20:03,860
That's not too crazy that we spent some time, um, figuring out how to do, and,

252
00:20:03,860 --> 00:20:05,860
and this is the approach we'll take.

253
00:20:05,860 --> 00:20:10,900
Um, but it's maybe worth thinking of the main queries where we're

254
00:20:10,900 --> 00:20:12,220
wanting to support with this.

255
00:20:12,260 --> 00:20:16,220
Um, and obviously all of this is up for discussion and we actually have an issue

256
00:20:16,220 --> 00:20:19,960
where we currently tracking our thoughts around this, which we linked to in the

257
00:20:19,960 --> 00:20:20,580
show notes.

258
00:20:20,580 --> 00:20:28,420
Um, and I think, I mean, you alluded to this, the product dependencies are really

259
00:20:28,420 --> 00:20:33,240
where the meat of the matter is because those are the ones that go into your app

260
00:20:33,240 --> 00:20:35,280
or your service, whatever it is.

261
00:20:35,280 --> 00:20:41,520
Those are the ones that partake in your, in your, um, artifact that you're shipping.

262
00:20:41,540 --> 00:20:45,460
So those are the ones that going to be impacted by CVs and the like.

263
00:20:45,460 --> 00:20:50,020
Or just source code breakage, right?

264
00:20:50,020 --> 00:20:56,700
If you want to assess ahead of time, how exposed am I to potential API changes

265
00:20:56,700 --> 00:21:02,260
and having to deal with them, the lower the number of packages, the less likely that is.

266
00:21:02,260 --> 00:21:06,420
So that's why that's important.

267
00:21:09,460 --> 00:21:14,260
And this also assumes that in a pinch, right, if there's breakage due to something in test

268
00:21:14,260 --> 00:21:19,620
dependencies, you can ignore those, right? If your test dependencies depend on a package

269
00:21:19,620 --> 00:21:25,860
that has a change so that you can't run your tests and you really need to get out a hot fix,

270
00:21:25,860 --> 00:21:31,460
I think you're going to have an argument and say, right, okay, we need to fix this. We can do some

271
00:21:31,460 --> 00:21:36,980
manual testing, we get this out, and then we deal with the test dependency after the fact. That's

272
00:21:36,980 --> 00:21:41,140
probably something you can get away with. If that's a product dependency, you can't.

273
00:21:41,140 --> 00:21:41,780
100%.

274
00:21:41,780 --> 00:21:44,020
So that's why that distinction is certainly important.

275
00:21:44,020 --> 00:21:51,300
But test dependencies are still important because there's this other thing that comes up

276
00:21:51,300 --> 00:21:57,700
again and again, and that's being referred to as the software bill of materials.

277
00:21:57,700 --> 00:22:03,780
And that's effectively your complete attack surface to supply chain attacks.

278
00:22:03,780 --> 00:22:08,820
and test dependencies do play a role there because you run stuff. You run your tests,

279
00:22:08,820 --> 00:22:16,100
and anything you do in CI or locally, anything you run and any source code that goes into

280
00:22:16,100 --> 00:22:24,980
impact what you run there is open to any malicious package messing with what you're running and where

281
00:22:24,980 --> 00:22:32,740
you're running it. A while back, way back, there was a compromised Xcode version that got shipped

282
00:22:32,740 --> 00:22:38,260
and or got, you know, people were tricked into downloading it and that impacted how you ran your

283
00:22:38,260 --> 00:22:43,940
stuff. And then downstream from there are all sorts of problems, you know, like secrets being

284
00:22:43,940 --> 00:22:50,900
leaked because of stuff like that. So you still want to know what your total surface is, you know,

285
00:22:50,900 --> 00:22:55,860
what code are you actually pulling in across your whole package, but there's a bit of a difference

286
00:22:55,860 --> 00:23:02,740
in, in importance, I guess, or, and because these supply chain chain attacks are, are

287
00:23:02,740 --> 00:23:09,460
probably not targeted at an indie developer or if, if it is, you know, you're probably.

288
00:23:09,460 --> 00:23:12,260
You're probably not going to be picked on it.

289
00:23:12,260 --> 00:23:15,060
They're going to pick the, the big targets, the important targets.

290
00:23:15,060 --> 00:23:20,900
Um, but it's certainly a good thing to have exposed and to be able to see ahead of time

291
00:23:20,900 --> 00:23:25,060
what the list of packages really is, what that bill of materials really is.

292
00:23:25,060 --> 00:23:30,960
And maybe the last thing that's interesting is usage tracking.

293
00:23:30,960 --> 00:23:36,060
And that's how many packages depend on this package P that you're looking at.

294
00:23:36,060 --> 00:23:41,180
And while that's an interesting metric, that's probably one that we can never

295
00:23:41,180 --> 00:23:48,060
really produce in a useful sense, because we only see open source packages.

296
00:23:48,060 --> 00:23:53,560
So any usage we would ever see in these metrics is open source

297
00:23:53,560 --> 00:23:55,820
packages using this open source package.

298
00:23:55,820 --> 00:24:02,140
And given that we currently track 6,000 packages and there's like, it's

299
00:24:02,140 --> 00:24:03,640
millions of apps out there, right?

300
00:24:03,640 --> 00:24:05,600
This is going to be dwarfed.

301
00:24:05,600 --> 00:24:12,740
Like it's the number of, of actually packages using a package like alarmofire.

302
00:24:12,740 --> 00:24:16,700
It's not the package that we have in index that use alarmofire that are

303
00:24:16,700 --> 00:24:18,440
the actual clients of alarmofire.

304
00:24:18,440 --> 00:24:23,180
The clients of alarmofire are all the apps in the app store that actually

305
00:24:23,180 --> 00:24:27,780
embed that library and we have no usage stats on those.

306
00:24:27,780 --> 00:24:30,980
So that is probably not really even a useful thing

307
00:24:30,980 --> 00:24:32,160
to try and expose.

308
00:24:32,160 --> 00:24:36,880
- Yeah, it's tragic in a way because we do have,

309
00:24:36,880 --> 00:24:40,380
well, we will have a really nice set of data,

310
00:24:40,380 --> 00:24:44,100
but I would say that unless we come up with a way

311
00:24:44,100 --> 00:24:48,420
for people who build apps to anonymously report

312
00:24:48,420 --> 00:24:51,340
what packages they are depending on in their app,

313
00:24:51,340 --> 00:24:55,820
which we could do. And we don't need to go into how we could do that, but we could do that.

314
00:24:55,820 --> 00:25:02,460
But I also think that, you know, even if we went down that route, there's so much work to do to get

315
00:25:02,460 --> 00:25:08,700
people to adopt that, that I'm not sure we could ever trust that data. And I think it's almost a

316
00:25:08,700 --> 00:25:12,900
little bit of a tragedy that we'll have a subset of this, but we won't really ever be able to do

317
00:25:12,900 --> 00:25:14,300
anything useful with it.

318
00:25:14,300 --> 00:25:20,980
Yeah, I think it might be really nice. And maybe that's an option if a package registry had a way

319
00:25:21,020 --> 00:25:27,860
of reporting that back to us or some service, because I think there's value in that for

320
00:25:27,860 --> 00:25:31,840
you, even for the clients of Alarm or Fire to report that back.

321
00:25:31,840 --> 00:25:36,780
Because then on the way back, that could be reporting of CVEs.

322
00:25:36,780 --> 00:25:44,020
Imagine someone is, for instance, using Swift Neo and there could be just like Dependabot,

323
00:25:44,020 --> 00:25:49,820
it could be a service maybe based on the package index in combination with the registry to

324
00:25:49,820 --> 00:25:57,500
report back to application authors that there's something wrong and notify them

325
00:25:57,500 --> 00:25:59,900
that there's a CVE against a package that they're using.

326
00:25:59,900 --> 00:26:05,700
So that might be a nice avenue to incentivize people to opt in if it's an

327
00:26:05,700 --> 00:26:08,300
opt in process to this kind of reporting.

328
00:26:08,300 --> 00:26:16,380
And that data is in many ways much better than a lot of the data that language,

329
00:26:16,380 --> 00:26:18,060
other language indexes use.

330
00:26:18,060 --> 00:26:22,720
So for example, a lot of dependency indexes

331
00:26:22,720 --> 00:26:25,280
for other languages use downloads as a metric

332
00:26:25,280 --> 00:26:27,220
of how popular something is.

333
00:26:27,220 --> 00:26:31,320
So whenever a package is grabbed by the package manager,

334
00:26:31,320 --> 00:26:33,960
they'll take up a count on the number of downloads.

335
00:26:33,960 --> 00:26:36,600
And that's certainly an indicator,

336
00:26:36,600 --> 00:26:39,080
but there's enough downloads

337
00:26:39,080 --> 00:26:40,960
that someone trying out a package

338
00:26:40,960 --> 00:26:42,300
or just testing something.

339
00:26:42,300 --> 00:26:45,480
Whereas if you actually have what packages

340
00:26:45,480 --> 00:26:47,800
are actually in use at build time,

341
00:26:47,800 --> 00:26:50,680
that's really different information.

342
00:26:50,680 --> 00:26:52,800
And I think it's probably a better indicator,

343
00:26:52,800 --> 00:26:55,240
but we've got such a long road to go down

344
00:26:55,240 --> 00:26:58,560
for that to be anything like useful.

345
00:26:58,560 --> 00:27:00,720
And I think step one is exactly what we're planning

346
00:27:00,720 --> 00:27:05,720
to do here, which is give people some information

347
00:27:05,720 --> 00:27:08,240
about the dependencies of the packages

348
00:27:08,240 --> 00:27:10,000
that they are considering using themselves

349
00:27:10,000 --> 00:27:12,120
and not to worry about the bigger picture.

350
00:27:12,120 --> 00:27:14,600
- Yeah, and I'm hopeful that we can break this down further

351
00:27:14,600 --> 00:27:16,400
because it's quite a large piece.

352
00:27:16,400 --> 00:27:19,300
I went through my notes this morning

353
00:27:19,300 --> 00:27:23,680
to sort of recap where we left it.

354
00:27:23,680 --> 00:27:27,240
And this is going to be quite complicated.

355
00:27:27,240 --> 00:27:30,140
And hopefully there's some intermediate things

356
00:27:30,140 --> 00:27:33,580
that we can release to make that incrementally more useful

357
00:27:33,580 --> 00:27:35,840
than it is now with the total count.

358
00:27:35,840 --> 00:27:38,900
- Even if it's just the case of bringing the data

359
00:27:38,900 --> 00:27:42,240
in bit by bit or adding the extra bits of analysis

360
00:27:42,240 --> 00:27:44,800
on the data bit by bit before we expose anything

361
00:27:44,800 --> 00:27:46,200
to the user interface.

362
00:27:46,200 --> 00:27:49,760
So yeah, I think it would be good to chip away at this

363
00:27:49,760 --> 00:27:50,600
in smaller chunks.

364
00:27:50,600 --> 00:27:52,840
It's always better to approach things that way.

365
00:27:52,840 --> 00:27:54,000
- Yeah, definitely.

366
00:27:54,000 --> 00:27:56,800
- Right, we've actually,

367
00:27:56,800 --> 00:27:59,520
we've whitted on quite extensively today.

368
00:27:59,520 --> 00:28:02,120
Let's get into some package recommendations.

369
00:28:02,120 --> 00:28:05,040
Do you wanna give us the first one?

370
00:28:05,040 --> 00:28:11,020
- My first one is called DataKit by Paul Kraft,

371
00:28:11,020 --> 00:28:16,420
Paul Kraft, he's German, so I'm confident in the pronunciation of the name.

372
00:28:16,420 --> 00:28:19,580
That's not what I got from the way you said that.

373
00:28:19,580 --> 00:28:21,100
I didn't get any confidence at all.

374
00:28:21,100 --> 00:28:24,180
Damn.

375
00:28:24,180 --> 00:28:29,100
DataKit is a really great package.

376
00:28:29,100 --> 00:28:30,780
I loved, I loved seeing this.

377
00:28:30,780 --> 00:28:35,020
Um, it's a great package when you're working with custom binary data formats.

378
00:28:35,020 --> 00:28:40,140
And this sort of brought me back to a time several years ago when I had to

379
00:28:40,140 --> 00:28:43,880
decode a proprietary proprietary data format.

380
00:28:43,880 --> 00:28:48,160
Um, and even way back further in the physics days, where we're losing, using

381
00:28:48,160 --> 00:28:54,520
lots of proprietary custom data formats, because it really, every bit even counted

382
00:28:54,520 --> 00:28:59,520
at the time, and this can be really fiddly, but what this package does, it

383
00:28:59,520 --> 00:29:05,940
gives you a, um, result builder based DSL where you can actually specify this.

384
00:29:05,940 --> 00:29:07,080
It's really nice.

385
00:29:07,080 --> 00:29:13,720
It sort of looks like Swift UI layout, but for your data, you can define static data

386
00:29:13,720 --> 00:29:17,960
blocks, like certain byte patterns that you want as markers.

387
00:29:17,960 --> 00:29:25,040
You can then specify your values, properties, do conversions where needed.

388
00:29:25,040 --> 00:29:28,080
So by values, properties, I mean, you know, like data types.

389
00:29:28,080 --> 00:29:34,960
And obviously specify quite in detail ways, the bit size of them.

390
00:29:34,960 --> 00:29:36,720
Use conversions where needed.

391
00:29:37,040 --> 00:29:43,520
really nice. The reading and writing can be driven by different conformers to a read format

392
00:29:43,520 --> 00:29:50,640
and a write format protocol. That's if you have to do different things or if you only implement a read

393
00:29:50,640 --> 00:29:56,160
of a format, for instance, or you can do it jointly by conforming to a format. It's a bit like

394
00:29:56,160 --> 00:30:03,280
codable, you know, that has a encodable and a decodable form protocol that you conform to.

395
00:30:03,840 --> 00:30:09,360
And it also has a CRC checksum support component so you can tack this on and then

396
00:30:09,360 --> 00:30:14,880
I guess in some way ensure that what you've received and decoded is actually

397
00:30:14,880 --> 00:30:22,160
came across the wire and is intact still. Really nice. This whole thing works in a playground so

398
00:30:22,160 --> 00:30:27,840
you can use our feature to try in a playground which I always love calling out because that's

399
00:30:27,840 --> 00:30:33,440
how I actually play with packages and look at them and you can and that I would have found really

400
00:30:33,440 --> 00:30:39,440
really useful working and trying to load a file, stick this in and then piece by piece try and

401
00:30:39,440 --> 00:30:48,000
parse a file back out. So really nice package. DataKit by Paul Kraft. How was that for the

402
00:30:48,000 --> 00:30:58,320
pronunciation, Dave? Yes, much better, much more confident, absolutely. My first package is a

403
00:30:58,320 --> 00:31:03,600
package that we don't use directly, but we do use the underlying technology behind it.

404
00:31:03,600 --> 00:31:14,480
So the package is called SwiftWhisper by Aaron Taylor. And it is a wrapper around a C++ library

405
00:31:14,480 --> 00:31:22,320
that interacts with the Whisper AI model from, I believe it's OpenAI that produces the Whisper

406
00:31:22,320 --> 00:31:31,040
model. And Whisper takes audio files and will transcribe them with quite unbelievable accuracy.

407
00:31:31,040 --> 00:31:41,280
It is a remarkable library. So we use it to transcribe all of these podcasts. We run it

408
00:31:41,280 --> 00:31:49,040
through an application called MacWhisper by Jordi Bruin. There's also an app called Ico, which I

409
00:31:49,040 --> 00:31:51,600
which I believe is by Sindre Sohus.

410
00:31:51,600 --> 00:31:55,840
And both of those use the whisper model

411
00:31:55,840 --> 00:31:59,240
to take in an MP3 file or a web file

412
00:31:59,240 --> 00:32:00,840
and produce a transcript.

413
00:32:00,840 --> 00:32:04,700
And I mean, I'll see how it does with the,

414
00:32:04,700 --> 00:32:08,040
with your pronunciation of the previous author's name

415
00:32:08,040 --> 00:32:13,240
this time, but it does actually get author names

416
00:32:13,240 --> 00:32:16,520
like remarkably accurately transcribed.

417
00:32:16,520 --> 00:32:18,420
It's an amazing bit of software.

418
00:32:18,420 --> 00:32:23,420
And so this package is a way for you to interact

419
00:32:23,420 --> 00:32:29,620
with that model from a Swift application.

420
00:32:29,620 --> 00:32:33,720
It doesn't come with the models included,

421
00:32:33,720 --> 00:32:37,200
but it does include a link where you can download

422
00:32:37,200 --> 00:32:39,160
pre-trained models, 'cause obviously the model

423
00:32:39,160 --> 00:32:44,160
is a huge part of that dependency.

424
00:32:44,320 --> 00:32:47,960
But yeah, it seems like a really easy way

425
00:32:47,960 --> 00:32:52,960
to get either offline or even potentially

426
00:32:52,960 --> 00:32:56,160
real-time translation, transcription, sorry,

427
00:32:56,160 --> 00:32:58,880
into an application that you're looking at.

428
00:32:58,880 --> 00:33:01,600
And the nice thing about it is that these models

429
00:33:01,600 --> 00:33:03,320
can be shipped along with your app.

430
00:33:03,320 --> 00:33:05,280
So it's not the kind of thing

431
00:33:05,280 --> 00:33:07,280
that requires an online connection.

432
00:33:07,280 --> 00:33:10,220
- Nice, yeah, I'm really surprised

433
00:33:10,220 --> 00:33:12,140
about the quality of these tools

434
00:33:12,140 --> 00:33:13,760
and how quickly that evolved.

435
00:33:13,760 --> 00:33:19,280
Cause I recall that being quite difficult and often, you know, especially with

436
00:33:19,280 --> 00:33:23,540
technical terms and names and stuff, this, this is so amazing that this actually works.

437
00:33:23,540 --> 00:33:28,080
I mean, there's still cases where this doesn't work correctly, but you can see

438
00:33:28,080 --> 00:33:31,580
with, with, you know, bigger models that it'll, it'll get there.

439
00:33:31,580 --> 00:33:34,660
And I, even, even humans fail at this at times, right?

440
00:33:34,660 --> 00:33:38,440
You misunderstand something or you have a different term in mind and are

441
00:33:38,440 --> 00:33:39,620
confused about what it is.

442
00:33:39,620 --> 00:33:43,140
So it's not, not surprising that this goes wrong sometimes.

443
00:33:43,580 --> 00:33:47,900
And we've talked about this on the podcast in the past and this idea of,

444
00:33:47,900 --> 00:33:49,620
um,

445
00:33:49,620 --> 00:33:54,700
uses for AI that don't involve the AI having to come up with kind of original

446
00:33:54,700 --> 00:33:59,420
thought or original data or knowledge based answers and things like that.

447
00:33:59,420 --> 00:34:01,460
And this is a perfect example of that. Yes,

448
00:34:01,460 --> 00:34:04,900
it might not get every single bit of transcription correct,

449
00:34:04,900 --> 00:34:10,220
but it's never going to just start hallucinating or at least in our experience

450
00:34:10,220 --> 00:34:12,780
it doesn't, it doesn't hallucinate. It sometimes,

451
00:34:12,820 --> 00:34:15,740
It sometimes makes mistakes, but it never hallucinates.

452
00:34:15,740 --> 00:34:18,360
And it's because it's that problem domain

453
00:34:18,360 --> 00:34:21,720
is very well suited to this kind of AI.

454
00:34:21,720 --> 00:34:22,860
- Well, sticking with the theme,

455
00:34:22,860 --> 00:34:26,300
my second pick is actually very similar.

456
00:34:26,300 --> 00:34:30,260
It's called Cleverbird by BT Franklin.

457
00:34:30,260 --> 00:34:35,260
And it's an open API, no, it's an open AI API wrapper.

458
00:34:35,260 --> 00:34:37,380
And I actually mistyped this in my notes

459
00:34:37,380 --> 00:34:39,140
because I always mix these up.

460
00:34:39,140 --> 00:34:40,980
Open AI API wrapper.

461
00:34:41,860 --> 00:34:46,700
And it's actually the package we're using in one of our packages to generate package

462
00:34:46,700 --> 00:34:51,560
descriptions. So this is a little proof of concept kind of thing that we're doing.

463
00:34:51,560 --> 00:34:57,340
And I had a really interesting use case this week for these package descriptions.

464
00:34:57,340 --> 00:35:02,260
I actually used our tool to generate a package description for a package

465
00:35:02,260 --> 00:35:06,980
called a ZuKeyKanaKanjiConverter.

466
00:35:07,940 --> 00:35:13,780
And this is a package, we'll have a link in the show notes that has a readme in Japanese.

467
00:35:13,780 --> 00:35:24,100
And because the GitHub page is in English and the readme is in Japanese, the Google's page,

468
00:35:24,100 --> 00:35:30,820
webpage translation or Safari's webpage translation doesn't work or it's not offered as an option.

469
00:35:31,460 --> 00:35:36,460
So I couldn't really tell what this package really does,

470
00:35:36,460 --> 00:35:39,340
and I wasn't sure if I might want to mention it.

471
00:35:39,340 --> 00:35:42,800
So I ran this tool on this package,

472
00:35:42,800 --> 00:35:45,540
and it actually gave me an English description

473
00:35:45,540 --> 00:35:46,740
of the package, what it does,

474
00:35:46,740 --> 00:35:48,700
and it does appear to make sense.

475
00:35:48,700 --> 00:35:51,860
So that's really nice,

476
00:35:51,860 --> 00:35:54,380
how these tools open up these things.

477
00:35:54,380 --> 00:35:56,460
Not only does it tell you what this page is about,

478
00:35:56,460 --> 00:35:58,220
at the same time, it gives you a short summary.

479
00:35:58,220 --> 00:36:01,220
So I think that's a really interesting use case

480
00:36:01,220 --> 00:36:04,980
these open AI or general in general and AI tools?

481
00:36:04,980 --> 00:36:13,620
Um, you may or may not know this, but, um, in the work that I did on the prompt for generating the

482
00:36:13,620 --> 00:36:19,940
summaries, um, I actually looked into also translating and there are lots of different

483
00:36:19,940 --> 00:36:28,420
options that you can kind of get out of, um, uh, of GPT with translating or not translating. You can,

484
00:36:28,420 --> 00:36:35,540
you can and it understands your wishes to summarize something and also translate it at the

485
00:36:35,540 --> 00:36:40,100
same time or summarize it and keep it in the same language and there's lots of different options.

486
00:36:40,100 --> 00:36:46,580
Especially with the translation, you're straying into stuff where

487
00:36:46,580 --> 00:36:53,300
potential hallucination could be quite dangerous because you might not know whether if it was

488
00:36:53,300 --> 00:36:57,380
translating something, you might not know whether that translation was accurate or not. But certainly

489
00:36:57,380 --> 00:37:03,940
in summaries it's often operating on a very good set of initial data. But certainly that

490
00:37:03,940 --> 00:37:08,100
translation, I think that actually made it into the prompt that we ended up using

491
00:37:08,100 --> 00:37:11,140
in the end that it should also translate it to English.

492
00:37:11,140 --> 00:37:16,980
Yeah. I recall, didn't you test it with a Chinese package or something when you wrote the prompt?

493
00:37:16,980 --> 00:37:23,780
Yes, we did with Chinese. I think we tested it with both Chinese and Japanese text.

494
00:37:24,420 --> 00:37:32,500
Nice. So yeah, that's so the the OpenAI wrapper, API wrapper is called Cleverbird and it's by BT Franklin.

495
00:37:32,500 --> 00:37:41,780
That's good. My second package today is called Stores and it's by Omar Albeek.

496
00:37:41,780 --> 00:37:51,780
And Stores is a key value store to store code of all types, but the destination of that store is

497
00:37:51,780 --> 00:38:00,580
is configurable. So with the same data layer, you can store your data in user defaults on the file

498
00:38:00,580 --> 00:38:08,020
system, into core data, into the keychain, and you've got the same interface to all of the

499
00:38:08,020 --> 00:38:15,300
storage no matter what ultimate destination you're using. Now, obviously we've got Swift data, which

500
00:38:15,300 --> 00:38:18,940
which is new this year and in beta at the moment.

501
00:38:18,940 --> 00:38:23,100
And from what I've seen so far, I really like Swift data.

502
00:38:23,100 --> 00:38:28,100
And I think it removes a lot of why I hesitated

503
00:38:28,100 --> 00:38:30,700
to always recommend core data,

504
00:38:30,700 --> 00:38:32,660
which is there's quite a lot of initial setup

505
00:38:32,660 --> 00:38:34,820
and you've got to think about,

506
00:38:34,820 --> 00:38:36,820
you've got to think about your storage quite carefully

507
00:38:36,820 --> 00:38:39,080
before you pick a core data.

508
00:38:39,080 --> 00:38:43,600
Where sometimes a plist file on a file system

509
00:38:43,600 --> 00:38:47,140
a JSON file and file system might do just as good a job,

510
00:38:47,140 --> 00:38:48,680
depending on what kind of data

511
00:38:48,680 --> 00:38:50,620
and how much data you're looking at.

512
00:38:50,620 --> 00:38:53,960
And what I quite liked about this package is that

513
00:38:53,960 --> 00:38:56,260
you can almost defer that decision.

514
00:38:56,260 --> 00:38:59,860
So with the same interface to the data store,

515
00:38:59,860 --> 00:39:03,480
you could start with file system store

516
00:39:03,480 --> 00:39:06,460
and then potentially move up to a core data store later.

517
00:39:06,460 --> 00:39:08,580
Of course you are tied in

518
00:39:08,580 --> 00:39:11,780
and with any data storage package,

519
00:39:11,780 --> 00:39:13,980
or in fact, any package that goes in

520
00:39:13,980 --> 00:39:16,140
at the root of your application,

521
00:39:16,140 --> 00:39:19,100
it's a much, what's the best way to say it?

522
00:39:19,100 --> 00:39:21,980
It's a much heavier dependency to take on

523
00:39:21,980 --> 00:39:24,060
than something that's right at the edges

524
00:39:24,060 --> 00:39:25,660
where you could easily replace it.

525
00:39:25,660 --> 00:39:28,300
Once you make a decision in your data store,

526
00:39:28,300 --> 00:39:30,060
you've gotta be really sure

527
00:39:30,060 --> 00:39:31,420
you wanna stick with that data store.

528
00:39:31,420 --> 00:39:32,860
- Yeah, that's load-bearing.

529
00:39:32,860 --> 00:39:34,220
(laughing)

530
00:39:34,220 --> 00:39:35,060
- It is load-bearing.

531
00:39:35,060 --> 00:39:37,260
That's exactly the way to describe it, yeah.

532
00:39:37,260 --> 00:39:39,620
But I quite like the idea of it,

533
00:39:39,620 --> 00:39:44,140
and it looks to be fairly mature.

534
00:39:44,140 --> 00:39:45,860
It's only been around for 11 months,

535
00:39:45,860 --> 00:39:50,140
but it's already had 12 releases, so that's a good sign.

536
00:39:50,140 --> 00:39:52,460
And it's well-documented.

537
00:39:52,460 --> 00:39:54,700
The documentation is hosted on the package index,

538
00:39:54,700 --> 00:39:57,700
which we know that always gives people a leg up

539
00:39:57,700 --> 00:39:59,540
into getting picked on this podcast.

540
00:39:59,540 --> 00:40:01,800
(laughing)

541
00:40:01,800 --> 00:40:05,320
So that's Storz.

542
00:40:05,320 --> 00:40:12,360
Right, my third pick is the Swift composable architecture package by Pointfree.

543
00:40:12,360 --> 00:40:19,000
And the reason I want to mention it this week, and I think because I think I mentioned it before,

544
00:40:19,000 --> 00:40:29,000
is that they've now made their 1.0 release. So I think that's certainly worth talking about

545
00:40:29,000 --> 00:40:33,880
briefly here. We should also mention that Pointfree are sponsors of Swift package index.

546
00:40:34,760 --> 00:40:40,600
But all their packages are open source and free so you know you can get a lot out of them.

547
00:40:40,600 --> 00:40:45,240
They really have great packages and they have excellent documentation so

548
00:40:45,240 --> 00:40:49,000
you don't need to subscribe to point free to make use of it.

549
00:40:49,000 --> 00:40:56,360
This is all available and really really high quality even before 1.0 release.

550
00:40:56,360 --> 00:41:03,240
I've been using the composable architecture for I think at least three years now.

551
00:41:03,240 --> 00:41:09,800
Now I'm not writing a whole lot of UI apps. I think I count like four small ones over the last

552
00:41:09,800 --> 00:41:17,240
four years, but they're all TCA based because I, once I learned how that works, it really resonated

553
00:41:17,240 --> 00:41:25,720
with me to the extent that I, I really feel like I can't write UI apps anymore. Well, actually I

554
00:41:25,720 --> 00:41:31,400
didn't, I never really felt comfortable writing UI apps before because of the way I tend to write

555
00:41:31,400 --> 00:41:33,960
code which is really test based.

556
00:41:33,960 --> 00:41:39,560
So I really like to test stuff and UI code is often really hard to test.

557
00:41:39,560 --> 00:41:45,800
And that's perhaps the strongest argument for TCA that I can think of, at least

558
00:41:45,800 --> 00:41:52,240
personally for me, is that it makes UI apps so testable and therefore manageable.

559
00:41:52,240 --> 00:41:58,160
Because the thing is you might bang out an app really quick without tests, but

560
00:41:58,360 --> 00:42:00,520
Where it really pays off is in the maintenance.

561
00:42:00,520 --> 00:42:05,320
If you have, you know, add more features, have more releases, the bigger your test

562
00:42:05,320 --> 00:42:10,520
suite, the easier that still stays and remains updating your dependencies, that

563
00:42:10,520 --> 00:42:16,560
sort of stuff, all that stuff really scales much better, is easier, more easily

564
00:42:16,560 --> 00:42:20,720
done if you have lots of tests and TCI really makes that possible.

565
00:42:20,720 --> 00:42:26,160
Um, they have this, um, unidirectional data flow where actions modify a state

566
00:42:26,200 --> 00:42:31,720
in a store and that's really the only way to modify your store and your views are really

567
00:42:31,720 --> 00:42:38,120
just displays of the store. And that concept really makes it for me like really natural

568
00:42:38,120 --> 00:42:44,140
and easy to work with UI because it then becomes less magical. I always struggle with UI apps

569
00:42:44,140 --> 00:42:51,380
because stuff seems to be happening magically. One change, little change over here in the

570
00:42:51,380 --> 00:42:54,740
would suddenly make things happen on another end.

571
00:42:54,740 --> 00:42:58,980
And I never really got quite comfortable with that.

572
00:42:58,980 --> 00:43:03,060
And TCA, I think is the thing that really made that click for me.

573
00:43:03,060 --> 00:43:08,100
That you can test all the logic in unit tests and then have snapshot tests,

574
00:43:08,100 --> 00:43:10,420
for instance, for your UI views.

575
00:43:10,420 --> 00:43:13,140
So, yeah, there you go.

576
00:43:13,140 --> 00:43:15,940
TCA, the composable architecture 1.0

577
00:43:16,660 --> 00:43:21,660
after a long time of being in pre-release by point three.

578
00:43:21,660 --> 00:43:23,500
- I think it's also worth mentioning

579
00:43:23,500 --> 00:43:26,340
with Composable Architecture that they've done a great job

580
00:43:26,340 --> 00:43:29,860
with obviously documenting it through their video series,

581
00:43:29,860 --> 00:43:32,540
of course, but also documenting it through

582
00:43:32,540 --> 00:43:33,900
actual documentation.

583
00:43:33,900 --> 00:43:37,620
And they've also put together one of those Doxy tutorials,

584
00:43:37,620 --> 00:43:39,700
which is an extensive,

585
00:43:39,700 --> 00:43:43,300
I think it's like a four hour potential length tutorial

586
00:43:43,300 --> 00:43:45,580
or something like that that I saw

587
00:43:45,580 --> 00:43:52,300
that, you know, putting together a tutorial like that takes time and effort. And it's great to see

588
00:43:52,300 --> 00:43:56,700
that kind of effort going into an open source package like this. Yeah, the other thing I really

589
00:43:56,700 --> 00:44:05,420
want to call out is, you might think, well, 1.0, I'm going to wait for 1.1. The way they've dealt

590
00:44:05,420 --> 00:44:11,740
with version changes, even leading up to 1.0, I don't recall a time when there was a breakage.

591
00:44:11,740 --> 00:44:21,020
They always had releases with deprecation warnings and then the most detailed adoption

592
00:44:21,020 --> 00:44:23,020
documentation.

593
00:44:23,020 --> 00:44:26,860
You're like, when you adopt the new version and you get deprecation warnings, you need

594
00:44:26,860 --> 00:44:28,540
to do this to fix those.

595
00:44:28,540 --> 00:44:32,940
Or, you know, if you jumped a few versions, you could see, all right, I need to do this

596
00:44:32,940 --> 00:44:39,660
and this to fix my compile errors because you skipped over the deprecation version,

597
00:44:39,660 --> 00:44:41,020
ended up on the new version.

598
00:44:41,020 --> 00:44:44,200
It's been, I've picked up apps that I'd written

599
00:44:44,200 --> 00:44:46,700
three years ago and went through,

600
00:44:46,700 --> 00:44:50,740
and it has always been really, really hassle-free

601
00:44:50,740 --> 00:44:54,840
to move along, and I'd say this is a safe library to adopt

602
00:44:54,840 --> 00:44:57,760
if you're concerned about breaking changes.

603
00:44:57,760 --> 00:45:00,240
It's really amazing the way they've dealt with this.

604
00:45:00,240 --> 00:45:02,580
- Although to use your phrase before,

605
00:45:02,580 --> 00:45:05,440
this is very much a load-bearing library.

606
00:45:05,440 --> 00:45:06,380
- It is, yes.

607
00:45:06,380 --> 00:45:09,480
You have to be, you have to buy into the concept.

608
00:45:09,480 --> 00:45:14,640
This is not something you'll pick up in one evening, I guess, unless you're

609
00:45:14,640 --> 00:45:19,920
perhaps comfortable or you know React Native, which is I think very similar.

610
00:45:19,920 --> 00:45:25,240
Or I think Elm also has this unidirectional data flow concept.

611
00:45:25,240 --> 00:45:28,160
It's certainly different.

612
00:45:28,160 --> 00:45:29,960
It's quite, and it is an architecture.

613
00:45:29,960 --> 00:45:33,440
It's like an honest architecture that you need to adopt in your app.

614
00:45:33,440 --> 00:45:37,920
It's not something you should do lightly.

615
00:45:38,320 --> 00:45:42,940
Having said that, I do believe it's something you can adopt partially.

616
00:45:42,940 --> 00:45:47,080
So, um, this might be something to look into.

617
00:45:47,080 --> 00:45:53,460
I do believe you can do this in, you know, in a, in a screen or two in your app and

618
00:45:53,460 --> 00:45:55,300
I see how it goes and take it from there.

619
00:45:55,300 --> 00:45:59,820
So you don't need to onboard your whole thing into this, but it's certainly easier

620
00:45:59,820 --> 00:46:05,540
to get to start out with this in a, in a new app or a smaller app to, to see how it

621
00:46:05,540 --> 00:46:10,840
goes and that goes to Dave's point that there's a really, really good tutorial and extensive

622
00:46:10,840 --> 00:46:16,560
tutorial. So there's lots of stuff there to get started with it and see if that's something

623
00:46:16,560 --> 00:46:17,800
for you.

624
00:46:17,800 --> 00:46:26,800
That's great. My last package is not this week a cleverly or amusingly named package,

625
00:46:26,800 --> 00:46:30,820
It is an amusing content to this package.

626
00:46:30,820 --> 00:46:36,320
The package is brand new, five days old,

627
00:46:36,320 --> 00:46:39,760
and it's called Swift NRC by Joe Hinkle.

628
00:46:39,760 --> 00:46:42,000
And I'm not entirely sure,

629
00:46:42,000 --> 00:46:44,600
I may be misrepresenting this package terribly

630
00:46:44,600 --> 00:46:49,740
in saying that it's kind of a music content,

631
00:46:49,740 --> 00:46:52,240
but it's the description of this package is,

632
00:46:52,240 --> 00:46:54,760
Swift objects without reference counting.

633
00:46:54,760 --> 00:46:56,720
Do you ever wish you could go back

634
00:46:56,720 --> 00:46:59,320
to manual memory management and Swift

635
00:46:59,320 --> 00:47:02,300
is the kind of language that just does not let you do that?

636
00:47:02,300 --> 00:47:07,080
Well, Swift NRC is here to help.

637
00:47:07,080 --> 00:47:12,080
It's effectively a package with a macro inside it,

638
00:47:12,080 --> 00:47:19,000
which allows you to use the unsafe pointers of Swift

639
00:47:19,900 --> 00:47:24,300
in a slightly more,

640
00:47:24,300 --> 00:47:28,140
is they wrap up the unsafe pointers

641
00:47:28,140 --> 00:47:31,280
to allow you to do your own memory management.

642
00:47:31,280 --> 00:47:33,660
I don't think you should use this package.

643
00:47:33,660 --> 00:47:35,900
I think this package demonstrates

644
00:47:35,900 --> 00:47:37,820
some interesting things with macros.

645
00:47:37,820 --> 00:47:39,080
I don't think we should go back

646
00:47:39,080 --> 00:47:40,580
to manual memory management,

647
00:47:40,580 --> 00:47:42,820
although there are potentially uses

648
00:47:42,820 --> 00:47:45,020
that may be performance or something like that.

649
00:47:45,020 --> 00:47:48,780
Although even then, I'd be really surprised

650
00:47:48,780 --> 00:47:53,780
if going back to pre-arc days was ever a good idea.

651
00:47:53,780 --> 00:47:55,980
But I did, it did make me smile.

652
00:47:55,980 --> 00:47:58,480
It did make me, it's an interesting little package

653
00:47:58,480 --> 00:48:00,840
and I thought it was worth a mention.

654
00:48:00,840 --> 00:48:01,680
- Very nice.

655
00:48:01,680 --> 00:48:03,880
- But please don't use it.

656
00:48:03,880 --> 00:48:07,720
Right, and with that, I think we should call it,

657
00:48:07,720 --> 00:48:12,000
and we will be back in two weeks

658
00:48:12,000 --> 00:48:14,920
with more package recommendations

659
00:48:14,920 --> 00:48:17,820
and potentially an update on dependencies

660
00:48:17,820 --> 00:48:23,660
potentially a fixed version of our use this package popover. Great, see you in two weeks.

661
00:48:23,660 --> 00:48:29,420
So until then I will see you in a couple of weeks. Bye bye. Bye.