Swift Package Indexing

But we should probably start by saying it's been a while, because it has.

It's been a little while since we did an episode of the podcast.

A few things came up and we we ended up having to postpone a couple of episodes.

But we are back now. Yeah, we better late than never.

We I think we skipped one because it was slow news.

And now we've racked up a whole list of news items such that we get into the habit

of skipping them. It's easy to continue.

Yeah, yeah, that's what we want. We want a skipping streak there.

And also, I mean, I think it's probably worth just briefly saying that the

I think after our last recording, we both agreed that we would reduce

the frequency of the podcast a little bit from every two weeks.

And we didn't intend it to be this long between episodes.

But but we may we may switch to maybe every three weeks or even every four weeks,

occasionally a schedule, but certainly more frequent than it has been over the last couple of months.

Yeah, definitely.

So we should probably start with our plans around Swift 6.

We just finished processing all of the Swift 5.10

builds, and so we're fully up to date with the release version of 5.10,

which came out a few weeks ago.

I forget exactly when, but it was a few weeks ago.

And the next version of Swift will be Swift 6.

And we actually have some quite big plans for Swift 6.

So as well as, you know, our kind of standard

routine for a new version of Swift is that some point during the beta cycle,

we will update the system so that it can accept packages with the next version of Swift.

And then as we get towards the final release of it,

then we upgrade the systems to to fully support the release version

and process all of the builds at that point.

And we're going to do something a little bit different.

This one, because Swift 6 is a is a obviously a major version release,

which is always a big event.

And there are some breaking changes coming in Swift 6,

which you've probably heard about already.

They're all around structured concurrency and strict concurrency.

And you can actually switch on all the warnings around that you will

that will become errors in Swift 6.

You can switch them all on now in Swift 5.10.

And how do you do that exactly, Dave?

Would you would you tell us?

You use you use one of two flags.

And one of them is enable experimental feature.

And one of them is enable upcoming feature.

And if you get them wrong, as I did,

it appears like your entire project is perfect.

One of them will make you happy, the other one will make you sad.

The one that made me happy was was it that it showed me that there was nothing to do.

Yeah, what Sven is referring to there is that I did try

and switch this feature on and I got it wrong.

And if you want the full story behind that, it's on the the apology

for my mistake is on the latest iOS Dev Weekly introduction.

So you can go and read it there.

But yes, we can we can as of Swift 5.10, we can get a preview of all these

what will become errors.

And what we want to do is track the compatibility of packages

over the Swift 6 beta period.

So we actually was it the end of last week

kicked off our very first Swift 6 preview build, which is not

it's not in beta yet.

This is a nightly build of the tool chain.

But yeah, we are.

Well, I think I think it actually just finished processing.

Yeah, it did. Yeah, it finished earlier this morning.

And this is not the the whole compatibility matrix, because right now

the nightlies have trouble building with Xcode build.

So it's currently only testing the Swift PM platforms, which is Mac OS and Linux

by Swift PM platforms.

I mean, builds that you run with Swift build.

And that obviously doesn't work for iOS builds and the like.

So it's it's a slice of what we'll eventually build.

Yeah, and we got the results in and what we're tracking really is the error count.

So there's a instrumentation in the tool chains

where the compiler spits out lots of diagnostics.

And one of them is the number of Swift 6 errors

that it counted when it did the compile.

And what we're also planning to do is host a page on Swift Package Index,

which shows compatibility of Swift 6 over time.

Now, that page is not going to be released immediately.

Partly because it doesn't exist yet, but partly because what we want to do

by the time we launch that page is have some data to show, hopefully,

the number of Swift 6 errors reducing already.

And then throughout the beta period of Swift 6,

we will maintain that page and keep it updated with how

all the package ecosystem is doing with Swift 6 compatibility.

Yeah. Yeah.

And the idea there overall is to to sort of help a bit

with the transition, just following people on social media.

There's there's a lot of concern that this, you know, the 5/6 transition

might be kind of similar to the 2/3, Swift 2 to 3 transition in the past,

which I don't even recall.

I don't think I was using Swift at the time in an actual product

because the stuff we were working on didn't didn't really lend itself to be,

you know, the adoption at that time.

So I wasn't really one of those people who I guess were burned by that transition.

And but but that's still lingers, right?

That pain is still there.

Yeah. In people's memory.

I did have code that was affected by that transition.

And while my code was not terribly painful to convert, it was certainly

it's that thing where if you if you present the world in a certain way

and then suddenly present the world in a different way,

people are just going to get upset.

