Swift Package Indexing

Well, I think we do have a bit of news. We spoke about maybe not having that much,

but there was a package that landed last week, I think.

Yes, you wrote about it in IOS Dev Weekly as well.

And that is Swift Win 32 by Salim Abdul Rasool.

Yeah, I thought I'd maybe pull this forward into the news section,

not just as a package towards the end.

I think that's a great idea to talk about that.

Yeah, I got good feedback on that opening comment,

actually, this week, so yeah.

Yeah, I really like that.

And just to mention Salim Abdullah,

who is also known as CompNerd.

That's actually what I map his persona to

on the Swift forums and everywhere.

So he's the, I think, the maintainer of Swift on Windows

and also the person who brought that into existence,

I believe.

Yeah.

And so he submitted, or someone submitted, I'm not sure what the order of events was,

but we have it in the index now, Swift Win 32, a Windows application framework in Swift.

Unsurprisingly the compatibility matrix is all crosses because we only test on macOS,

Mac OS, iOS and so on, the Apple platforms and Linux.

So that's not a big surprise,

but that sort of brings or mounts the pressure a bit

what our strategy is with respect to the next platform,

I suppose.

I mean, Windows has always been one of the leading candidates

and we've obviously talked about this before

and tossed around the ideas,

the idea to add it and when will we add it, how will we add it actually, because I've been thinking about this a bit

and it's a bit of a departure because with Mac OS and Linux

we have the option to run this pretty much ourselves, I mean just speaking for myself, I have no

real access to a Windows machine where we could even experiment with building Swift packages on it.

So it'd have to be either cloud-based or I'd have to get a Windows laptop or some kind of Windows machine.

So that's sort of been an impediment to experimenting further with this.

And in that same vein, there's another package that I saw just last week that mentioned one of the platforms that we're not supporting yet,

that is WOSM. So there's an explicit mention, I believe it was a point free

core package. And there it was just mentioned as an additional platform that

they support. So which is different because the Win32 platform is actually

one that is Windows only, right? So this is a package that is specifically for

Windows. I'm sure we have other packages that will be compatible with Windows

once we start testing. But you know, that's just because they happen to also

work on Windows while this one certainly requires Windows.

I think it's a great idea and we've talked about it several times but I think

I think the time is is arriving for us to think seriously about adding Windows

compatibility and you mentioned the Win32 package I think it was actually me

that added that package on Thursday or Friday last week because I was I was

doing a bit of research for that article I wrote on iOS Dev Weekly and ended up

poking around in Selim's GitHub list, repository list, and I found that one.

I think the WinRT one had already been added, but the Win32 one hadn't, or I may

have got those the wrong way around.

We had one, but we didn't have the other.

But it's great to see that kind of work happening.

And I think Selim deserves all the credit in the world for not only doing the work

that he's done to bring SWIFT to windows, but also for having the momentum and the force

of will to get it done, because it was probably not the—well, it was certainly not the easiest

task in the world, I'm sure, but it was also probably not the most obvious thing to do

as an independent person outside of the SWIFT project.

So I think he deserves a huge amount of credit for that.

Yeah, and he's been doing this for a long, long time, right?

I mean, I don't even remember when he started adding Windows support.

And initially, I believe it wasn't even in Swift itself.

So there was a lot of absorbing upstream changes into his branch or fork of it, I believe.

But I think that a lot of that has changed in the meantime.

So yeah, there's a little for people watching what's going on.

If you want a spoiler for iOS Dev Weekly, check out what stuff gets added to the package index on Thursdays,

because that's when Dave spoils his newsletter.

Pretty much. It's quite a common thing that I'll find something on a Thursday

that I want to add to the index.

Yeah, so I was thinking a bit about our next platform and May is probably not a great time

to actually add a new platform because, you know, in June there might be something new happening.

so we always have to be careful what we take on because adding a new platform isn't just a one-off thing,

