Subscribe
Share
Share
Embed
This week Dave and Sven break their streak of skipping recording to find Swift in exciting new places, like on ARM Windows and the Playdate, and learn new tricks like interoperating with C#. And as usual, there are package recommendations, with a good sprinkling of descents into various rabbit holes.
News
News
- Combining Swift and C# on Windows with SwiftToCLR
- Swift on ARM Windows 11
- Swift Tooling: Windows Edition
- Swift on the Playdate
Packages
Creators & Guests
What is Swift Package Indexing?
Join Dave and Sven, the creators of the Swift Package Index open-source project, as they talk about progress on the project and discuss a new set of community package recommendations every episode.
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.