Swift Package Indexing

So I got an email this morning from Google and I'm not sure whether you get it actually Sven,

but we get an email every month from Google saying, "Here is your performance on Google Search."

The Search, yeah.

Yeah, this month we hit 22,000 clicks through from search terms on Google through to the site

and we were shown in Google Search results almost 850,000 times. And I like these emails,

they're kind of, they're a nice kind of every month you just see whether you've grown a little

little bit more on the ground a little bit more.

But one thing I spotted this week,

which I don't think I'd seen before,

is there's a section in that email

that says your top growing pages.

- Right.

- And there were a couple of interesting ones in there

this time that I thought were worth pointing out.

So the top growing page this month is a package page

for a package called SwiftUI Shimmer,

which I think, if I remember rightly,

I linked to in iOS Dev Weekly when it first came out.

- Does it?

- But it's our top growing page in this month,

which I was quite surprised about.

It's a decent control, it's a SwiftUI view that shows,

do you remember the old slide to unlock?

- Yes, yeah.

- Text on the home screen.

And it used to have a little white shimmer that,

so it basically does that for any text in SwiftUI.

So that is our top growing package this month,

which I thought was interesting.

interesting. But our second top-growing

package or top-growing link that people

land on when they have searched through

Google was a documentation page. Oh wow.

So it's the documentation for

GRDB query. Right, yeah. And it's one very

specific page in that documentation. It's

an article actually. It's an article

called MVVM and Dependency Injection.

And it's a relatively long article

that's in the documentation on the GRDB query documentation

set.

And that is our second top growing link

from Google Search this month, which

I was quite surprised about.

Well, that is a super click-baity title, isn't it?

MVVM and Dependency Injection.

That's like catnip for any developer,

or any developer in all languages.

That's true.

That's true, yeah.

[laughs]

Oh, that's great.

And then just to round out the trio, because there were three links in this report, the

third top growing link this month was to the MQTT NIO package, which is the event-driven

Swift client for MQTT.

If I'm not mistaken, that's the protocol underlying Rabbit MQ, which is a messaging queue.

Is it?

Yeah, I think so.

used to play around with that ages ago.

In very early Swift days, I sort of,

I think I wrote a little wrapper around one C library

that deals with that.

- Interesting.

Is there any indication why that first package,

for instance, you mentioned, is picking up?

Is there a search term associated with it

that has sort of picked it up?

- Not that I could see,

certainly not in the report that Google sends me.

We could potentially dig in through the search console

to see something like that.

But, but no, there was nothing, nothing obvious.

What I will just do though, is give a quick shout out to the

three authors of those pages.

So SwiftUI Shimmer is Vikram Kriplaini.

GRDB Query is Gwendolyn Roo.

And the NQTT NIO is Stephen Robert.

Nice.

Just to give them the credit that they deserve.

And so then from there, I looked into our Google search results,

just our analytics package.

So we use a package called plausible for analytics on the Swift package index.

It is a privacy focused analytics package that doesn't tell us anything about who you are.

It doesn't even have a cookie.

So it has, it is a cookie-less analytics platform that just records statistics on how many people visit which pages on the site.

And our top search terms there have a couple of really

interesting items in them this month.

So again, looking only at the last 30 days, you've got all of the obvious ones.

Like obviously our most popular search term is Swift package index and

Swift packages and things like that.

And then you've got all the search terms that you would associate with popular

packages, like Alamofire, SwiftLint and IQ Keyboard Manager has all consistently

been in our, in our top searched packages.

But there's a new entry this month, which is we are starting to get some traffic from the search term OpenAI Swift.

Oh, yes, I saw that.

I usually check out the Google search stuff as well.

And I did notice that that search term started appearing first in December with all the OpenAI stuff.

Right. Yeah.

So if you look at the history, it tracks your ranking to that search term, and it only started appearing in December.

And I found that really interesting.

Yeah, it's always interesting to see which bits of, you know, which packages within the index are

getting traffic and if there are trends around that as well.

Yeah, I usually look at that a bit as well, not in too much detail.