it then becomes an ongoing concern, you know, like maintenance.

In particular a platform like Windows, which we'd have to, well that's something to discuss,

but likely something that we'd have to maintain, right?

We'd have to maintain Windows machines.

Perhaps there's an alternative way to actually do it, which I want to maybe briefly talk about.

and that's one I have high hopes for because it would solve a lot of the effort that we would have to bring and put in otherwise.

And that's Swift's cross-compilation support.

There's an evolution proposal out by Max Desiatov right now.

Well, actually, I think it might have been approved by now, and that's about cross-compilation destinations.

I think that's just the first step in a range of proposals to be coming to give Swift the capability,

you know, across compilation capabilities.

And having that would save us a lot of trouble because maintaining Windows machines for the Windows testing,

I mean, it's possible, but then we'd have yet a third, yet another, you know, platform in the mix that we'd need to maintain, update,

and also set up the build environment for.

Whereas if we could rely on cross compilation,

that would be really great because

we'd probably still want to choose either Mac OS and Linux

as a single one that does everything then,

but we'd at least have that choice

to run the compiles on a single platform.

All the runners being the same

would give us a lot of advantages.

you know, we just we have an easier time managing our capacity because it's all the same.

We could just add machines and every machine can build everything.

That's that's really nice.

So that would be great.

But I just I don't have a sense for how far off that is and in particular how how long it'll take for that to be

something we could truly rely on.

I mean, we do effectively do cross compilation already, right?

Because we're using Macs to compile iOS, tvOS, watchOS.

So it's nothing new.

But that doesn't automatically mean it'll be perfect for Linux

and all the other platforms that are less common as those Apple platforms.

The other big question I have with this is,

how will it cope with things like, so for example, that Win32 package,

has presumably bindings into the Windows APIs.

Yes.

And how does it, if it can, can it even cope with something like that?

I would, I think that's a question we'll need to answer fairly early because, and again,

we'd have the same questions with the Mac side of things, right?

Yes.

So I think there are some questions that need answering there.

There is actually another option on how we could approach this, which is again, something

that came from an article I linked to in IOS Dev Weekly this week, which was, it was a

post on continuous integration at Airbnb from Michael Backhand and Xiaomeng Chen.

And they were talking about, I don't know whether you spotted the article, but they

were talking about an enormous kind of redesign of their continuous integration environment

at Airbnb and switching it from, they had 300 CI machines, which is an enormous amount.

I can't even imagine.

They were talking about the problems of applying updates and making sure they were in a stable

situation, logging onto one and rebooting it and that kind of thing.

And they switched to a AMI-based environment in Amazon.

So they have base images.

And then on demand, they spin up a machine from that base image, they run some CI, and

at the end of it, they shut it down.

I mean, it's a long article, so I'm summarizing terribly here, but roughly that's the approach

that they took.

And we're running in cloud environments, so we have the potential to do something similar

if we wanted to kind of look into that side of things.

It's certainly another option.

Yeah, that'd be great. I mean, we talked about Tart in the past, which on macOS offers virtualization,

you know, like where you can spin up Macs, which would help a lot. I mean, on Linux,

we're sort of saved a bit by Docker, which effectively does that to a degree.

It's effectively doing it.

Yeah. And I've every year in June at WWDC, I hope for something Docker like to happen

for macOS, but I think that'll be a forever hope.

Maybe this year, Sven, maybe this year.

Oh yeah, right.

Not long to wait. Four weeks, is it?

Three, yeah, three. It's three weeks.

The other thing I was thinking about,

how would we actually decide what platform to pick next?

I mean, it's unrealistic that we do multiple at the same time.

How would we judge just effort?

Do we have a sense for how much demand there is for Windows over Wasm, for instance?

I think effort has to come into it, but I don't think it should be the primary metric.

I'd go on really gut feeling what feels like the right platform.

And to me, I think the gut feeling is very strong, actually, that it should be Windows.