And I remember the the the wailing and gnashing of teeth at the time.

And and I think I think it's it's everything we can do to prevent

that kind of situation, to just talk about it as much as we can

before it happens is going to make the process smoother.

Yeah. Yeah.

And I think it bears, you know, stressing that there's no reason to believe

it'll be like that because and for a number of reasons.

So first off, there'll be they continue to be a Swift five mode.

So even if you use the Swift six compiler on a module by module basis,

you will be able to just compile your code in Swift five mode

and nothing will change.

So you you are not forced to do any of the things that are

good ideas to do in general when when Swift six comes around.

You know, it has benefits doing these things, but you're not forced to.

You don't have to do that immediately.

And you don't have to do it for the whole project at the same time.

So you can pick your battles,

pull the things ahead, you know, pick pick the ones that you want to tackle first,

get get a feel for what it means, do it.

And then, you know, by the end, over potentially a long period of time,

you'll be able to transition over.

And also, there's going to be like a host of resources to help you.

I think a lot of these things are going to be quite mechanical

just by following people, exploring what it means.

Even if you have a large error count,

often it's just a few root sources that need changing.

That'll make that number dwindle like massively by just making a couple of tweaks.

Yeah.

So when I did find out how to switch around properly,

we had around 500 and something errors.

But as I took a quick look through our

kind of list of of of warnings inside of Swift 5.10,

and there were so many that would look like the same thing.

Like once we fix one thing, I think, you know, it'll get rid of 100 errors.

And once we fix another thing, it'll get rid of another hundred.

Yeah. Yeah.

Look, there were lots of common root causes.

Yeah, it's actually interesting.

I believe you mentioned they are around the current

our dependency injection structure is some of them.

Yeah. Which is actually interesting because this is something I wanted to update.

I have been wanting to update for quite a while.

So this is based on a quite,

I wouldn't say old in the sense that it's outdated,

but it's been a few years that we started adopting this.

All this was published by Point Free Code.

That's a sort of a mechanism to do a dependency injection.

And it's valid. It works really well.

It has allowed us to write tests that would otherwise have been really difficult to write.

They have, however,

so there are some downsides to this mechanism,

and that's mainly around composing it between different packages and so on.

Point Free Code have a new mechanism, a superseding mechanism

with their dependency package that you can use instead of this,

has the same features, allows easier composition.

And I've always wanted to actually make a switch over

because it's the better, the more modern system.

But, you know, we have a working system.

You have no real reason to change.

So I haven't done it.

This is actually an opportunity to do both at the same time, you know,

get rid of that debt.

And I have sort of a bigger reason to do it at the same time.

I actually quite like that.

So I'm not aware of the new system that they've come up with,

but I just hope it's as easy as this one, because I really like the

the way that that works at the moment.

It is simple to, for a method that you need to

kind of step out for testing.

It's a really easy way to do that.

Yeah, it'll be similarly easy.

I mean, it's it's really just using macros

to facilitate the same thing, really.

Oh, macros. OK. I think it's based on macros.

Yeah, it's like it's like the environment system in Swift UI

in that you sort of import them.

You import customization points via a dependency clause.

You have sort of a variable that points to this dependency, which you can then

it's automatically populated with a default.

And in tests, you can override those and you don't have any of these typical

downsides of a dependency injection system in that you have initializers

that need to populate all these things, you know, for your types

because you attach it to the type, so to speak. Right.

Not sorry. I said macros.

I meant property wrappers.

That's OK. That makes more sense. Yeah.

But all of that is that's kind of quite deep in the weeds of

of I think we've fallen out a couple of rabbit holes there.

I mean, I think I think we'll we'll talk about Swift 6 more as time goes on.

And we'll probably talk about our progress

in fixing these 500 and something warnings that we've got

in subsequent editions of the podcast, because it is something

that's going to be a common theme over this summer.

Yeah, definitely.

All right.

I think that was it for Swift 6, wasn't it?

It was. Yeah.

Cool. I have a couple of points that I wanted to bring up.

Blog posts and social media posts that I found really interesting

that I've sort of accumulated over the last

well, few weeks that we've been on hiatus.

And the first one is a blog post by Daniel Kennett,

a great blog post called Combining Swift and Swift 6.

And C# on Windows with Swift to CLR.

I I don't recall where I saw this.

I believe it might have been on the Swift forums that he posted this.

This article. Yeah. Great.

It's really well written.

I just read it again because this is from February,

I think early February. So it's been a while.

And I reread it and I liked it all over again.

It's really worth the read.