And just to recap on that, on one of those first numbers, getting on for a million impressions

of our site on for people on Google within just this last month, which is kind of crazy.

Yeah, I always wonder how that's come because that doesn't really line up with the page views

that we see implausible, right?

No, that means that people are seeing a link to our site and not clicking it.

It's not the best statistic, I'll give you that.

This is the top of the funnel, right?

That's right. It is. It is literally at the top of the funnel.

Right. Since we're talking about news, there's a couple of things we could talk about with

respect to the project implementation. So one change we made over the last two weeks

was adding support for documentation builds on Linux. That's actually been requested for a while.

I think it issue was first opened in December. And the two first packages that actually wanted

to have support for that were Benchmark and Frostflake by Joachim Hassila. And that was

was one of those tasks that seemed pretty straightforward to implement.

Actually, when you run this package build documentation generation on Linux, that

works fine out of the box. And it did work pretty much instantly on first

attempt when I added it to our builder. But then everything sort of stopped and

I soon arrived at these existential questions. Well, what can I actually do?

are there other skills that I can market?

Is this my profession?

Because I couldn't actually ship the doc set that was created to our uploader

because it ended up in a nested directory

and I could not for the life of me figure out why that was.

And it turned out that cp-r, so the unix copy-r

which we were using to stage the documentation sets

because we have to do a couple of things differently from building them normally

because if you have multiple targets,

if you rebuild documentation with a different target,

that actually wipes the previously generated docs.

So what we need to do is we need to copy them to a staging area

and then for each target, copy them to that staging area over each other

and then also merge a JSON file that tracks all the targets.

But for some reason, the nesting was wrong on Linux

And it turned out the reason was that CP-R behaves differently between Mac OS and Linux.

And that's kind of weird because you'd think a common command like that wouldn't actually show that.

And it wasn't even consistent.

That's the thing. I stopped trying to figure this out because by that point,

I was so deep down the rabbit hole, there was no light to be seen.

And I thought, right, I just I know how to fix it.

I'm not even going to try and figure out why that is.

I actually arrived at the point where if I ran the command back to back on Linux, the

second time it copied it the way I expected.

What?

It's like, I'm not, I tried this multiple times, but I had to stop because I thought

I'm going nuts here.

That's so odd.

Anyway, it's all working now.

I actually, I brought this up now.

I regret that I brought it up because I just get reminded of how crazy that was.

So let's talk about that side of it.

I think the interesting bit there is why people might want to do a doc build on Linux because

it is, you're right, it's a feature that people have been asking for and there's a couple

of reasons you might want to do it.

If you don't need any Apple platform specific frameworks, then it's likely that your package

is going to compile on Linux.

Obviously there are intricacies that might go wrong on a Linux build, but generally if

If you don't need the Apple platform frameworks, then you're in good shape for Linux.

And if there's anything that you're doing Linux specific, you might only have Linux compatibility.

And suddenly we can't generate docs for you.

And that's actually the case for these packages.

So Benchmark, I know for a fact is Linux only, and I presume Frostflake as well.

And Benchmark is Linux only because it actually needs a platform dependency.

I think it's called JMalloc, so it uses a custom malloc,

which actually needs, we had to actually provide,

extend our builders dependencies for the Linux builder

to make that work.

You can also, I mean, it can run on macOS as well

because you can install it via brew,

but our machines don't have that installed.

So in the compatibility matrix,

the package currently actually as it stands

doesn't compile on macOS,

and it's actually easier to prepare

the whole machinery on Linux because it's easier to manage the dependencies there.

I bet there are not a very large number of packages that are Linux only in our index.

I'd be interested to know how many of those there are.

Well, maybe there might be a quiz about that next time.

If I remember.

Yeah, I think that would be an interesting stat.

And the other thing we gained since last time was Doxy build flag on the build details page.

So what that does, it shows you on the build details page, which is the page where we list

all the builds for a package, you know, per Swift version and Swift platform.

So it's a big matrix of all the builds.

It's the click through from the smaller compatibility matrix on the package page.

And because we only build the doc set for the latest Swift version and the platform