I think WASM is certainly one that we would like to add at some point, but it feels to

me like Windows should be first.

Do you have a use case in mind or do you think there's a,

can you think of a project

that actually has Windows demand?

- I feel like I'm gonna refer to iOS Dev Weekly

a lot in this episode.

- I have to admit I'm prompting you a bit there.

(both laughing)

- What I was actually writing about on Friday

in the newsletter was,

so there's a web browser which has been around on Mac

for a little while now,

I think maybe like a year or just over,

something like that, called Arc.

And currently, so it's a Chromium-based browser,

so it uses the Chromium rendering engine

with a Mac user interface on top of it.

And up until, well, still up until now,

it is Mac only in terms of where you can run it.

But they are currently doing a Windows version

and using Swift to build that Windows version,

which is, I think I described it as ambitious,

because I think it is certainly quite ambitious.

And so, and actually that's, Salim is working for

that company, it's called the Browser Company,

and he works there at the moment,

and presumably he's leading that initiative.

And I actually had a little chat,

I actually kind of got it wrong in the newsletter.

I've posted an update to it this morning

just to correction.

I kind of concluded that they were maybe not working on some kind of cross-platform UI

framework but actually their CTO reached out to me over the weekend and he said, "That's

not quite right.

What we're doing is we're doing a different UI layer for Mac and Windows but both written

in Swift.

So we're not trying to make a cross-platform UI.

We're trying to make a platform-specific UI but all using Swift."

Which of course, if you want to get perfect platform native feel on both platforms, that's

what you have to do.

And so I think the fact that that project is in progress is one mark in the sand for

Windows.

Yeah.

So, I've come across a requirement for Wasm in one context that might be quite interesting,

and that is cloud deployment.

That's a, the project where this popped up was Swift Cloud.

It was an early testing I did before we actually started

our Doc C uploader project that is using Swift Lambda.

I came across Swift Cloud and that's by Andrew Barber.

And that is actually, that is Swift.

So you actually write a Swift package that deploys

to that cloud very, very nicely.

the process is super smooth, much smoother

than it is to get something deployed on AWS Lambda.

And there the requirement is that the packages

actually supports Wasm or runs on Wasm

because it gets actually compiled into a Wasm,

I guess binary, I'm not even sure

what the artifact is that comes out of it.

And that is then deployed into that cloud.

So in that context, I can see demand for WASM actually as a compatibility test.

That would be quite useful and interesting.

I suppose in terms of effort, I could imagine that WASM is probably quite a bit easier to get tested for,

because we would effectively be using, I guess, the Mac or Linux,

because I think all you need is a Swift compiler version.

And that needs, I think, to be a certain compiler version

that needs to be ready for Woz and Mitz,

not upstreamed everything.

But I think at least on the platform side,

that would be different from Windows

and less complex, I suppose.

- Yeah, I mean, it's kind of exciting

to have two more platforms

that we could potentially add to our compatibility testing.

That in itself is remarkable.

- Yes, and beginning of June,

there might be yet another one, who knows.

So I'm going to combine my first package recommendation this week with a quiz.

It was going to be a package recommendation because it popped up in the RSS feed of

new major versions this week.

But it is a package that I also then, or it's a tool that I also then ran on our

code base and we can do a little quiz on the results of it.

Oh, is that Paul Hudson's tool?

It is Paul Hudson's tool.

Oh, I haven't actually run it, so I'm unspoiled.

I'm curious what the results are.

That's good.

So the tool is called SitRep, and it is a tool that will take a look at your Swift code

base and give you statistics on it.

So I ran the tool today because it just, the version three release gained support for Swift

5.8, so it's right up to date with the current Swift version.

And I ran the tool today and discovered various different stats on our code base.

So let's start with a question about purely lines of code.

How many lines of Swift code do you think we have in the Swift package index?

Ooh, I ran a tool a few months back, and so I think I might have a sense of this, and