Even if you, like me, aren't deep into ABI's,

runtimes and C++ translation layers, but he just paints a really nice picture

of of this proof of concept job that he started over the Christmas break.

You were just speaking about rabbit holes.

I think Daniel was quite deep in one there

and tells a really nice story about it.

The story about building a three layer contraption to bridge C# to Swift.

Right. And not only that, he somehow managed to create a helpful image

of these layers, like an actual image with source code and IDEs

and stuff showing how they interact.

It's it's really well done.

That's great. And I read it, too.

And I did think it was it was interesting.

It's also more low level than I like to go normally as well.

And what's really nice is so he sets out this goal where you think, oh, wow,

is he going to manage that or is that going to be the proposed about the

aspirational, but he actually succeeds.

So he lays out nicely at the start what he's trying to do.

And he he managed it in the end, which is to build both a Swift UI

and a C# Windows app that sort of interfaces with a common back end

that is written in in Swift and sort of is targeted by both these front ends

as the instrumentation to to what the back end does.

And the back end is a camera API.

So to manage camera feeds and that sort of thing,

which is just to give some context to that, that's what Daniel's apps do.

Yeah, exactly.

Yeah. And even not only did he write this post and, you know,

talk about his journey, he even managed to generalize everything

into a tool that does the automation of generating these translation layers.

So it's not just all, you know, hand assembled stuff that sort of

managed to work together somehow.

But he actually managed to to productize it in a sense

so that a lot of the mechanics of it are hidden away and done by a tool,

which is really promising.

And yeah, I mean, one thing I'd like to add,

we've sort of seen some really interesting posts appear on Swift.org

recently around Swift as a language

appearing in outside the typical habitat.

And I think that would be a would have been a post that had been

really nice to see on Swift.org itself.

Maybe it's not too late. Maybe that could still happen.

But I think that would be worthwhile having and giving it,

you know, another boost or more reach in general.

I might bring that up at the Swift website workgroup meeting, actually,

because I think you're right.

I think that would I think it would be a good choice.

Cool. Another bit of news

since we're talking about Swift on Windows, I saw that the other day.

Helge Hess posted that he managed to get Swift

running on ARM Windows 11 via

VMware's Fusion on Apple Silicon.

And I found that really interesting because when I initially considered,

you know, I think I was thinking about how to get started with Swift on Windows,

you know, just to get a feel for how it works.

I always run into I don't even have a Windows machine.

And, you know, I have

I have an old Intel Mac around, I think, but sort of

my initial take would be my first step would be to to spin up a VM.

But then you immediately run into the architecture problem, you know,

ARM Windows and and Swift probably not working on it.

And so I found that really interesting to see that it actually can be done.

And Helge said, it's it's not all that involved.

So actually might give that a spin.

I doubt we'll do our compatibility testing on Windows on ARM,

but it certainly would help to get a feel for how it how it could be set up

if if it was possible to do that locally on a VM, just on my machine.

So I found that really interesting to see.

Yeah, I think it does bring up the the there's a little bit of a small

a baby elephant in the room, which is we have Linux

compatibility testing, but Linux is a is a many faceted beast.

And there are many different Linuxes.

And we don't we're not we are very unspecific

about what type of Linux we are testing on.

And and so as we come to think about Windows compatibility and Swift,

that's one of those as well, where it's like, well, there's Windows

compatibility and then there's Windows compatibility.

Yeah. And I also I don't think we'll do ARM64 on Windows, mainly because

ARM64 Windows has had a bit of a rocky

start, I think.

And I think it's the vast, vast majority of Windows

is still Intel x86 Windows.

That's not to say that there's no ARM64 Windows out there,

but I think it's not it's not on the verge of becoming dominant

or anything like that.

Yeah, definitely.

And it certainly is unlikely to be the cheapest way of actually

hosting those builders. Right.

Yeah. So I think going with Intel will be the wise choice there.

While we're on the subject of Windows compatibility or sorry,

Windows and Swift,

there's a blog post, another blog post from Jeremy Day

from the browser company who have been working on

their Arc browser for Windows.

And in fact, their Arc browser now is out in Windows,

and that is a Swift application.

And this blog post is called Swift Tooling Windows Edition.

And in it, he talks about debugging.

He talks about how he edits code and lots of stuff.

And it's quite an extensive blog post, but definitely worth a read on this subject.

Yeah, I think I saw that as well.

That's really nice.

I just love seeing Swift pop up in all these different places now.

It seems to be happening more frequently, or is it just my imagination?