you choose, or Mac OS SPM if you don't choose, that's the default, we have a little icon

next to the actual build that is responsible for generating the docs.

So that if there's anything wrong with your docs and you want to check the logs, that's

the place to go and check out the build with a little icon next to it and see if there's

something obvious going wrong.

was a feature that both you and I didn't really need it because we know the logic

as to which build generates documentation, but to a package author it

was completely opaque where the documentation build was actually

happening and so that was that was causing people not huge headaches but

but it was causing people problems of not really understanding how we were

doing the documentation build and now as soon as you go into that page you see

the little icon and you can just say okay if you hover over it I think I

believe there's a tool tip that says this build generated documentation or

something like that and you can then click in and see the build go and then

the documentation and if anything went wrong you can see the logs from that

build. Exactly. And actually so the little bit of trivia on the GitHub project

there we had a project you know the GitHub projects like Kanban board type

thing. We had a GitHub project for documentation generation support. That

was the last ticket in that project and it's been the last ticket in that

project for many months and so it was nice to finally close that project off.

Nice. I hadn't actually seen that project board in a while. Yes, it was the only

one and I closed it as we closed that ticket. Nice. Well and the final thing we

could maybe briefly mention is that was quite interesting also there was a

a search issue around syntax. So if you search for syntax, one of the packages you most likely

are going to be interested in is Apple Swift syntax, right? I mean, that sort of sounds

like a common thing to look for. And that was ranking unexpectedly low. So it only showed

up on the second page. The reason that happened was that syntax by itself wasn't actually

mentioned anywhere in the package description or the package name.

Anywhere where we looked it wasn't by itself.

It was always in the Pascal case Swift syntax.

And the problem with that was we use Postgres' word stemming to find word boundaries.

But the problem is Postgres is sort of case insensitive.

It doesn't actually generate two words out of that.

It doesn't see the word boundary in Swift syntax.

So it was blind to syntax actually appearing in that phrase and there's no easy way to

teach it to do that.

There are ways to do it, but they aren't actually easily doable for us with our hosted Postgres.

There was luckily the package name, not the package name, the repository name is actually

Swift dash syntax.

So and that was an oversight.

We didn't actually index or rank on the repository name itself.

So that actually saved us in that case.

We were able to then extend our word stemming,

made that part of the Postgres word stemming thing,

and then it could break these two apart

by taking out the dash

and recognizing Swift and Syntax separately,

and that fixed the ranking.

But it was really, that's a chance.

If Apple had named that repository Swift Syntax

camel case as well,

actually wouldn't have been anything we could have done on our end to fix the ranking easily.

So maybe package authors something to bear in mind if you use camel casing in your descriptions

and stuff. Maybe also if these are important individually and you can already see that

they aren't appearing individually, maybe stick them in a keyword or something. You

know, like if syntax was a keyword, we would have picked it up or just, you know, as a

a single word in the description, that's always a good thing to maybe have duplication there

with a couple of different spellings to make sure that it can be picked up.

And I think the other thing to mention here for package authors is that your package name

does not need to be the same as your repository name.

Yes.

And you can be a little more, descriptive is the wrong word, but you don't have to use

so many hyphens and things like that in your package name because that's a different field,

it's just a string, whereas a lot of people use the same naming for their repository name

and their package name, but we do show the package name, we do search on the package

name, and so it's worth mentioning that.

And in fact, that topic comes up in one of my package recommendations today, so stay

tuned for that.

Right.

Well, that's a segue.

Maybe we should start there.

You want to kick us off then?

Yeah, absolutely.

So I actually bookmarked this a week or so ago.

And I bookmarked it partially because it sounded interesting

and partially because the package name

and the repository name were an interesting thing

to talk about.

So the package is called P-U-I-D,

which stands for Probably Unique Identifiers,

which I really like.

I love the name.

And it's by an organization or I don't know the,

well, I guess I do know the name

because we exposed the author.

It's written by Paul Rogers

And it's in an open source organization called PUID.

And at the time that I bookmarked it, the PUID organization had seven or eight

