Swift Package Indexing

Well, maybe I can fill in, though we maybe need to agree on a safe word where you reel me in.

I've debated whether I should bring it up because the news topic is, I mean, effectively, I'm talking about one of my packages,

which I've been using for quite a number of projects now.

And that's why I feel like it's really useful and maybe worth talking about and mentioning it so people can check it out if they need it for their work.

And the background of that is the documentation pages are becoming more popular and more relied upon.

So we do have a need of having a more fine grained availability testing in place.

Now, we do have probes in place to alert us if the homepage is unavailable.

Surge, I think we have a couple of we have like a little smoke test script, which is actually also powered by that same tool.

And we also have Azure's availability probes in place and something else called status cake.

Status cake, yeah.

What's the history of that name of that web page status cake? That doesn't seem like a...

I have no idea.

I've been using them for years, but I have no idea where their name came from. But it is odd. It is odd.

Every time I get an email, you know, typically when I do maintenance on staging where we don't have redundancy,

you know, we get the status cake email and staging is done.

I think, what on earth were they thinking naming that status cake? But yeah, it does its job.

While we're talking about the smoke test, there was as well, you may remember,

there was a time when our smoke test tested every single package page. Do you remember that?

Yes. Yeah, that was... I made it so easy to actually test all the pages that I didn't stop to think whether I should.

So the main purpose of this is we need more fine grained availability testing.

So we need to test more pages because there are a number of doc pages that we can already see by the traffic that they are visited a lot.

So we should ensure that they're there.

And there's typically no risk that they should disappear once they're there, except for a couple of edge cases.

And that is if a new version were to be published, and that version had build errors for some reason,

you know, might either be the package having issues, which is unlikely for those packages.

But it also might be a problem with our build system or something else going wrong.

Or the latest Swift version may be having a problem and not preventing the docs from being published.

So in that case, the latest version might not be available, but the main branch would still be there to pick up the issue.

However, if there's an actual problem with a package, it's quite likely that also the main pages might have a problem.

So in any case, we do actually want to know for a detailed list of packages, the popular ones, that the documentations are up.

And as far as I know, there aren't a whole lot of things that allow you to create these sort of testers easily.

On macOS, I've used Paw to do API exploration and a little bit of testing as well,

which is a great tool for those who don't know, where you can put in a URL and add query parameters and all that,

do post requests and all that sort of stuff and then run that repeatedly.

But that's obviously not something that's easy to deploy into a CI environment,

because what we want to do is have a script that a crawler uses to hit pages and then also verify the return codes.

And the tool we're using is actually a package of mine that I wrote four years ago now for exactly that purpose,

to do testing of pages and like detailed testing, not just for the return code, but also return results.

So if it's a JSON API, you can drill into the payload that you're getting back and you can even use that payload to drive further requests.

So the initial purpose was to both do the testing where you do sign up testing, for instance,

you create a user account and then you get the token back, you sign in.

That's obviously quite complicated to do with curl, because you'd have to get the result back,

then use something to pass the JSON, get the data out, stick it in the next request.

And you can imagine doing that in a shell script.

Of course, yeah.

Can be super fiddly.

So what I at the time used initially was a JavaScript tool called strest.

And that worked okay, but then it was missing a few things.

And rather than try and extend something, you know, in a language that I'm not very familiar with,

what do you do? You rewrite it.

And that's what I did at the time.

And this is the tool Resta, which we're using now to do our general smoke testing.

So we're just a couple of pages, but also in this case, this fine grained documentation page testing.

And the nice thing is, this is driven by a YAML file that effectively is the script.

And that YAML file is very easy to just auto generate from a list of URLs that we just query from the database.

So we have a little extension on our server package that actually writes out a list of URLs that we want to probe.

And that YAML file, we just ship with a repository.

And there's a scheduled job that runs the Resta tool, which then queries all the URLs and checks that return codes are as expected.

And the whole thing will fail with an error if any of the URLs aren't available or something like that.

And we've been using that for quite a while now.

So right from the beginning of our smoke test, we've been using that Resta package to not only detect these latest documentation pages, but also every page that we test.

Yeah, it's not new.

So we actually have a stage that runs after a deployment that probes the whole page, a search page and another page just to make sure the deployment is up and nothing's broken.

No, it's a great little tool.

I'm glad we have it.

Right.

I think that's it with the news, isn't it?