I think it was 30k.

Okay.

You are underestimating.

If in total lines of code, which I presume includes comments and all the rest of it,

we have 46,000.

And in source code, we have 40,000.

So there are 6,000 wasted lines of code in our code base.

Or maybe more, depending on how you look at it.

But not far off, I guess, the correct ballpark.

Well, I ran this three months ago, and we obviously wrote 10,000, 14,000 lines since

then.

So clearly, that's definitely what we did.

How about structs, classes, and enums? Of those three different types, which of those

do we have most of between just structs, classes, and enums?

Oh, I think the order is structs, enum, classes.

Interesting. Not quite correct, but you were correct with structs. So we have the most

number of structs, but then we have classes behind that.

No!

And enums trailing behind.

Yeah.

So we have 149 tests, sorry, 149 structs, 111 classes, and 58 enums.

All the vapor models are classes.

Yes, because I was thinking only the views where we actually have classes,

but all the vapor models are actually classes.

Yeah.

How many protocols do you think we have?

Not a whole lot, I think.

Give me how many classes did we have in the end or enums?

We had 111 classes in total.

Oh, wow. That many. Well, I don't know, like 40?

We have eight protocols, which is way less than I would have thought.

[laughter]

We're obviously not particularly keen on the old protocols.

And finally, one last question on types.

How many extensions do we have?

Oh, we have loads of extensions.

We have lots of extensions. You're great.

So I can give you a clue on this. We have more extensions than all of the other types put together.

Well, that's not... So I was going to ask how is that actually counted?

Because what I often do is I open an extension and then, you know, grouping a few things together

and then I open in the same file another extension on the same type, grouping yet another set of things together.

So is that two extensions?

I don't know how it works, but I would assume,

I would assume, given that this number is quite high,

I would assume that it is every time you make an extension.

- Right. - It counts that.

I'm going to say 200.

We have 354 extensions.

[laughter]

Okay, final-- well, not actually final question,

but you'll see what I mean.

What's our longest file?

Oh.

It's the same file, both in just pure number of lines in the file and actual longest amount of source lines in a type.

I think it's going to be a test.

And I'm going to say it's analysis tests.

Not quite. I think you'll actually be pleased to hear what the file is. It is a test.

And given that the package index is a search engine, it is actually our search tests that is the...

Oh, of course, because all the SQL is expanded and tested.

Right, yeah, yeah, yeah.

I remember in school that's a test.

Because those are massive.

And it comes in at almost 1300 lines of code, yeah.

Oh, wow.

So actually at that point what I did

was I deleted our tests directory and ran it again.

Oh, no.

Because I thought, well, what's the largest class?

Or, I think it's not actually a class,

But what's the largest type without the tests?

So what's your guess on that?

Oh, like type or file?

It's actually both. They're both the same.

Both the file and the type are the largest.

I'd say again analysis, although that's not a type,

that's just the file. So that can't actually be search?

You should have gone with your gut feeling.

The type is analyze and it's in analyze.swift.

So analyze, just to give a bit of background,

is the process that looks at all of the metadata from a local checkout of the Git repository for a package.

So we check out the Git repository and then we run this analysis process on it, which looks at commit history.

It analyzes the package.swift, it ingests all the metadata out of that package.swift file and a whole load of Git metadata as well.

But actually, given that it is such a large process,

the number of source lines is not that bad.

It's 623 lines, which I think,

given that's our very largest file,

I think that's kind of okay, actually.

- Yeah, I just remember I had started moving,

I think that has now a top-level enum

that sort of has a namespace analyze.

And one of the reasons I wanted to do that,

because then it's a bit nicer to break it up into segments

and name them properly because they're named by the type.

- I do have one final question.

So once I ran the tool again without the tests folder,

I was able to see how much of our code is in code

and how much of our code is in tests.

And I won't ask you for numbers here,