I think it does. Yeah, I think I think certainly the work

that the browser company have been doing has

generated. Genuine interest in Swift on Windows,

I think that's been really instrumental in what we've been seeing, I think.

Yeah. We'll include links to all of those articles in the show notes.

Yeah, definitely.

And just to wrap this up, the new section.

And I think you've you had this in iOS Dev Weekly as well, didn't you?

The Playdate blog post on Swift.org.

I did. Yeah.

Yeah. This is a blog post about

running in the scene of Swift in unusual places,

writing Playdate games in Swift.

And Playdate is a well, how would you describe Playdate?

Playdate is a is a handheld gaming

console, I guess, which is it has a little cortex chip in it

and it has a one bit, so black and white only

screen in it, which is quite high resolution,

but obviously just a monochromatic display.

And it is made by Panic, who make things like Transmit,

which is the FTP and SFTP client and Nova, the text editor,

which is really good.

And in fact, they've made so many apps over the years.

They're cornerstone of independent Mac development.

And they a few years ago decided to.

I think the original story is, if I remember rightly,

I may be getting this wrong, but the original story, if I remember rightly,

is that they wanted to make a

kind of long service gift for some of their employees

that had been there a very long time.

And they they thought about making a little a little

because they actually do publish some games as well.

They publish several games on Steam and on various different platforms.

And I think they they want the initial idea was this,

that it started as one of those.

And then they decided to do a kind of public release of it.

And they hit that public release right during

all the kind of development of it right during Covid.

And also the chip shortage.

So I think it's had in fact, I know it's had quite a difficult

journey to being released.

Actually, just I won't go any further into the story.

But if you're interested in the story behind Playdate,

the Panic podcast, which is a not a regular podcast,

but they did a series of, I think, six or seven podcasts.

And a couple of them, at least, were on the history

and the development of Playdate.

And they are a fantastic lesson.

I really thoroughly enjoyed them.

So that's what the Playdate is.

And they have an SDK so that anybody can write

software or games for the platform.

They also have a little app store.

So if you do write a game, you can publish it to the app store.

And I think the primary language for games is either C

and they have a C SDK or Lua,

which is a commonly used in gaming scripting language.

But now they can add one more language to that SDK.

Yeah, and that is Swift.

And that's that's going via the C API.

And I think what's worth calling out here is this is using the fairly

new embedded language mode of Swift,

which is sort of made for these devices with more

constrained environments.

And what it does, it spits out smaller binaries by stripping

and all sorts of techniques like that.

I think it has no or very tiny runtime and it's a language subset.

So it doesn't have all the features of full blown Swift.

In particular, there's no objective C interop.

There's no reflection.

And there are some limitations around Unicode.

So I think the main thing is that it doesn't have the Unicode

data tables, which means like Unicode point stuff,

you know, like character width and traversing strings isn't isn't available.

By default, you need to opt in.

And then that pulls in that those data sets making the binary larger.

And I think there are more constraints, but those are just the three

that I found in in quickly looking through the description of that language

language mode.

And you would need to use a nightly tool chain to actually make use of that.

And build and target the playdate with Swift.

But it's really great to see that this is being being used

and opens up Swift to yet another place.

Yeah, fantastic to see.

And I think as as Swift 6 arrives,

I hope we'll see some Swift games on the Playdate store.

Yeah, I think that's probably about it for Muse and kind of catching up.

So why don't we do some package recommendations?

Let's do some packages.

Do you want to kick us off?

Sure thing.

The first package I want to talk about this week is called Threadcrum

by Alexander Cohen, and

the description of it is a Swift, sorry, Swift,

no nonsense, dependency free breadcrumb logger.

And I really like the idea of this.

It's probably something that you can already do

if you have all of your symbolication set up in your project

so that you can get fully symbolicated crash reports whenever you want them.

But I really like the technique that Alexander is using here, which is to

you get the API to the developer, to you,

as threadcrum.log, and you can put a string in

a log message and there's your logging.

But the way that these log messages appear is, I think, quite clever.

What it actually does is it inserts stack frames into the backtrace

with the log messages in the method names of the stack frames.

So you can get these log messages out regardless of symbolication.

OK.

And I thought that was a really clever little idea.

Interesting.

OK, so even if something's messed up, you could still see enough in the stack trace

to sort of piece together where things were at.

Yeah.

And there's a good screenshot on the readme file that you can,

if you check it out on the Swift Package Index, that you can see how it kind of

manifests itself in a real world environment.

Actually, there's an interesting story behind that screenshot.