Yeah, I think it's a fairly slim week on news.

I guess that's the way it happens sometimes, isn't it?

That's the way it is.

Yeah.

I feel like I'm in a meeting in my bus where I have to describe what I've done over the last three weeks.

Yeah, it's an awkward stand up where you think, oh, god damn it, what did I do?

I was so busy, but nothing's actually finished.

I know I've done stuff.

There's one other thing I worked on that I'll probably talk about some other time because it's not quite done.

I want to tie it all together.

We also might have a bit more news in other areas to talk about next time.

But in the meantime, maybe we can do something that we haven't done for a while.

And I hope you forgot that we talked about that last time.

And that is a...

Is it a quiz time?

Okay.

It is quiz time.

Yes.

Remember what the open question was that we left dangling last time?

I remember that there was an open question.

I don't know what the question was.

So that's a good thing, I think.

That's great.

That's a great excuse.

So I can be fairly sure that you didn't look up the details.

My terrible memory is a feature, not a bug.

Yes.

So the question was, are there any other Linux-only packages that we had?

The topic last time we talked about documentation generation on Linux.

And that was triggered by two packages, auto-1 package benchmark and package Frostflake.

So these were the two example packages.

And the question was, are there actually a lot of Linux-only packages?

And I had a look.

So what's your guess?

How many overall packages are only testing as available on Linux?

Obviously, when we test something to be only available on Linux,

doesn't necessarily mean it is.

So that's just the result of our tests.

Of course.

Yeah.

Yeah.

I think it's fairly low.

I would say we're what?

5,500-ish total.

I would say 10.

Oh, wow.

It's nine.

That was a...

You get three points for that one.

And I'll thank my SQL queries.

No, I'm kidding.

I didn't do it.

Actually, I sat down.

I thought, oh, God, this is going to be one of these ugly SQL queries I need to write.

And then I realized it's actually a single field in a single table that tells us this information.

Right.

The thing is, I had to do a bit of digging because as I suspect,

there's a number of accidental Linux-only ones, and that's four of them are really Linux-only,

but the build happens to fail on the other platforms, which is kind of funny.

But sometimes the Linux builds actually succeed because the way they fail is

they do certain availability tests for Apple platforms,

and Linux just falls off and doesn't actually build anything.

So it succeeds by doing nothing and the others fail.

Right.

For some obscure reasons.

Yeah, yeah, yeah.

So that's four of them.

And I think there are like three Linux-first packages that are clearly targeting Linux and

don't happen to build on macOS, but probably would with a little bit of tweaking.

And on that subject, I think it's as the popularity of the site grows,

we see package authors pay attention to their compatibility results.

And sometimes they'll pop in and raise an issue or pop into Discord or something

and just raise like, oh, I was expecting it to compile here and it didn't.

Now, I think we do a really good job of getting compatibility approximately right,

but we can't get it 100% right for that number of packages.

And so there are always going to be cases where package authors need to

just kind of come in and take a quick look and see if their package results

or their compatibility results expectation matches what we actually report.

And I think as we become more popular and our usage grows,

I think that will become less of a problem because people will be paying a little bit of attention.

Because generally, once it's fixed up and once it's kind of working,

it works forever.

Like it's not something that...

Yeah.

You don't need some monitor your package compatibility results,

but sometimes you do need to just kind of take a check.

Is it doing what I expect it to do?

Yeah, and an easy way to actually do check that and have an eye on it is if you stick the badge

in your readme, because then even if you just look at the GitHub page,

you have another chance of seeing whether it actually matches your expectations.

In case anyone isn't familiar with that badge, you can put a shields.io badge on your readme file

that reports the platform and the Swift compatibility status of your package.

And to get that badge, if you...

So as you add the package, it tells you how to get the badge at that point.

And it is also on the package page, but it's kind of...

The link is less obvious these days on the package page.

So on the right hand side of your package page, towards the bottom of that column,

you'll see a little bit of text that says something like

information for package authors or something like that.

And if you click on there, then you'll get some markdown from there where you can

paste them to your readme to put those badges on your package page.

And I'm always happy to see how many of those...

I know you keep a track of how many you spend.

Do you have a current count?

I... Last I checked, it was 400.

400.

400 and a couple.

That is pretty good, given 5,500 packages-ish.

400, I'm very happy with that number.