but as a percentage, how much is code and how much is tests?

- I think the tests are more lines of code,

maybe 50% more, no 30% more.

- Actually remarkably close.

We have more code than we do tests, but only just.

We have, we're 55% code, 45% tests.

- Oh wow.

I thought that was more the other way around, interesting.

- Which again, I think is actually fine.

I think that's a healthy balance of code

to tests within a project.

- I think in terms of time spent,

I spend with, that's probably why I'm overestimating it so much because I only stay at the tests.

So yes, that's both my first package recommendation for this week and also a little quiz for you,

Fenn, and for everyone to hopefully get a bit of insight into what our project looks like.

And I would recommend, it's very easy to install. It's actually, you can install it trivially with

homebrew, you can just have brew install and then there's a path you can install and it installed in

five minutes. And then running it is just as simple as typing sitrep in your source code

directory. The only other thing that I'd mention here is I had to clean up our source directory a

little bit before I ran it. So I had to remove the .build directory because it was looking and

finding Swift files inside there for all of our dependencies as well.

So I just completely removed that folder and then ran it on just our source code files.

So just be aware that it may give you, if you use Swift build from the command line,

you may have a huge .build directory which it's looking at as well.

Really nice. That was a nice quiz.

Do you want to do your first package?

Let's do the other packages.

So the first one I wanted to talk about is called "Gonzales" by Andreas Wendleder.

Gonzolo also on GitHub.

This is an interesting package because it's a package you're almost certainly not going to use.

[laughs]

I noticed this this week because there was a new release,

but then I actually went back to look into it in more detail

and found out that it was introduced in January 21 in a blog post and on the Swift forums.

And this is a package that is the TLDR is "Render Disney's Moana scene in less than 10,000 lines of

Swift code". And the thing about the package is it claims to be one of the only renderers

of that scene, which is an elaborate 3D rendering scene from a Disney film.

One of the only packages or things that does that, that isn't written in C++ or C.

Okay, I'm going to need a bit of context here. So obviously I'm familiar with the film Moana,

but what does it mean by render? Like, does it have the models? And does it have that kind of stuff?

Yes. So we'll add a link to the show notes. You can actually download the assets for the Moana Island scene from Disneyanimation.com.

Wow.

And this is really interesting. So the base download is 45 gigabytes, 93 gigabytes unpacked. That's just the base scene.

And there's 24 gigabytes of compressed animation data,

15 gigabytes of USD,

USD version of our data,

along with that might be,

I'm not sure what that is exactly,

but we're talking about--

- USD is--

- That's a 3D format, yeah.

- Yeah, that's model data because--

- But I'm not sure if that's just part of the base,

if that's in addition or if that's actually required.

But you're certainly looking at tens of gigabytes

of input data to render this scene.

So this is stuff that gets ingested by this package or other packages that render that scene.

That's the underlying data that it uses to then generate a scene.

So what this person, what Andreas has done, has written a Swift package,

and he says, "I wrote it in VI and command line Swift on Ubuntu, Linux and Xcode on Mac OS."

So I mean that first part, "I wrote it in VI and command line Swift."

I thought, wow, okay.

But apparently he's also used Xcode,

and I think he's used that mainly to do performance testing

because of instruments.

He mentions that.

I mean, that blog post from January 21

is definitely worth reading.

And there's a lot of interesting details

about the project itself, how it's been developed.

But what he did in January 21 is first run this,

and he created a single image,

he rendered a single scene, like one output scene,

like 2K by 800 pixels in 64-bit something,

I think that was the bit depth.

And he did this on a 8V CPU,

40 gigabyte memory cloud instance on Google Cloud.

And it took 24 hours.

So that's a single image, that's like a frame. He rendered a single frame in 24 hours.

And the release he published last week, which he re-rendered that scene.

Now it's not a one-to-one comparison. The image is slightly smaller, ever so slightly.

I think it's maybe like 10% in each dimension.