I was going to ask.

So this screenshot up until, I think, yesterday,

well, actually overnight, last night, it fixed itself.

But up until yesterday, this screenshot, if you'd have checked the screenshot

on the Swift Package Index, it would have been a broken image

because we had a situation with some readme file screenshots

that were not making it through to the package index.

And it's a fix that we deployed to the system yesterday, which was...

So there's several ways to include an image in a GitHub readme file.

Some of them you can just refer to a file, like if you include the file

in your repository, sometimes people put a .readmeimages directory

in the root of their repository or something like that,

and then just reference that file on raw.github.com, whatever it is.

That will work just fine.

And whenever we pull the readme in from GitHub's API,

those images just load off GitHub servers.

But some of the images, depending on how you upload them to GitHub,

when we request the readme file via their API,

they come back with a JWT attached.

And that JWT has an expiration date of five minutes.

So as we ingest the readme file into our system

and we hold a cache of that ingested readme file, so we upload that to S3.

That cached readme file has an image in it with a JWT on it, which has expired.

And so those images are never going to display for us

because it's unlikely that you would ever look at a readme file

within five minutes of us caching it.

So that has been a little project that I've been working on last week or so,

which is to, as we ingest the readme files now,

we also look through for any of these images that have JWTs attached

and we cache those to S3 as well.

So the good news is you should now no longer see any

broken images on any of the readme files in the package index.

And it wasn't, this wasn't affecting a huge number of packages.

It was 611 images across 148 repositories.

So as a percentage of our total, it was fairly minor.

But where people have included an image in their readme file,

it's usually quite an important part of what the package does.

And so I'm really glad that we were able to get it fixed.

Yeah, that's really great to have in.

So, yeah, that's Threadcrumb by Alexander Cohen.

And yeah, go check out the shiny new image on the readme file.

Nice.

Right, my first pick is called Flying Fox by Simon Whitty.

Flying Fox is a lightweight HTTP server with async weight APIs.

And I came across that recently because I needed to write a small proxy.

And I normally would have reached for Python, I think,

because, you know, it has stuff like that built in.

But I have been moving more and more of my scripting jobs over to Swift lately.

And I really like it.

So I looked around when I needed to write this little proxy.

And I recall that I had looked for HTTP servers a while back

and I came across Flying Fox again and tried it and it did it perfectly.

It's really concise, a really nice API, really easy to integrate and write that proxy.

Why I really like Swift over Python in situations like this

is obviously the type safety, which helps you write it.

But I found that it's much easier to pick up projects with large time gaps in between

because the type safety helps you understand what you were doing at the time.

You know, like these little scripts, I don't write lots of comments and stuff.

They're off the cuff written things that you write in the moment when you know what's going on.

And when you revisit those sort of things is when you lack all the context.

And I feel Swift really adds a lot of context out of the box

because you are sort of putting it in the types.

That makes it really nice to work in these projects.

That's why I really like it.

Right.

So the thing explains itself via the documented types

rather than having to guess at what it is from the outside.

And in Python, you always have this thing, you know, I guess it's a dictionary.

Yeah, but you know, how deep is it?

What's in it?

You know, that's always kind of weird.

So yeah, that's a really nice aspect.

I'm sort of digressing a bit from this nice package.

I mean, I wouldn't really say much about that.

I digress into a bug fix.

Yeah, and while I'm doing this, I might as well mention the one downside I found

when writing scripts and wanting to use dependencies like here,

you know, I want to use Flying Fox in a script, obviously to try it out.

I can't not mention our feature on the package index,

try in a package where you can click a button

and get a ready-made playground to actually use the package,

which is nice to try it out.

But if you actually want to run the script,

that's not really the way you would want to be doing it.

So then you hit the problem of how would you use a dependency in a script?

And you're kind of either forced to create a package, which is not too hard,

but it's also kind of tedious.

And the other thing you can do is use the package SwiftSH by Max Howell.

SwiftSH is a package where you can write scripts

and pull in dependencies via comments on your import line.

And then under the hood, it does all the package creation,

executable target definition for you.

So you can use a dependency in a script as if it was a package.

And that's really nice.

So long story short, if you need to write--

if you need to do anything with an HTTP server,

imagine you're writing an app and you want to stand up a very simple API

to play around with it.

That would be a really nice use case for something like Flying Fox,

where you can spin up a server and easily instrument it

on a fake back end, that sort of thing.

And these are the tools you could use to help you with that sort of problem.

Yeah, again, Flying Fox by Simon Witte.