different implementations of PUID in different languages and each repository

didn't even include the word PUID.

It was just the name of the language.

So the repository for P U I D and Swift was P U I D as the organization slash

Swift, and then there was P U I D Dart, P U I D Ruby.

And I thought that was a bold choice because to not have the name of the name

of your package at all in the repository name, only the language, I thought maybe

this is going to struggle a little bit.

Since bookmarking it, when I came to open up my bookmarks today,

It has been moved and it is now called Swift P U I D as in the repository.

So it looks like the author of that realized the problem, realized,

because it's obviously not unique to the Swift package index, this is

going to be an issue everywhere.

But, um, they renamed all of their repositories and it's back in the.

Uh, so the package name is still just P U I D.

Uh, but now the repository also has Swift P U I D in it as well.

So it basically is a little bit like UUIDs,

but it gives you lots of different options

on how to generate probably

or potentially unique identifiers.

- Yeah, and actually that is one of my picks as well.

And I actually noticed the exact same thing

when it first showed up.

And even I bookmarked it as well, like early,

I think it was released or added

right after we recorded last time.

And it was still, my bookmark was also still a Swift.

and I noticed like when I came back to it while preparing, I noticed that it had changed,

but I luckily remembered that I saw the name change, so I wasn't confused,

because I ended up on the 404 and I thought, well, I'm sure when I added this, it was there.

Yes, exactly.

But yeah, it is an interesting package and I actually played around with it a bit

and I found it really interesting.

So a couple of aspects that are interesting about it beyond UUIDs,

which give you a fixed 128-bit random identifier.

You can choose your total number of bits that you want,

but what you can also do is,

and all of this works in a playground,

so you can use our Triana Playground feature

to pull down the package and play around with it.

It's quite interesting and instructive.

You can also choose your total number of IDs you need

and the collision risk you're willing to deal with.

and then it'll pick a length of the ID it generates to match those requirements.

So for instance, if you want to generate 100K IDs

with a collision risk of one in a trillion, 1 to 10 to the 12th,

it generates 15 characters.

And if you instead want to generate 10 billion IDs with that same risk,

it'll be 22 characters.

That just takes account of the if you generate lots more,

obviously you need more characters to have the same low risk of collisions.

And then it is very configurable, so you can choose from a wide range of representations

like alpha, alphanumeric, hex, even your custom character sets that are used to map the randomly

generated entities to characters and as a representation.

Right, yeah.

Yeah, really nice package.

The author also throws some shade on UUIDs in the readme file.

I did not see that.

I'm going to read a sentence from there.

There is simply no such thing as a universally unique ID, regardless of the UUID moniker.

Rather than blindly use a one-size-fits-non solution, PUID allows full control so that

WISC can be explicitly declared as appropriate for specific application need.

Oh, shots fired, UUID.

Yes, absolutely.

Yeah, I think with all that said about the package, I think it bears repeating with kind

of security related packages like these or this one in your dependencies, make sure you

review in detail how it's actually implemented and do some testing, I suppose.

It looks really well done.

It has documentation and everything, supports lots of platforms and talks about lots of

things within our authority that gives you the sense that this is

very solid but do double check. Documentation hosted on the Swift

package index as well. That's always how they get us isn't it? All right so if I

stole your first one what are you going to replace it with? I'm going to

replace that with a package called Mac Control Center UI. Oh well so now we're

even because you just stole one of mine. Okay we're both be scrambling this week

and this is by Stefan Andrews.

And I actually had news for that package last week

because I was building a little menu extra app as a personal tool

and I came across the limitation that if you have a menu extra,

so menu extras can have two menu styles.

One is the menu style and the other one is the window style.

And when you do that, so the menu style renders buttons

like normal SwiftUI buttons like normal window buttons and you can also have text that are just

menu items that only show the text but aren't active. But those are the two options you have

really. If you throw a custom view in your menu bar builder that actually doesn't get rendered

in that menu style. What I had was both menu items and a custom view so I wanted to have a Swift

chart in the menu item. You can do that with a window style, but then buttons render like