Also roughly 20% fewer pixels overall.

and a slightly faster machine.

So this will in the cloud instances

was actually I think a physical machine,

but he brought it down to 78 minutes.

So that's quite remarkable in itself.

- That's incredible.

- But I thought this whole project is really interesting

and the blog post certainly is.

So you probably won't use it,

but certainly you'll find the blog post interesting,

I believe, if you're interested in Swift

and that kind of Swift, which is sort of low-level-y

and just very interesting cross-platform.

It has lots of things that I find super interesting about Swift in general.

I had no idea that those assets were public and available.

Yep, there you go. That's Gonzales by Andreas Wendleder.

Fantastic. So my next package is one called One Finger Rotation,

which I spotted it because it's kind of an interesting title.

I spotted it in the RSS list of package updates, and I opened up the package page for it, and

instantly at the very top of the readme file is the most beautiful animation and explanation

of - well, it's not even an explanation because it's not what it does at all, but it's a beautiful

eye-catching animation, and it made me want to learn more about this.

So the control in itself is a gesture.

So you can add a one finger rotation gesture to any view.

So if you imagine, if you were designing a UI

that had a rotary dial on it,

this would be a gesture so that you could move your finger

across the surface in a kind of a circular motion

and have the dial respond to your touch.

But the animation on the top of this package page is wonderful.

So it takes a very simple line drawing of a rotary dial

and then in 3D spins it around to show this kind of incredible machine,

like Rube Goldberg type machine underneath,

which is creating this one fingerization.

And of course, it's complete fiction,

but it's a beautiful example of really catching.

I mean, it caught my eye for sure, made me look more carefully at the package.

And actually this package is great.

So there is, you might think that this would be a very simple package, but there

are so many things that you can do with this and you could have inertia on your

rotation gesture, so you can, you can either just have it track your finger.

Or if you kind of let go of your finger, you can have the dial carry on spinning.

And you can rotate to specific values with or without inertia.

You can have auto rotation.

So there's an enormous amount of work that's gone into this one finger gesture.

And I thought it was worth highlighting.

And it's the kind of thing I actually have used in real world projects before.

I think it depends on the project specifically, but a rotor and dial is

certainly a valid UI control in a touch environment.

Yeah, I mean, it's a virtual iPod click wheel, isn't it?

Pretty much, yep.

Yeah, I actually had this on my extended list as well. I saw that and I was...

So that's One Finger Rotation by Matteo Fontana.

Nice. Right, my second package this week is Swift Soup by Nabil Chatbi.

And this is a package that we're actually using in the Swift Package Index.

And what it does, it is a nice package to parse HTML,

which we have some need for,

I think in the context of adding the navigation bar

to our Doc C pages.

- You are correct.

Yeah, that's the only,

that's I think the only place

we actually use it in production.

So yes, we take the generated Doc C documentation page

and we want to add some HTML to it above and below as headers and footers on that documentation site.

And so we parse the entire HTML document so that we can insert various tags.

We insert stuff into the head tag, which is the non-visible part of the page,

and then we insert tags above and below all of the DocC rendering environment.

Yeah, and you touched on a key point there, we're parsing the whole page.

And I think that's maybe something interesting to briefly talk about,

because the first thing you hear when someone wants to extract data out of HTML is,

you can imagine the Stack Overflow question,

what kind of regex do I need to write to get this out of the HTML?

And the first response is, don't.

So this package is for the time when you're reaching for regex, but you know you shouldn't.

And I was trying, I mean, we have this immediate response, right? Don't do it.

Why is that actually?

And I looked into this briefly. I had some vague recollection of why that is.

And the things that come up, you know, HTML is a context-free language.

And I think it's, I don't even remember what the details are.

I think it's mainly about the nesting, you know, you can have deeply nested structures

that you eventually can't handle with RegEx because you can't write the RegEx for this

recursive thing.

