Subscribe
Share
Share
Embed
This week, we discuss importing ALL the packages, Swift 5.9, the Swift mentorship programme and package scores. Plus, of course, package recommendations!
News
News
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.
Remember last week we talked about dependencies and in the course of the conversation I sort of
apologetically, is that a word? I sort of feel, I felt embarrassed when I mentioned that
SPI server, so the package that drives the Swift package index webpage is the one with the most
dependencies in the index at 56. And when I was listening back to the episode, I thought,
I've been approaching this all wrong. This is the Swift package index server package. The server,
the package that's hosting the package index, it should be using as many packages as possible.
We need to embrace the index, right? Embrace the index. That's probably a tagline we should have
on the site. So if anything, that number is too low. We should be aiming to have at least 1% of
our packages that we use. I have a mission. Yeah, I have a mission. I'm going to get all the
dependencies. Maybe we should just include every dependency just in case we need it.
Well, at least a few more we could do, right? Maybe we should remember when Steve Jobs announced the
iPhone and said, you know, once to have 1% market share, we should maybe have 1% package share in a
year. Yeah. And maybe then in the future, we could aim for two or 3% long-term, but you know, 1%,
we're close. We're at 56, 63, 10% is 1%. So we're right there. I mean, it doesn't take much.
who else is going to test whether all these packages work together? I think we are the only
answer to that question. I mean, I'm sure there's a couple of easy ones we can pull in
without bending over backwards too much. I'm sure something can be done.
Anyway, so that was that. And then the other interesting bit of feedback we got was from
Joe Heck, so he sent us a follow-up email. We've talked about JavaScript dependency trees,
how they tend to be big and self-referencing in ways we found puzzling. And he suspects
the reason is that the dependency trees in JavaScript are independent. So, and my understanding
was if this is as if Swift package manager, when you do package resolution, it looks at the whole
thing and resolves one version and one version only per package that is used for your artifact.
And sometimes that doesn't work, right? There is no package resolution because one package has a
certain range for a dependency and another package has another incompatible range and then package
resolution fails entirely. My understanding is in JavaScript, that would still work because
you have two independent subtrees that both use that dependency, just at different versions.
And I think the analogy in Swift is as if every dependency was built like a binary artifact,
and then you pull those binary artifacts in and link them into your binary at the end,
such that they're sort of opaque. Yeah. Yeah, pretty much, but it's not binary, of course,
it's just source code. So the slightly annoying thing is, I actually knew this already and I just
completely slipped my mind completely when we were talking about it last week. And it is an
interesting approach, but it brings with it as many problems as it solves. Yeah, it's interesting
how these different approaches potentially lead to different outcomes. I mean, we don't have the
numbers. There were some similarities between JavaScript's ecosystem and Rust. And Rust,
I believe, doesn't have that same approach. So the fact that they also have circular
references might indicate that that would happen in Swift as well. Again, we'll do this at some
point and then we'll find out. I still can't explain why some packages reference
themselves. Wasn't that a thing? Yeah not only that, I think even directly,
which I found super baffling. Yeah so the two dependency
cycle is now explained more readily, but the one package dependency cycle is
still a mystery to me. Yeah that pretty much is a mystery. I wonder if
something that was wrong with him. But you know his analysis looked very
thorough and considered so it doesn't look like this was a data mess-up
or anything like it. We'll see. And if you're wondering what we're talking
about, you should go back and listen to the previous episode where we
talk about this blog post about JavaScript dependencies and
you'll hear all the background to what we're following up here.
here. Yeah, exactly. Yeah, right. That was the follow-up that I have in my
notes. One thing we can talk about this week is we had a pull request merged as
a result of the SWIFT mentorship program. So we've been participating in the
mentorship program for three years now. This is our third year of participation
and I've been working with Cindy Chin to work on some of our package scoring
code. And so there's actually been a couple of pull requests merged by Cindy
already. The project that we're working on is all around package score and how
we determine it and how we surface what the package score is and so package
authors can see their package score and things like that. And we got started with
with one pull request almost at the beginning of the program and then this
week we merged another pull request which is part of the scoring mechanism.
So we're adding an extra dimension to scoring. So we have this internal package
score which is what we use. It's not entirely the sort order for search
results but it contributes to the sort order for search results and we want to
make that package score represent or should we say we want to make that
package score increase when good quality packages should naturally increase that
package score. So for example, if a package has been maintained recently, it
had an issue closed or a pull request closed or a commit or something like
that, then we count that as a recently maintained package and that
adds to the score. If the package repository is archived, we don't give any
points for that, but if it's not archived, we get some points for that. And there's
several. You can have a look at the source. In fact, we'll give a link to the
source code in the show notes because the algorithm is transparent and open.
and we've added to it or Cindy has added to it this week by adding a
score increase if your package has a test target. Now there's pros and cons to
this score increase for test targets. It is just about the simplest
implementation of are there tests in this package and what it does is it looks
through the targets in the package manifest and if you have a test target
then it says then you probably have some tests. Now depending on how you made your
package you might have got a test target for free and might have never added any
actual test to it. So there's an element of this which we would like to improve
again in the future but this progress towards a better system right? This is
that how software development works, we step one foot in front of another.
Yeah, I think it would be good as a second step to try and at least reject the common case where
someone has just created a template package and sort of got the points for free and someone who
actually cleaned up the template and removed stuff they weren't using would actually be sort of
punished for doing the tidying up, that's probably something we can do at some point. It doesn't
sound like it's... I could imagine there are ways to do that that aren't overly complicated.
Just briefly thinking about it, Devel might be in the details, but it's the sort of thing that is
probably one metric that is going to be really interesting for someone looking for a package,
test coverage one way or another, if it's by counting targets or number of tests,
or ideally actual coverage is a really interesting metric, but obviously it's also hard to get,
right? Test coverage is really hard to obtain unless you run the tests and running the tests
isn't something we'll probably ever do or be able to do because ACI system isn't
notoriously difficult to set up even if you own the project and probably
impossible to do if you don't own it. So yeah CI is hard to set up if you're
being paid to set it up. Let alone us setting up for every project that
exists. I really like messing with tests and CI but the prospect of
managing hundreds of CI systems of packages I don't own isn't one I cherish.
Yeah, yeah it's interesting. It's the kind of thing that I also don't
think we'll ever go to that level with the package index compatibility system.
But we could certainly do more to start actually looking for
number of tests. I probably wouldn't want to even report, even if we could, I mean
obviously we'd need to run the tests, but even if we could find a way to do that, I
wouldn't even particularly want to report code coverage. But I think a
simple number of tests is a great metric that we'll potentially work
towards going forward. Yeah, and I think that might be feasible with Swift
syntax if you really want to look at the source code or maybe even some
simple heuristics that might be wrong, but you know in some edge cases, but generally have
a good result that might work too. I think there are ways to arrive there that aren't overly
complicated. And then the next stage of Cindy's work on the mentorship program is to explain that
score. So I said a few minutes ago, I said we put a link to the source code in. Linking to the source
code is one way to tell people how their package is scored, but it's not a great
way. It is, however, the way that we've been relying on so far. But the
next piece of work that Cindy is currently working on - in fact I had a
meeting with her about an hour ago where we looked at a prototype of this
working on her branch - is to - so we have a page for package maintainers
where we give people the markdown for the compatibility badges that they can
put in their readme and links to how to configure the documentation and things
like that. And at the bottom of that page we're going to have a section where it
tells people what the package score is and then has a table underneath that
score to also explain how the points were tallied and why the points were
tallied so that you can take a look at your package if you have a package in
the index and see okay well this is why I got this score and if I would like to
improve my score this is what I need to do and if if all of this works then
those things that you do to improve your score will also make your package better
so hopefully there'll be no gaming of the system. I was just gonna say we're
going to publish the recipe to game the system. Well I think there's obviously
gonna be a little bit of that and we can't we can't stop that nor would I
particularly be interested in stopping it. But I think as long as we are, I think
we should be transparent with what the score is. I mean we are being
transparent by definition because it's an open source project so we can't, we
could hide it, we could put it in a private package but I definitely don't
want to do that. So it is already open. This is just explaining it
- Yeah, and you know, if we get people to add documentation
to their package, even if it's bare bones,
that's still a win.
If that's the level of gaming we arrive at, that's fine.
That's good, because then it's easier next time around
to just do a little more,
that other little bit of documentation,
because you've already set it up, why not use it?
- It's like a broccoli eating competition.
You know, you can cheat and eat a load of broccoli,
and at the end of it, you're just more healthy.
(laughing)
(laughing)
That doesn't work at all.
- It sounds like you don't like broccoli.
I actually love broccoli.
That didn't sound like--
- I actually, I love broccoli.
I think I would even go as far as to say
broccoli is my favorite vegetable.
Ah, that's funny.
I don't know whether that'll make the edit.
(laughing)
- Leave it in.
- The last thing to mention here is that Cindy was very keen
with her mentorship to do a feature end to end.
And so we started off with some planning of it.
We talked about possibilities.
We talked about, should we even display the score?
Where should we display it?
We toyed with having it on the package page.
So we did a little kind of feature design at the beginning.
We also wanted at least one more kind of indicator
into that score, which is this test target,
pull request that got merged.
But I think the other thing which is really nice to see
is that she wanted to take this feature
right through to launching it.
And the last pull request on this project for her
will hopefully be a blog post announcing the thing.
So it's literally from what are we even going to do
through to several pull requests to add some functionality
through to launching it and publicizing it
and getting the word out about what we're doing.
- Very nice.
- Which I think is just, it's such a great attitude.
It's been, I mean, it's not over yet,
but it's been a pleasure working with Cindy so far.
- That sounds great.
All right, in other news,
we have upgraded our build system
to the release version of Swift 5.9,
which is probably not a big change for most packages.
We were still running on a early version
of the Swift 5.9 beta,
but I don't think there were many packages
that had any build differences between the two.
The biggest change is probably that we're also now generating a documentation by default
with 5.9, because the documentation generation always happens on the latest release version
in our system.
And as long as we're on a pre-release version, we don't switch documentation generation over
yet.
So if you haven't specified a Swift version for your doc generation from now on, your
will be generated with 5.9. That's also probably not a big change between 5.8, 5.9. Do you actually
know what the docc differences are between the two versions? I don't think there was any.
The quick navigation was 5.8, right?
Yeah, that was a very user-facing feature that came with 5.8, but 5.9, I don't think there's
anything in the UI. I believe there was a default change when it comes to generating documentation
for extensions but I'm always a bit hazy on what goes in when and what default is enabled when.
But it might be a good idea if you have documentation and you release a new version
or just the main branch, have a look at your docs for that version to make sure that everything
looks as you expect it to. And if you see any issues, make sure you generate your documentation
locally with Swift 5.9 to see if they get the same result. And if there's any discrepancy,
let us know. If there are any errors, let us know and we'll take a closer look.
Yeah, that's just the heads up around that change.
Absolutely.
Shall we do some packages?
Yeah, let's do some packages. And I will start us off this week with a package by Miguel de Icaza
called Swift Godot or Godot, which is something that I've been paying a little bit of attention
to for a little while now. So I don't know whether you heard in the last couple of weeks,
Unity put their foot squarely in their mouth with a change of business plan that really
was not very well thought through and was to say the least badly received by the Unity community.
One could say there was discord in the Unity community.
One could if one wanted to, yes. But let's hope one doesn't want to.
Yeah, it was a terrible PR disaster. And I'm not a Unity user. I've downloaded it and had a very,
very cursory play with it, but I definitely wouldn't call myself a user of it. But one
thing that I had been kind of keeping my eye on is this open source game framework called Guddo,
or "G'not" I'm not quite sure what the pronunciation is. And I think they had a
huge boost in publicity when this unity announcement went bad because everyone
suddenly starts looking for well maybe what else is available. Yeah. And yeah and
Miguel has put together some bindings for the framework using Swift. So there
is apparently a new extension system in the framework that you can hook into
and then interact with the game object. So the default language for this
framework is actually a language called GDScript, which it's a little like Python
in that it uses indentation for structure, but also it's a little...
there's certainly a couple of shades of Swift in there with, you know, VAR
statements and funk statements and things like that. So it's GDScript
itself is one option for interacting with this framework, but now you can
actually also use Swift. And I just want to call out what a fantastic job - I don't
know how I haven't used this package - but what a fantastic job Miguel has
done with documenting this package, even down to hosting a tutorial, a 50 minute
long tutorial using the Doxy tutorial framework to get you started with
building a game with Swift using this framework.
Nice. Yeah, this was actually also on my list, actually the first one.
Oh, I sniped you!
sniped, got in first, yeah, and I picked it for the same reason, with the Unity stuff going on.
It's really interesting, yeah, I saw, I didn't actually see that there was this
long tutorial in it, and I think tutorials can be quite fiddly to generate, so creating a tutorial
that long is quite the task. That's amazing. So from the readme file, if you click through to the
API documentation you'll end up on a Doxy generated documentation set which is
unfortunately not hosted with package index but we'll forgive Miguel that just
this one time. And the very first link on that on that documentation is to the
tutorial it's called meet Swift Godot and it is estimated at 50 minutes of
development. Nice. The other thing perhaps worth mentioning is there is a binary
package that also comes with Swift Go, or is associated with Swift Go though, and the advantage
here is that he has packaged the underlying library up in a binary artifact, so you don't need
to actually build the whole framework to use it, and that should probably help with your just user
experience using that package. I haven't tried this, I don't know how this worked. I did have
have a quick look into how to set this up, but I quickly gave up when I saw what
all is needed to do this, and game dev is a bit like cooking for me. I've
sort of chosen to specialize in eating, so I'm much better at playing games than
doing anything around creating them, so I pretty much waved the flag
immediately. I have had a play with the framework itself way before the Unity
stuff. I investigated it maybe six months ago, but I didn't do anything apart from
write a little GD script, which is just the default. So that's, yeah, that's
my first package recommendation. I think we are going with Godot, right?
I think so. That's how I had it in my head. Probably needs some sort of
phonetic spelling out as a metadata field on all these packages.
So that's SwiftGido by Miguel de Icaza. Right, my first pick is called Swift SDK
Generator by that little company called Apple and this is of particular
interest to me. It's a package about or for cross compilation. It's a cross
compilation toolkit and was I think released just last week or the week
before. So there have been some Swift proposals around this Swift proposals
that went through a while back, but this is the first part of the whole cross
compilation story that is actually usable and does work but in limited
ways. So currently what it supports is cross compilation from Mac OS to Linux
And the way this works is use this SDK generator to create a Swift SDK toolkit.
So it's sort of a bundle.
You can bundle up, it's 2.5 gigabytes of stuff, essentially Linux stuff that you bundle together
and it's by Linux version.
So there are slight differences between different Linux distributions.
So you need to do this typically per Linux distribution.
I've tried this for Ubuntu Jammy, for instance, and obviously also by platform.
And then you, you package this together and then you can import this into the, into
your Swift compiler tool chain effectively.
And after you've done that, you can run Swift build and it's currently an
experimental flag, so you do it Swift build dash dash experimental dash Swift
dash SDK, and then you reference the SDK you've just created and effectively give
it a Swift version number, a platform version label and architecture.
So like 5.9 release, Ubuntu, Jammy, AR64 for the ARM version of it.
You specify that as the identifier for that SDK, and then you can cross compile
on Mac as a Linux binary, and you can copy that over to Linux Docker image, for
instance, a Docker container and then run it.
And after that, it works just fine.
Really nice.
And, um, I mean, obviously this is probably not the most interesting path yet, right?
Compiling from macOS to Linux, because if you are looking to perhaps save some money
on your CI, the macOS as the platform to run stuff on is probably not the cheapest option you have.
I don't know what the plans are, if it's ever going to be possible to do it the other way around.
like on Linux to cross compile to macOS.
I'm not sure how that would work with licensing and all that.
But that would be for us, for instance, that would be really interesting.
Because currently Linux is a very easy platform for us to manage and, and, and
maintain with respect to Swift versions.
Whereas macOS interestingly is, is the most complicated one.
We might have a little story to tell in the future, how that might be possible
to make it a bit easier, but currently it's a bit of a fiddly system with respect to macOS
versions and Xcode versions to manage. I really hope that at some point these SDK setups become
really universal and that they support lots of different combinations. I mean, ideally all of
them, but that might never be possible. But the more combinations are covered by this, the better,
really.
- And I think that's the key thing here is that this may be a package which will become more useful
and or more used in the future, but it's good to see that there's thought and planning going into
this now. - Yeah, I mean, just the effort that this exists and works is amazing. I think this
is a really great and strong indicator of where we're heading here because I mean, none of the
the Apple packages strike you as efforts that happen now and then don't go anywhere. I think
these are all long-term strategic things that are just being started now and are intended to be used
and to grow. So this is really exciting and the fact that this already works and is usable is
compelling. I'm not sure it's something that would help us immediately. I mean, I could see how it
could make some of our build system easy. So if we were to use this, it would make actually parts
of our setup easier. It would make other parts of our setup harder. So it currently would be a
trade-off, but just the fact that this exists would give us an option in dealing with certain
complexities in our system. And I can, you know, envision that in the future this might make lots
of things just easier in general, where right now we have to do a lot of special casing. So I'm
really looking forward to how this package develops in the future. Yeah, that's great. It's great to
see. My next package is Zip Pinch by Alexey Bukhtin. And this package kind of blew my mind
when I found it. It's actually not a new package at all. It's been in development
for eight years so this is a very well established
open source package. It's not a, I don't think it's a
particularly terribly complicated package because
in those eight years it's only had 48 commits but
that's not to put it down at all. It's just
you know some jobs are big, some jobs are small. But what blew my mind
what it does and what it does is it's an extension for URL session to work with
zip files remotely so you can open peek inside read and write to a zip file
without downloading the file locally which absolutely blew my mind now it's
been a very long time since I looked at the details of a PK zip file but I do
do remember from when I did briefly look at it when I was a kid,
basically, that it does have this kind of table of contents at the beginning,
and you can reference into the file and you can get just the bits you need and
all the rest of it. But to do that remotely over a UL session kind of blew
my mind a little bit. Now you might ask, well, how useful is that? And it became
more useful in my mind when I read that it was also compatible with watchOS.
So I can absolutely see a situation where on the watch you're trying not to
download an entire zip file, unzip it, try and poke through what the
files are inside there, but to be able to access a remote zip file and access
files within that, I can see this being useful.
So is this PKZIP or ZIP or are they the same? I don't know. I thought PKZIP was different.
PKZIP was the original file format. I mean I know that file format has been incredibly robust.
I can't say there have been no changes to the zip file format since then, but I don't think there
have been many changes to it. Right, so this is just a general zip file that you could like if
you right-click and click compress, that's the same format. It's a zip file,
yeah, absolutely. So how does that work? Does it just use HTTP offset like
head requests and stuff like that? I haven't been digging through the source
code, but that's the only way that I can think that it can work. So it must do a
request to get the beginning of the file, read a little bit, read the table of
contents and then do a separate request at an offset to read the file and then
unzip the content locally. So that's Zip Pinch by Alexey Bukhtin. Very nice.
Right, my second pick is another package by Apple and it's called Swift Testing.
People have probably heard about this because I believe you also referenced or
mentioned this in Friday's newsletter, didn't you? Yes, in fact I wrote my
opening comment on it. Ah right, yes, yes. You actually had a link to the
Vision document about the package in your opening and it's actually, that
document is hard to find. I wanted to check it out again and the best way to
find it was to go back and find that issue because it's not actually linked
from... Well the best way to find anything is to go to iOS.com. Here we go.
our sponsors this week. I really love this package. When I saw this announced on the
Swift forums, I was so excited because I've long felt that that XC test assert and the whole XC test
framework is great. I mean, I've used this for literally decades now. I mean, this is ancient,
right? And it hasn't changed really. The word I used to describe it was "fine". It's fine.
It does exactly what it needs to do. Yeah. And you know, at the surface, it's the same old. I learned
unit testing with Java in, I still know the year because it was at a conference in 2001
where I first heard about unit testing and I was immediately taken by it. And the concept is
exactly the same since then. You have a runner and you have asserts that you effectively something
equals another comparison function or macro or however it's implemented and something that
prints out if they differ and to various degrees they print it nicely or perhaps in the case of
XCT_ASSERT less nicely the actual difference. And what this does, it gives, it uses macros to
revisit how all of this machinery is done. So for instance you have a #expect macro that unifies all
of the XCT_ASSERT variants, so you no longer have different ones that you spell out like XCT_ASSERT
equal and I think the other one is "exert equal accuracy" if you want to compare two
doubles with a certain accuracy. XCT, assert true/false if you have boogalions that you
compare. All these different variants you have to use. #expect is a single macro that you use,
It can handle all these different variants and it gives you nicer printouts in case of
error logging. I do hope that they sort of steal from the power assert library that we talked about
in the past. I'll add a link to the show note. I'm sorry, I don't have the author's name to
hand right now. It's called power assert. It's a macro library that gives amazing printouts of error
messages when an expression is wrong. It actually details which part of the
expression is what and uses ASCII-R to point to the different elements.
Yeah it's super cool. So you can immediately see what's what it's an
amazing library and I hope they they they you know steal or you know and some
shape or form absorb the awesomeness of this package into the Swift testing
package, so we have it available without having to import anything extra.
It also adds an @test annotations to your test functions.
So it's not any longer required to adhere to certain naming conventions to make tests
discoverable. So there's no longer a test_naming of functions.
They can be named anything and you have the @test annotation and you can even give your
tests speaking names like proper descriptions what they do.
By default, if you don't do anything, it'll just use the test name as the test name, but
you can override that and even use like normal strings with spaces and all that to spell
out what the test does.
Really nice.
It's just a modern test suite really.
It has parameterized testing so you can run many tests that just differ in input parameters.
And the recommendation is already great.
There's a great guide on how to convert tests over.
I've actually tried this out with one of our packages to see how this works and if it's
already usable.
And it is.
I think the only thing I noticed is that there is no class setup function at the moment.
So a class test up, if you have a XCTest case, if you have a class setup, it runs once per
suite, whereas an instance setup runs before each test. So right now you'd have to sort of fake that
by keeping a little Boolean around where you mark if it's run already, if you have need for that.
But other than that, everything I needed to convert over that test was there, and the output is nice.
You need a nightly toolchain right now to use it, but it's all documented how to use it and looks
looks like really great. I'm excited about this. I can't wait to have this around. I
suspect it'll be Swift 5.10 when this will come. I don't think this will be any of the
dot releases of 5.9. So I think we're looking at Spring. But yeah, I mean, Spring can't
come soon enough to be honest.
Yeah, yeah, it does look really, really great. And I think the fact that this is being developed
as an open source package rather than something.
'Cause obviously testing is a big part
of what iOS applications and macOS applications do.
And it's a big part of what Xcode does.
And there's obviously Xcode integration with XCTest
in the current releases of Xcode.
And I think that the fact that this is being released
as a open source Swift package is a really good sign
that that interface between test results
and Xcode showing you test results
might become a little more flexible.
And that's mainly what I wrote about
in the newsletter on Friday.
My hope that that would be the case
to enable things like different testing strategies
and different testing libraries.
And wouldn't it be wonderful if we could,
if Swift could support lots of different testing approaches,
not just one blessed testing approach,
even if that bless testing approach is great.
- Yeah, I mean, I'm pretty sure it will be
because I mean, functionally it's a drop in replacement
for the existing system and there's lots of,
there are lots of other packages,
quick and nimble that are built alongside at least,
if not on top of XCTest,
point three also have a number of test extension packages
which make use of XCTest
and all this should still just work
and be possible to extend and build on top of.
- Of course, yeah.
But the problem with those things,
especially QUIC and Nimble,
is that the way that Xcode reports those tests
is because everything has to effectively
be done within one XC test.
And so your test suite passes or fails,
and they do things to make that a little easier.
But I'm hoping that this ushers in a new era
of decoupling the tight integration between that.
- Yeah, I mean, just the fact that this is
an open source package gives all these developers
of these test extensions an opportunity to chime in.
And they already have.
I've seen Stephen Sellez too, listing their packages
and highlighting in which ways they build on top of XC tests
and sort of hinting at these would be potentially useful things to have inside this package.
So you don't need to actually onboard different new test libraries. And he didn't say so,
but I'm pretty sure that Stephen and Brandon would be happy to see functionality moved out of their
packages into a core testing library such that they wouldn't have to maintain it anymore and
could use it. So I'm really excited about this for all these reasons. It's built out in the open
and gives all of these other test extension packages and authors a chance to influence
the direction. And I think that looks really, really great and promising.
Yeah, it is. It's great. Okay, I'm going to start my last package recommendation this week
with a question for you, Sven.
Howdy, is it quiz time again? Kind of, it's just a one question quiz.
How many times have you written a regular expression to detect an email address?
Not a lot to be honest. I don't know. Not a lot, but probably more than zero, right?
Perhaps, yeah. I mean, I know I'd probably look for a... I know this is a hotly debated topic,
you know, like using Regex stuff to parse certain things. And I know, especially the email spec is
not as easy as you think it is, right? Even the domain name spec isn't as easy as you think it is.
So. And you have to incorporate all the domain name spec plus the email spec, right? Yeah.
I might even go so far as just to look for a single @ sign and make that the, you know,
depending on how rigorous the check has to be. But sure. And that's the temptation. It feels like
such an easy problem to solve. You just go, well we'll just split on the @ and
then if it's got a dot on the right hand side and something of this kind of
alphanumeric character on the left hand side, we're fine, right? It feels so easy
but it's not it's never that easy. So my final recommendation for this week is by
Dave Poirier and it's called Swift Email Validator and one thing that I didn't
even realized till I read this readme is that you mentioned the email spec.
Well actually there are five email specs. Of course there are. There is RFC 8222047
5321 5322 for the stuff they forgot to put in 5321 and RFC 6531.
So yeah, this email addresses are notoriously difficult to validate and
most of the time you might just offload that functionality to your backend
server. You might just say take your iOS app or your Mac app, pass whatever the
input is back to your server. But if you do want to do some smart validation on
the client, I think the comprehensive nature of this package by Dave Poirier
is worth taking a look at. It certainly seems to be extremely
comprehensive. You can have email addresses that have IP addresses in them.
You can have email addresses that have IPv6 email addresses in them. And suddenly the can is open and the worms are
everywhere. Yes so yes do not do not try and write a regular expression to validate
email. You will get it wrong and I mean that doesn't even start to think about
all the internationalization character sets and all sorts of stuff. They're all
valid in email so yeah it's it's a difficult thing to do so maybe try this
package by Dave instead. That's Swift email validator by Dave Poirier. Nice.
Well at the very least you'll have someone to yell at if it doesn't work.
Great. Well I don't have a third, well I did have a third package but you sniped
that so I'm out. But I sniped it, yeah. So we will call that an episode and we
We'll see you back here in a couple of weeks.
- See you in two weeks, bye bye.
- See you then, bye bye.