Yeah. Yeah, it's really great.

That's it for the quiz.

So 9 overall, that was two real Linux-only packages,

which was clear because they tried to import glibc.

Right.

I guess those could also be made to work on macOS and three Linux-first packages.

But yeah, it's a low number, but Linux at this time is not the most common platform

for Swift yet, although it's probably widely used in the server space.

Let's revisit this in a year and see how many Windows-only packages there are.

All right.

So if we're done with news...

Let's do some package recommendations.

I wonder if we get clashes again, because I think there's one that we probably both have

picked, but let's see how it goes.

Well, I'm going to start off with one that I've picked this week,

because it changed its name.

So we have a script that runs every night that looks for deleted packages.

If it starts getting a 404 on the repository,

or if we get a redirect on the repository, it notes that and it removes the old one

and it adds the new one, that kind of thing.

So I noticed one package author who is a very prolific package author, actually.

It's Sindre Sorhus, and he renamed one of his packages from

Preferences to Settings to match the new Apple terminology of now everything is settings,

settings and nothing is preferences, to match the iPhone, I believe is where that came from.

And he has a package called Settings Now, which is a macOS UI package to build a kind of standard

looking tab bar at the top, window that resizes to fit your settings, standard settings window

for any macOS app.

And that's the kind of thing that, you know, I've built several macOS apps that maybe wouldn't

have ever needed too many settings.

And you just end up with, you know, maybe a settings window with one or two checkboxes,

but it never looks quite right.

And to actually get that functionality, especially if you are switching tabs between lots of

different settings pages, it's quite a lot of work.

And so this package is a nice little shortcut to save you the effort of building all that

functionality.

So whenever you switch tabs, it resizes the window to fit your new set of UI controls.

You can add icons and text at the top.

You can also have it in a segmented control style.

So if you didn't want to use icons, you could just have a segmented control at the top.

Really nice little package just to save you a whole lot of time building a standard looking

consistent settings window.

It is surprisingly difficult to layout settings.

I have only this little app and it has a preferences window, settings window, and I'm never quite

happy.

I'm not super happy with the way it looks, but I just don't know what to do to make it

look nice.

I can tell if a settings window is really nicely laid out, but for the life of me, I

can't, I can't steal the mechanics of actually getting there.

It's really bizarre how difficult it can be to lay out a little bit of text and controls

to make it look grouped.

I always open a couple of different examples.

Obviously this system settings, which is the preferences or the old system preferences,

but also a company that always does a great job of settings windows is Panic.

So if you open any of Panic's apps and open up their settings window, that I have one

I put on my screen right now.

It just looks right in every, every single panel that just looks really the correct design.

And it's really hard to, to put into words what makes it correct.

And I had a great hope actually for SwiftUI to kind of fix this because that takes away

a lot of the layout stuff.

And you have this, you only even have this control called form that you should be able

to just pop a form in.

And I was hoping desperately that it would give you a perfectly laid out settings window.

The reality of that on Mac OS is not quite there yet.

I don't think, and I think there's something about settings windows that, that form doesn't,

I form, I don't think was intended to be just for settings windows.

In fact, it certainly wasn't, but I hoped that it would do that job.

And I think there's a little way to go yet before it can, it can do that.

And at the moment it needs, it still needs manual layout for me.

Yeah.

It was a bit like the hope, like SF symbols for, for, you know, symbols and icons, because

that's, that's a great, it baseline a lot of iconography in apps to a very solid baseline.

And you don't get that same thing for, for layout and forms and stuff like that yet.

And one day we will get the old Java applet dream of write once run anywhere.

But today is not that day.

Right.

My first pick is called Popup View by Alisa Milnikova.

And this is a, a package that allows you to display alerts, popups or toasts in your app.

Why are they called toasts anyway?

Do you know?

I don't know why they're called toast, but that is a standard term for these.

It's really bizarre.

I first came across that when I worked in London and, you know, bigger company and all

those terms started flying around and I never quite never stopped to ask why it's called

that, but you know, toast is like a little banner at the top that displays something.

And it's a really nice package.

You can bring it in, has lots of different styles that you can pick from.

And obviously there's always a bit of a risk delegating such a core element to a third

party library.

But one of the things I thought about when I looked at this package is there's a low

risk way of introducing something like that.

If you maybe initially deploy it for in-house error messages, you know, like when you are