It couldn't be any simpler either.

I'm looking at the readme file right now.

And to start up the server is literally two lines of code.

Instantiate a HTTP server and call the start method on it.

Yeah, yeah, exactly.

That's what I really liked.

And it was one of the few ones that I looked at that had, like,

modern async/await interface, which made it just appealing.

My next package is a package for testing.

And it's called Expect to Eventually Equal,

which is what caught my eye in kind of browsing through the packages that

were new to the index.

It is a fairly new package.

Only been in development for a couple of months.

And it's by Jon Reid, who is a kind of cornerstone of testing knowledge

in the Swift community.

He's been writing about testing in Swift for many, many years now.

And so this--

I mean, it's going to be no surprise what this does,

is it adds an additional assertion where you can specify a block to execute

and an expected value for that block at some point in the future.

And what it does is it calls that block many times with a timeout of one second.

I presume the timeout is probably customizable,

although I don't actually see a method to customize it in the readme.

So maybe it's not.

And it will continually repeat the call to that block

until the value is as expected or the timeout of one second is here.

And it's quite clear when it does fail--

I'll read you out one of the kind of failure messages here.

It says, expected to, but was one after 93 tries, timing out after one second.

So it gives you a really nice reason that the assertion failed, if it failed.

Or if it passed within that second, then you just

get a test pass, which is great.

Nice.

Yeah, I mean, there's the whole expectation thing, right,

that comes with XCTests.

But it can be sometimes a bit awkward to set up.

You have to put the fulfill thing somewhere.

And a block-based interface is just nicer for some APIs.

Yeah, and that's why I liked it.

Because you look at this code sample here, and it is just--

it is so simple to do tests that may not be the correct value immediately.

Yeah.

Yeah, ergonomics in tests I find really important,

because anything that distracts you from writing tests is sort of--

yeah, it's bad.

Because you really want to be encouraged to write as many variants

and different tests and that sort of thing.

So it should be as easy as possible, really.

And the other thing that I liked about this is that quite often when you look

at--

well, it's not when you look at packages, actually.

It's when you think about making a package.

You maybe think, well, if I'm going to write a package that's

around test assertions, then maybe I need to rewrite all the test assertions

so that people can use all my test assertions.

I really like that this is just one thing.

It's just like, this is a better way to do this kind of testing.

It's just one assertion.

This package is probably kind of done.

Yeah.

Yeah.

It may never get another update.

And nor would it necessarily need one unless that's something

changed in the underlying code.

So yeah, I really like that these kind of focused, small packages,

I think they're great.

Yeah, you said something there that just reminded me.

Either quick or nimble, I always confuse which one does which.

One of them has alternative assert syntax.

Nimble, yeah.

Nimble is the matcher, yeah.

Which makes it really nice.

I really like the package.

I even used it a bit at the start.

But the problem is, not for every project

are you going to pull in a test dependency like that.

And then when you do, you're sort of

faced with that conundrum.

Well, do I now switch everything over or just the new tests?

And then I have a mix, and it's all weird.

And yeah, I mean, we also have different--

we use different patterns in our tests.

And that sort of annoys me sometimes

that they aren't all the same.

But there's only so much you can do.

But if it's something as fundamental how you assert,

it's really tough.

It's a tough sell then to do one or the other.

Yeah.

Yeah, one of the slight odd ones out

is our use of snapshot testing.

That's a whole different mechanism

to writing a test than the regular assertions.

And I wouldn't change that.

I wouldn't want to get rid of that.

But it is one of those things where you have to kind of, oh,

we're doing this kind of testing.

OK, we're using this API.

There we go.

Yeah, although in its defense, at least it

does sort of function.

And then it has two expectation values, right?

The nimble one is different in that it's almost

like a statement that you write.

I don't recall off the top of my head.

It's not like a function call.

It's different.

It's expect something to equal something.

Exactly, it's like a chained expression.

Yeah, yeah, yeah.

It makes it stand out a little bit more.

It's taken from a library which is literally

the standard in Ruby development, which is RSpec.

So there is an underlying testing library with Ruby,

but almost everybody uses RSpec.

And it's a behavioral BDD testing framework

where you describe what the thing should do,

and then you write some expectations in there

to assert that it is behaving correctly.

And that is what Quick and Nimble are effectively

porting across to Swift.

I'm really hopeful that with the new Swift testing package that

is coming soon or later at some point,

that Xcode starts to get better support

for different types of testing.

One of the reasons that Quick and Nimble

is challenging to adopt is that effectively your entire test