I think the other part of it is just that HTML is so, what's the best word for this,

so accepting of almost any input.

It will do its best with whatever it gets.

And so with a text format like that where you might have a closing tag or actually you

you might not, or sometimes you will,

sometimes you'll have white space, sometimes you won't.

It's like it's a very rough environment

to start doing searches through

with a regx or something like that.

- Yeah, and pages might still render okay

even though they have technically incorrect HTML,

I think you know that.

- Absolutely, yeah.

I mean, the browsers have over 20 years

got all sorts of stuff in it.

They'll render almost whatever they can.

they'll render something no matter what the input.

And that's a very challenging thing

for anyone else to reproduce.

- Anyway, I was briefly on this,

you know, in this situation where I had

way too many browser tabs open,

and I ended up on the pumping lemma for regular languages.

And I thought at that point,

wait, you've got to stop, you're so deep in the weeds.

And you're reading about stuff you don't even understand.

But I thought that was really interesting and funny

how you can have these stepping stones from things you almost understand.

And you're just one click away.

I think, oh, yeah, after reading this page, I'll certainly know what this is about.

And you just, what you ended up with is just three more tabs.

So there you go. Swift Soup by Nabil Shadbi.

Yeah, and we can thoroughly recommend that because we've been using it now for a good amount of time,

well over a year and it has been flawless.

It's a great package.

- Yeah.

- So my final package this week

is a package called Discord Kit.

And the organization is SwiftCord,

which is not something that I had actually

come across before.

- I actually have.

There is a Discord client by that name

and Discord Kit, I think, then obviously

is the underlying package that drives

the API access for it.

I'm not sure what state it's in.

I've been checking it out for over months now.

Every once in a while I do download the latest release,

but obviously with Discord and we use it so much,

you need a lot of, you know, it needs to be quite mature

before you actually start using it in earnest.

But it is actually a client that connects to Discord

and displays channels and all sorts of things.

- Interesting.

So I hadn't come across that third-party client

But the reason I was interested in this package was you can create Discord bots with this

package.

So you could, the example in the readme file is a, just a simple ping bot where you can

send a message to the bot and it will reply.

You know, if you say ping, it will say pong.

But that's a proof of concept for a bot, basic bot kind of scaffolding.

And the whole thing is done in like five or six lines of Swift code.

And the reason I was interested in this is, so we use Discord quite extensively in the

Swift Package Index project.

We have a Discord server where we chat with contributors and just have general chat about

Swift Package Index, that kind of thing.

But we also recently moved all of our reporting across.

We used to use a combination of a tool called Rollbar, which is a web-based tool, and we

We had a Telegram channel where it would report exceptions and logging events to that Telegram

channel.

And we've recently moved all of that into our Discord server.

And so we have two channels, one for our staging environment, one for our production environment,

where it's just constantly saying, "Well, it deployed this version," or, "This exception

happened," or there's a whole load of information in there.

And I find that sometimes I would like, not for every message, but I would like some messages

to be more prominently notified to me than others.

And so I was wondering whether I might have a little play with seeing what we can do with

this bot to see if we can do some kind of fine-grain notifications there based on the

actual information.

I haven't done any of this work yet, but it just, it did stand out to me as something

I might do.

That's interesting.

Yeah, I'm really curious about that.

Why you added write something that kicks the one thing that seems to be happening every

couple of days where you need to manually intervene, if that could be automated with

a Discord bot, that would be amazing.

So yeah, I think it's the kind of thing that, again, this probably is not going to be a

package that many people use, but certainly being able to write a Discord bot in Swift

is a nice little shortcut. Great, I think that wraps it up for this week doesn't it?

Yeah, another set of package references, another quiz and we will be back

in two weeks with yet more Swift Package news. Exactly and that's going to be just

before WWDC. That is gonna be just before it isn't it? Yeah, absolutely.

exciting times.

All right, see you in two weeks. Bye-bye.