developing an app, you might want to surface all the network errors in detail in your debug

builds or something like that.

That might be a good way to start using a package, but that's not to say that this package

would actually, you know, you would have to be careful because this has been around quite

a bit.

It's quite, it's quite popular, 2K stars, and it looks like a really nice package to

handle that sort of thing for you.

So that's PopupView by Alistair Melnikova.

I did see this package and I think if you want toasts or, you know, whatever you want

to call them in your app, then this is a fine package to use.

But I also, every time I see these used in a real app, I wonder whether a toast was the

right idea because it's a very easy way to just throw UI into a place where it can just

be ignored almost.

You can kind of have some UI come down from the top.

And if you look at, I mean, I always look towards Apple's apps in terms of design.

It's very rare that they use this type of control.

I'm not going to say they never use it because I'm sure somebody will prove me wrong, but

it's certainly, it's certainly rare.

And I think with a package like this, not specific to this package, but with a concept

like this, restraint is beneficial when using this.

You can end up with apps, and I've seen apps that have so many toasts in them that they're

kind of annoying.

So yeah, that would be my only comment on that.

Yeah, I mean, there's perhaps a reason why there isn't a native UI element for that.

Right.

But I do think there are cases where it's useful.

And I realized that the other day when I was using Hivery, they mastered on client because

what they do is they toast stuff in that would normally be a notification if you're not in

app.

And then it's actually quite nice because you're not pulled out of your current view.

You get a chance to see what's happening.

That is actually populating a little notification bubble for another view that you're not currently

looking at.

So I think that's a great use of it.

Yes.

It's too heavy for notification, but it's still interesting enough to actually be displayed

immediately.

I think that's a great use case for those kinds of things.

My next package is another result builder.

I think I've had a result, some kind of result builder for the last several weeks now.

And this week is no different.

My result builder this week is called Menu Builder and it's by Jed Fox.

And it is a, again, it's a Mac OS package.

Am I secretly building a Mac app?

The answer is no, but I do seem to have picked a couple of Mac OS packages this week.

So this is a result builder for NSMenu.

And NSMenu is a relatively old API these days.

And to be able to, in an AppKit application, just have a very SwiftUI-like menu item.

And then inside a menu item, you can have a .view, which then gives you a SwiftUI view

inside that menu item, separator items.

And then, yeah, it's a great way to visualize your menu inside your code in an easier way

than it would be with NSMenu in code directly.

Nice.

Would that work in menu bar items?

Does that mention that or would you not?

It doesn't mention it, but a menu bar item is just a menu.

So it is, you can just pop a NSMenu into your menu bar app and that will work.

So yeah, this is, I mean, I think SwiftUI now has support for menu bar apps as of the

latest release.

It does.

And I'm actually, I've written one recently, but the reason I'm asking is you can't,

there you can't mix like text menu items and views.

Oh, interesting.

So I used another package we talked about in the past to work around that.

And the way it works around it is it recreates like text menu items on its own.

So it's not using standard controls.

It just mimics them and has like a control center look.

And I was wondering if this package would allow the same thing, but using actually,

I don't know what to call them, native menu items, you know, like buttons render into

menu items like you would expect, which is other packages working around in different

ways.

I'm not sure.

I might try it out and report back.

Great.

Right.

My second package is called ContributorUI by Zia Scotti.

And that's the one I thought you might've picked because it is a great UI to show

GitHub contributors.

And it looks a bit like the grid of avatars that we have on the Swift package index home

page.

You know, this little grid where you have the round avatars.

You're correct that I would have picked this one if I'd have seen it, but it's right

past me.

Well, there's something for you then.

So this shows the little round avatars, GitHub avatars.

And I think this pulls mainly from code contributors.

I'm not sure if you can actually configure that to have other contributor lists like

from sponsors, but if it doesn't, perhaps that's extensible or I mean, it is open source

might be something that could be added on, but it looks really nice.

It's available on all platforms.

So iOS, macOS being all in this case, I'm not sure there's a lot of use for that on

to VOS, but although I suppose it could be, and yeah, it's a really nice little thing

to pop in.

I would also compliment this package on a great opening screenshot, which is always

very important.

If your package has any kind of visual element to it at all, this screenshot, if you haven't

had a look at this package, go to package index and search on contributor UI.

And that opening screenshot is really well designed.

It shows one, two, three, three different uses of it on different platforms in light