buttons in the in the menu bar, which looks odd, right? It's a button instead of a menu item.

So right, if you actually want to have proper menu items, you effectively need to build them

on your own, you know, to rebuild they look like and that package does that for you.

Although it does it in the control center style. So that's slightly different, I guess,

from a normal menu style but it is quite suited for a menu extra. So I found that really nice

and it gave me a very easy drop-in replacement for the thing I wanted to do, have this mix

of regular menu items and then you know richer UI elements like my Swift chart in there.

So that's a really nice package. It has a nice example so if you look at the page you

see what it looks like and it does more than just have you know what I just

described menu items that you can throw in it has actually it replicates the

elements you see in the normal control center you know like you have these

round buttons where you can choose between options like if you look at your

control center can for instance pick between your networks or have sliders

like your sound level and your brightness and that slide is replicated.

So I have these controls in addition to just regular menu items and the ability to throw

any views in there.

And it looks like the normal control center, I wouldn't be able to spot a difference between

the two.

So it looks like a really nice and complete package.

This continues a long tradition of Apple introducing a slightly different style of UI somewhere

in Mac OS and then the community going down and copying it.

And the first time I remember that happening was back in the interface builder three days,

the Xcode, Xcode 3, interface builder 3, which is when I first started writing Objective-C

code.

And at the time, the Cocoa controls were all light mode.

And of course, everything in Mac OS was light mode until just a few years ago.

there was a set of dark mode controls that Apple had for the little panels that were dark.

So for...

Ah, right. Yeah.

Yeah. And they were, they weren't used all over the place.

Yeah.

And Coco at the time could open up a dark panel, but you couldn't, if you put any controls in them,

they would look awful on there because they were only light controls. And so there was a framework

and Interface Builder 3 plugin, which is something that I'm not going to explain,

but Google Interface Builder plugins if you want to go down that rabbit hole.

So it was, in fact, the website is still up and around. We'll put it in the show notes.

So the person who wrote it was Brandon Wolkin, and still on Brandon's site under the path BW Toolkit

is the website for BW Toolkit, which is a set of Cocoa controls that fit

perfectly in those dark panels.

And I remember using that in my very first Mac app that I wrote way back in.

2006, maybe 2005, 2006.

And so thank you, Brandon, for that.

And this, I, this reminded me of that because it's, you know, Apple have

done something a little bit custom.

People like it.

Everyone wants to use it and here's the package that lets it happen.

Unfortunately, these days you don't get the interface builder plugin.

Or actually, should I say, thankfully, you don't get the interface builder plugin.

Yeah, that's all Swift previews, right?

They were troublesome.

Okay, so yeah, my next one is a double one.

And it's a couple of packages that have both had releases in the last day or two.

And they are both related to what we talked about in the Google search results thing.

One of them is called GPT Swift by Dennis Muller.

And the other one is called OpenAI Kit by a company called Futura Group.

And they're both basically API clients for the OpenAPI.

OpenAI, ChatGPT API. That's a very difficult phrase to say. OpenAI, ChatGPT API.

I say that five times fast. So yeah, the reason I'm kind of, so obviously ChatGPT and the OpenAI

APIs that they've recently released are everywhere at the moment. And just this last weekend, I was

was down in London and a friend of mine is working on,

and it's the first time I've actually seen anyone

really embed the API proper into an application.

They're building a web application for,

well, it's an already existing product,

it's called Readily, and they're using the OpenAI API

to do a couple of really interesting things.

The most interesting, I think, is they are relating,

So when you search on this site, you obviously got your search term that you entered, and

then you've got all the search terms in the database, all the metadata about the items

that you're searching for.

And he's using the OpenAI API to generate hints as to why the search term that you entered

matched the results that came back.

So you're searching for books, basically, and if you search for murder mystery, and

it brings back some books, and some of those books might say, "Matched because it's a mystery

set in Sweden," or something like that.

And so it's generating text to relate those two things together, and I thought that was

such a clever use of an AI like this, not something I've seen used before.

And so when I saw the GPT Swift and the OpenAI kit packages fly by, I instantly looked at