suite collapses down into one Xcode test.

And so you only get one green tick in Xcode

because your entire test suite is one test.

And then within that test, you've

got potentially thousands of expectations

or even sections and everything.

And I'm really hopeful that what they're

doing with Swift testing leads into slightly more

flexible reporting of those test results within Xcode.

Right.

I've actually used-- which one was it?

Quick, right?

That's the behavioral part.

Correct, yeah.

I've only used Nimble, the expectations.

Yeah.

Because I really like writing tests.

It's a very nice way to structure your test suite.

You can have nice sections.

And one thing that we're also not perfect at,

because nobody's perfect at this, I'm pretty sure,

is our consistent naming of our test methods.

We kind of use underscores to indicate that there's obviously

the word test and then maybe the type name

and then maybe an underscore in the method name

if we're testing a specific method.

But it's very inconsistent how we name those.

And one thing that BDD does is it gives you a really nice way

to just use English to describe what you're testing.

And that becomes effectively your test name.

Right.

Right.

So where were we at?

We've gone down lots of rabbit holes.

Whose turn is it?

Is it my turn?

I think that was mine.

So I think it's your turn.

Right.

My second package, and I think probably also my final package,

right, given where we're at in the recording.

My second package is called Swift Package Info

by Felipe Marino.

That's an interesting tool.

It's a tool that provides info about a package, most notable

about its binary size.

I sort of think we've talked about this in the past,

but I don't think we've had it as a package pick yet.

If we did, then we'd just do this whole thing again.

I saw this again, and I thought this

would be an interesting metric for us

to expose at some point.

So this we have definitely discussed in the past,

whether we would have means and ways

to expose binary size on the package page.

The interesting part there is the question

is, how much will my binary grow if I

use this package or a product?

It's a bit of a problem if a package

has more than one product.

That's not a one-to-one question,

but let's leave those details aside for the moment.

Just roughly, what would that mean for my app

to use this package?

And the concern has been, well, in order

to actually assess that properly,

we would have to build that package with a release build.

And we're not doing release builds right now

because they're much slower than debug builds,

and they're not really key to determine compatibility.

It's a fair assumption-- not a perfect assumption,

but a fair assumption if a debug build succeeds.

So with the release build, again, not certain,

but it's a good starting assumption.

So we're not doing release builds

because we're already on a constrained time

budget for our builds, and that would just squeeze that

further.

But I had a thought how we could potentially work with that

and get to use it at least initially,

and that's if we made this an opt-in for packages.

Because as I just said, it's--

so this tool looks at products in a package,

and you have to specify the product if you want

to get binary info out of it.

So we would sort of need to have a way for the authors

to tell us which product is the one that we should measure.

And that would go via our SPI.yaml file, right?

That's currently-- well, that's not just currently.

It's probably always going to be the only way for authors

to express that interest.

And that could be a way for us to signal to us, right,

I actually want to expose this metric.

Run a release build instead of the debug build,

maybe in addition.

I mean, we would have to deal with the implications,

I guess.

And authors would then also know, right, we're on a budget.

And if you already have a package that's quite large,

you kind of would know you can't opt-in.

So that might be a way of dealing with that.

And that's why I found this package interesting.

It sort of sparked the idea to maybe look at this again.

It is a very commonly requested feature of Package Index.

This has come up several times over the years.

And it always comes down to that release build thing.

And we always kind of say, OK, well, we'll put it to one side.

But I remember as soon as we launched the build system back

in 20--

end of 2020, we were instantly asked about this feature.

Yeah.

Yeah.

You think it's feasible if we do it this way to sort of opt it

in?

Would that still be worthwhile, even though the opt-in probably

isn't going to be huge?

But, you know.

Yeah.

And I think the more--

I think you're right that this mechanism of having

a file in the repository that we read is a good mechanism.

I don't want to change anything about that mechanism.

Of course, it is always a struggle

to get people to read anything.

And so communicating that this is a thing

that we can do is always going to be a difficult-- yes,

we can do a blog post, but nobody reads blog posts.

Yes, we can talk about it on a podcast.

And people do listen to podcasts,

but they're not on their computer

when they listen to podcasts.

And so they rarely do it.

They rarely act.

Like, it's hard to get people to act.

It's hard to get people to do things.

Because people are busy.

And it's not a criticism of people.

People are busy.

There's a million things that need your attention

whenever you're working.

And so getting that adoption up will be challenging for it.

But as the Swift package index grows,

and as it becomes kind of expected for a package

to be on the Swift package index--