and dark mode, all in the space of what would be, you know, maybe 15 to 20 lines of text.

That is a great opening image.

Tells me almost everything I need to know before I even started reading the readme.

Yeah, absolutely.

And it's, you know, color matched.

So the title color is like a brown, light brown, nice little gradient.

It's like very tastefully done.

It's a great readme intro.

Yeah, it is.

Yeah.

So there you go.

That's a contributor UI by Sirius Scottie.

I hope I've got the first name pronounced correctly.

So my last package for this week is one that's actually been around for a very long time.

It's been in development for seven years and it's GeoSwift by the organization GeoSwift.

But I can see that the primary authors are Andrew Kirschberger and Andrea Cremasi.

And GeoSwift is a package that helps you handle geometric objects in code.

So you can define areas, you can define points, you can define all sorts of different bits of

geometry, and then you can do interesting things with those bits of geometry.

So the example from the readme file is if you have two geometries, one, which is an

outline of the country of Italy, and another one is a fairly arbitrary set of polygons,

that, you know, there's an outer polygon and then an inner polygon cut out of the middle of it.

You can, for example, intersect those two geometries to get just a new geometry, which is

the intersection of those two.

You could buffer a geometry, so you could expand it by a certain amount.

You could difference a geometry.

You can boundary a geometry.

You can do all sorts of stuff that is quite tedious to do if you don't have some kind

of library to help you do it.

Yeah, I can imagine this can get super fiddly really fast if you want to do this on your own.

That kind of stuff is fiendishly complicated.

Yeah, and it's the kind of thing that you're not going to need to do this very often.

But for example, if you're dealing with core location geofencing or something like that,

a package like this where you just have that problem solved for you by this package,

and the fact that it's been developed for seven years means it's on major version 10,

which is why it popped into my feed this week.

I did have a quick look at the release notes for 10, and there's nothing particularly notable.

It's added some new functions.

Looking at the history of the releases, it seems to be a release every year or so,

something like that, and then maybe a couple of bug fixes after it.

But certainly the last major version was 9, and that was a year ago.

So yeah, it's a package that probably doesn't need updating every single week,

which is also good, but it's the kind of thing that you might find useful if you need to do that job.

Great.

And my third pick is called Swift CLI version by Michael Lujuch.

And this caught my eye because it actually does something that

I've sort of manually been doing in a couple of packages, and that is the issue of a executable,

and let's talk about command line executables maybe as an example, reporting its version.

So for instance, you might have written a CLI command and you wanted to spit out its version,

and that should typically be the latest git tag or whatever

the revision was at the time of building that package.

And that is a bit tricky to do, right?

You don't want to do this manually, update some sort of file,

and the way I've been doing that is run git describe,

which gives you sort of the git version of your history and pipe it into a Swift file.

So I have a template in my binary with a template version,

you know, that just says something, you know, version not saved.

And then from a make file, I sort of pipe the git describe over this file,

sort of replacing that version so that it can be used in code to spit out the version.

But obviously, that is all tied into having to run the builds,

you know, the release builds through this make file to make sure that this is created

in time for the build to absorb.

So it can be done, but it can be a bit fiddly.

And what this tool does, it is a build plugin that does all of that automatically.

So you add the build plugin to your tool, and that can be a tool, it can be an app.

And what it does, it creates that version.swift file as part of the build process

every time, reliably, and then you have access to a variable,

a global variable, just all caps version that you can use.

And it's a string, an optional string, I think,

that you can use in your, in all the places you might want to show exact version details.

So that's really nice.

It takes away, you know, the pain of having to set up that sort of make file based

or whatever mechanism you use to mechanism to create this version file and does it for you.

A really nice way, really nice use of a build tool plugin to get this result.

But surely make files will last forever.

I'm confident of that.

Yeah, so that's Swift CLI version by Michael Husch.

Great.

So maybe we should wrap it up there.

It's a slightly shorter than normal episode,

but I think last time was a slightly longer than normal.

So they do differ slightly.

But what we'll do is we will be back in two weeks with some more news,

hopefully some more significant news in a couple of weeks,

and some more package recommendations, of course.

Yeah, I'm sure we managed to balance it out with a longer episode again.

So here we go.

Exactly.

Yeah.

All right.

So we'll see you then.

See you in two weeks.

Bye bye.

Bye bye.