them because it's quite different using the API for OpenAI than it is to use just the

chat interface.

And you build up these prompts that can be quite a lot larger than I expected them to

be.

that he was showing us at the weekend

were, I don't know, hundreds? 500, 600, 700

words of prompt. Oh wow, okay. Really

interesting. Yes, it's much

deeper than I first thought it was.

Interesting. Have you used chatGBT for

anything? Not anything. I've played with

it. I tried to get it to write a couple of

emails, but I ended up editing them so much that they were...it actually took me

longer just to...I should have just written them. I also just...last week I got access to

the Bing AI search beta, which I've been playing with a little bit, and it's

better than I expected. I think Microsoft are making a little bit of a misstep

with it because I think they have an opportunity here to really make a

splash with this because it is quite good

and the problem is that it forces you

to use Microsoft Edge as your browser to

interact with it. So even though it's

just a web page, they're taking it as

a Microsoft Edge marketing

opportunity, which you know there's pros

and cons of that for them, but it did put

me off a little bit. But I have

played with it and it's better than I

expected. It's very, it's quite

different to chat GPT because it has

live access to the internet and so you'll

ask it a question and it will do one or

more web searches behind the scenes and

it will tell you that it's doing web

searches and then it will take the

results of those web searches and feed

that along with your prompt into the

API and bring back a generated response.

response. Right. I haven't actually done, you know, played with any of these. And I

think the main reason is, I mean, I find this super impressive, all the examples I see,

but it's also super scary that it just makes up stuff. And I'm not sure how common a problem

that is, but just the fact that it does happen for me taints the whole concept. As impressive

as it is that it can see these things, how would you ever be able to trust that the thing

you'd got just now, where it maybe isn't obvious to you that it just made this stuff up? You

know, because sometimes it might be obvious because you you would know the domain, but

if you don't, how do you trust that? How do you rely on the results that you're getting?

That's the thing I struggle with most with these.

I also struggle with that. But actually, one of the things that Bing is doing is quite

interesting in that it, let's say you ask it a question and it comes back with two or three

options as potential results for your query. It will also cite the sites that it got the information

from underneath its response. And so you can click through and find the webpage that the answer that

was generated got its, you know, where it got its data from, which I think is a really good move for

a little bit of transparency on this because you're right that this is the biggest problem

with it.

The other thing I think that's worth just, I don't know, this is not a AI ChatGPT podcast,

but now we're talking about it.

The other thing that I think is really important is to pick the right use for this.

So ChatGPT is literally a general purpose AI, and I think it's a bit early for that.

very impressive and it makes amazing

demos and you can have a lot of fun playing

with the chat GPT chatbot. But I think my

friend's example of using it for very

specifically relating why did this search

term map to this search result, which

actually if it gets it wrong, not the

end of the world. I think that's a great

use. I think that's exactly key, right,

that you pick a low-risk environment

where small or even bigger mistakes

aren't that critical. Yeah. None of us even

knew this existed, let's say, six months to a

year ago. And for it to have come this far,

this quickly, I think the chances of this

fading away into nothing, I think, are

very, very slim at this point. Yeah. But

we are absolutely on the precipice of

of an enormous, I think it's potentially a revolution,

because I think this is going to be quite a significant

step forward, not just chatGBT,

but if you look at all of these generative APIs

that we've seen in the last year, image generation,

text generation, code generation, music generation,

and that kind of stuff, it feels like there's a wave

of this stuff coming.

- Yeah, for better or for worse.

I mean, I'm... - For better or for worse, yes.

- I mean, the other thing I get the sense,

not having played with any of it,

but I get the sense that a lot of the impressive examples

are also cherry-picked, right?

You mentioned just now that you let it write

a couple of emails and ended up editing, you know,

if enough people run this enough times,

you know, it'll produce impressive results

every once in a while, maybe even a lot,

but the question is how often is it just not great?

And the thing, especially with the code generation, is I enjoy writing code much more than reading it.

If someone took away the writing part and all I had to do was be a pull request reviewer, that would be terrible.