and this is our hope, of course, that it becomes the place

to look for packages.

I think that as we see some packages adopt features

like this--

it's like we see with documentation, right?

That is a process that we're going through

to get people to consider hosting

their documentation with us.

And we actually have one very effective way

of letting people know about that,

which is whenever you add a package,

we have an opportunity to tell people who--

the package authors-- about the features that they can add.

And that's where we talk about documentation.

So we could add something there to also say,

if you'd like to let people know what kind of size impact

this is going to have on your users' applications,

we could put that in there.

There is less incentive for them to add this feature

than there is about the documentation,

because if that number is big,

it might stop people using the package.

Yeah, that's true. It's true.

But I think most packages will not have

a significant effect on people's budget.

And once you reach a tipping point of,

well, why doesn't this package have that number,

then that becomes much easier for people to kind of--

there's going to be a little bit of peer pressure

to adopt these features as they become more and more used.

Yeah. Yeah, I mean, I could see this as some SDK

having a good binary size and going forward

and publishing that as an advantage

and then sort of perhaps generating--

because it's also not-- many packages won't need that, right?

There's lots of dependencies that are sort of used

in ways where binary size isn't that important.

Like, we adopt packages in our server-side project

where binary size isn't that crucial.

I mean, we ship this thing in a Docker container.

That package dependency is going to make no change whatsoever

in our final product size.

And there's also examples like the package

we were talking about earlier, which is the testing package,

expect to eventually equal.

Exactly, yeah.

Absolutely irrelevant to the size, yeah.

Yeah. Here's a thought I had as you were talking about

making it easier for people to act.

I've actually just remembered because I had this thought before.

What if we had little actions that--

Yes, a button you click that opens up a pull request

with a pre-configured SBI.yaml file against your repository.

Like, for instance, adding documentation.

We look at the thing.

We could even read the package manifest,

know what targets there are, generate an SBI.yaml file

that's fully configured for the explicit repository,

opens a pull request so that all they have to do

is merge it into their repository

if they don't have an SBI.yaml file already.

So I've been thinking a little bit around this

over the last couple of months as well.

Not to the point of actually doing anything about it,

but I do have a half-written note

about how we might approach it.

And one of the things that I think would--

or one of the challenges that we have right now

is that telling people, telling package authors--

The package index at the moment has two groups

of people who visit it.

There is one which is people who are looking for a package,

and they're the kind of obvious group.

But there is also the group of package authors

looking to look at their own packages

and figure out what's happening with it or whatever it is.

And we struggle--

Our web pages are very much targeted at the first group.

And the second group, they have their own page,

and it's called Information for Package Maintainers

or something like that.

And there's a little, tiny little link to it

halfway down the sidebar on the right-hand side of a page.

And behind that is a whole load of information

about adding badges, about how to configure documentation,

links to all our documentation resources and things like that

on this kind of subject.

And that is a less than ideal place to put that.

But of course, you don't want to overload the site

with all that information being pushed down

the throat of people who are only there just

to find a package.

And I think the ultimate answer to this

is that at some point, we will have a logged-in area.

And that area is entirely for package authors.

Like, the whole point of that area

is so that you can see that your packages are producing

the compatibility you're expecting,

that they are being indexed effectively,

and showing the information that best highlights

what that package does.

And I don't think a authenticated area

of the Swift Package Index is necessarily--

I don't think the first thing that will come out of that

will be for the people who are looking for packages.

I think it will be for package authors.

And this kind of stuff of generating an SPI YAML file,

we'd have so much space for all that stuff

if there was a way to let people authenticate

and claim a package.

And I've been thinking about how we would do the claiming as

well.

And this is now going into--

this podcast is just full of rabbit holes today.

But I think we could actually use the SPI YAML file to--

yeah, to kind of say, these are the people who

are authorized to maintain this package.

And that way, you keep that responsibility

with the repository of defining the data for that package.

And then if we do a login with GitHub or whatever,

that could-- it could just be a list of GitHub usernames

or whatever it is.

I mean, I haven't thought this through in that much detail

yet.

But I think that's potentially where we're heading

with this kind of thing.

Yeah.

Right.

Right.

I think that's--

Show me Bruce Dillard.

--a long enough podcast.

Yeah.

[LAUGHTER]

So we will be back in--

last time that it took us to get this podcast out

is as specific as I'm going to be.

Big promises.

[LAUGHTER]

But until then, we will--

well, we'll speak to you whenever that happens.

It will probably be in three weeks' time.

All right.

See you next time.

Bye bye.

All right.