I'd never actually want to be in that role.

So I'm not sure that aspect of it is all that beneficial.

I am really torn, actually. I am tremendously excited about it on one hand,

and the old man in me is very fearful and resistant to change on the other hand.

I think the the co-pilot one, we should move on from this topic, but just to add one last thing,

which I've written about a couple of times in iOS Dev Weekly, the co-pilot issue for me is the

training data that they used for the GitHub co-pilots included GPL license code. And we know

that because there was a point at which it would spit out a GPL comment if you started to write

one and I think GitHub have swept that under the carpet a little bit knowing

that it will eventually one way or another it will come down to a court

case and a court will make a decision. I don't want any part of code that is

potentially in that situation in anything I write so I have not used

Copilot I will not use Copilot for that reason specifically but the the text

generation, the image generation, music

generation, I think are a little bit

because I'm only playing around with them

I don't have that fear so much with those.

Well they have that same issue. There's

actually a lawsuit I think shut us stock

yeah because in they they saw it

generated images that even had the the it's

yeah Getty the watermark still on it

Getty that with that is it you know

and it was clearly trained on yes

on copyrighted material and you know

obviously artists, they're still able to get copied.

I mean, that's--

- Thousands, millions, billions of hours of human effort.

Let's not try and solve that problem today, though.

(laughing)

- Exactly.

Well, I mean, we're both a package short

because we snapped each other's packages,

so we filled that with chat.

- I think that may be the deepest scrabbit hole

we've been down on this podcast.

Right, my second and I guess final pick is not new.

I don't even think it had a release recently,

but it came up in a little thread on Mastodon this last week

and it's called "Periphery" by Ian Leitch.

I'm not quite sure.

I think Leitch, yeah.

Leitch, yeah.

And the question was whether it is possible

to detect unused imports in Swift code.

And I immediately thought, well,

if there's a tool that can do it, it has to be periphery.

And I checked and unfortunately it can't do that.

And to my knowledge,

there doesn't exist a tool that actually does do that.

But that sort of reminded me that periphery is there.

And that is actually a great tool

to deal with other things that you might have in your code.

It detects these kind of staleness issues

where you remove something

and then you don't remove other parts of it

because they're not,

these are things that the compiler can't check for you,

but periphery can.

And these are cases like unused functions

or unused properties,

something that you might have declared public

because at some point you used it across modules,

but you aren't anymore.

These are just examples, it checks a whole lot of things.

And these aren't things that the compiler

will tell you about, right?

There's nothing in the compiler that'll tell you,

well, this function that you used to use,

but you removed the only use of that.

And now that is effectively, you know,

code that you're lugging around and possibly maintaining,

but actually not actually using.

And Periphery can go through that and actually see that,

and it gives you warnings and a nice report.

You can even have it click through,

like if you have a client that supports these links from the terminal,

it actually sends you to the proper line in the source file to fix it.

You can run that manually, obviously, you can even add that as an automation to your CI workflow

to have like, you know, as a warning or even an error if you have issues.

And it does have support for annotations to opt out.

So if you have some things that you know you do actually need,

but you don't want to be warned about it every time you can just put a little annotation in a comment

to tell it to ignore that sort of area of the code.

So I think that's a really nice complement to all the stuff that the compiler does for you,

like type safety and all that.

And this is really nice to cover that aspect of your code tidiness and health to check for these kinds of things.

That's Periphery by Ian Leitch.

Yeah, it's a great package and it's like you say, it's been around for quite a long time now.

I think it was originally, in fact I know it was originally a commercial product that was then turned into an open source tool.

Ah, okay. I did not know that.

Yeah, but it's been open source for quite a long time now and yeah, thoroughly recommended from me too.

Excellent.

All right, I think that's it for this week, isn't it?

I think, yes, our OpenAI discussion took all the time and we're actually running a little

over our normal episode length, I think, so apologies for the slightly extended edition

today.

We will be back in a couple of weeks with more news and more package recommendations,

and I will speak to you then, Sven.

Yeah, see you in two weeks.

Bye-bye.