Actually, I've got a little quiz for you. We have a quiz already, straight away? Well, yeah, we have a news quiz. Okay. It leads to news, I think. Okay. How do you add a package to a Swift package manifest? Can you, off the top of your head, give me the incantations you have to make to add a package? Well, yes I can, but only because I've been working on this thing to say. Because you've cheated, right? Yes, I have cheated. So what is it?
Because I think there's a, there's a, there's a part of it that you probably don't know, even, even though you've stared at this earlier this week. Okay. Okay. So you add the dot package clause in whatever the top area is, you find the top area, whether, where all the other package clauses are and you add one alongside it right? That's the technical, that's exactly what it says in the instructions. That's what it says in the docs, yep.
And then you find all of the other product areas and you've got a product. Yeah right, so that's the target dependencies, yeah right and there it's dot product and name and package goes in there. It's always, it's never quite clear which one it actually is, But even in the top section, that's, and what I'm alluding to is we've started some work around making package instructions easier. And it is actually quite easy if you're working in an
Xcode project because Xcode has some references for adding packages to your project. And even just by importing something, if you import a product that Xcode knows about via some mechanism, I think it's if it's in a package collection that you've added to your list of package collections Xcode knows about, then if you do an import statement of a product, it'll actually automatically add, do all the things that need to be done and add the package to your manifest. Now,
this only works if you have an Xcode project file. And if you're working in an actual Xcode project, this does not work if you are working on a on a pure Swift package. In that case, you actually need to go into the package manifest and add stuff. And for quite a while, we've had something to help you at least a little bit with that because even the package clause, the first thing you mentioned, adding the package dependency to the package clause, the top part of your package manifest,
even that is that line dot package. You're not done there because you need to specify what package version you actually want, right? And there's different variants of how you specify that. Typically it's from colon and then you give a start version and then from that start version, it picks the highest released version on the same major version. So if you do 1.0.0, it'll take any 1.xy version with the highest x and y possible. But there are a couple of other
variants of that and we do support that. For instance, if a package has a beta release, which would be a branch version that you're following, then it has a slightly different clause. And I think the clause is, and I don't even know, I'd have to look, I think it's branch colon and then the branch name. So honestly, just to interject on that, I've not done that manually since the Swift package index existed because we do have those
for the latest stable version and the latest default branch. And if there's a beta version, we have all of those ready. And I've not typed that in manually in a couple of years now. Stay Forever Yeah. But the thing is that we're working towards an adding and that was spawned by a little discussion on Mastodon where Matt Mazzucotti questioned whether it's actually useful to put installation instructions in your readme.
And a few people were quick to point out, well, it kind of is important because, because of these, you know, intricacies of, of what you need to add. And, you know, you might know the package name, you might not necessarily know the product name, and then, you know, you certainly want some instructions on what to add. And the thing we're looking to add, as triggered by that discussion, although we did have an issue in our list already, was to help with the second part of that, and
that is the product clause, or rather the product dependency in your target. And there we're looking, because we have all the information from the package manifest, so we know what products a package exports, so we can provide a selection dropdown UI element where you can pick the product that you want to add, and then we can write out the product clause that we need to copy,
at least help with that bit of it. And that's what this little quiz was about, you know, have this all in one place so that package authors can just point there rather than have this set up. And it will then automatically also always be up to date. So if you rename your products in your manifest, you don't need to worry about your readme going out of date and stuff like that. It'll all be almost up to date on that installation page. And I think that's a great
idea, especially the concept of being able to link to that. So at the moment, and it will continue to work this way, the "use this package" button on any package page does like a popover where it presents the information. If you're using Xcode, here's the URL that you paste into Xcode. And if you're using package.swift manifest, then here are and it will be the both the package clause
and the product clause as you say. The fact that that's a popover will remain but we will give people a mechanism to link directly to their package page with that already popped over so that you can link it as installation instructions in your package readme. Yeah that'd be really nice, really nice to have.
We also discussed - and this is not going to be in the first deploy of this feature - but we also discussed having a preview of a package manifest syntax highlighted with the code that you're kind of selecting with the by picking the version and the product in there too. Now I'm not sure how necessary that is, but it is the kind of thing that, especially for people just getting started with adding dependencies to pure Swift projects, that could be
helpful. Yeah, I think it would be really interesting to hear what people think because I believe we are... it's really hard to think back how weird that was adding a package dependency the first time because, I mean, even though I can't remember the syntax. I at least remember there's two things to do and roughly where to put them, and then there's enough scaffolding there to guide me. I couldn't type a package manifest,
just type it out for the life of me. I just couldn't. I always need a template. But I'd be really interested to hear if people think this is actually useful to see it in the context of a manifest, to see where stuff needs to go, or if that's just noise. It's hard to judge when you're sort of familiar enough with it. - And if we could take a look over in Apple's direction just for a second, I think Xcode being able to manipulate package manifest files better would be an amazing step forward.
- Oh yeah, yeah, definitely. I do vaguely remember there was talk about a Swift PM command, like add package that would then add it to the manifest. But I don't think that went anywhere. or I'm not sure what state that proposal is in, but it was talked about at least. - I just want Xcode to do it. - Yeah, yeah. Well, when I say Swift PM, I kind of assume that Xcode would gain that capability then also for pure Swift packages. It's always a bit weird.
Xcode is this thing that has this Xcode project kind of mechanism and then Swift PM kind of mechanism, and they're not the same. It's hard to really talk about it. It's almost like it has two different modes of operation in those contexts. It's kind of weird.
- And I had a standing prediction for a few years in IOS Dev Weekly just before the conference every year that my standing prediction was this would be the year that they would choose Xcode Project or package manifest file and just have one. And that hasn't happened yet, so I've stopped predicting it. - Yeah, well, for that to work, it would actually start, need to start supporting iOS apps and all that from a package manifest, right?
- That was where I thought they would, yeah, that's where I thought they would start going with it, but it does not seem to be the current, I mean, it may be the plan for the future, but it does not seem to be the current plan. - I mean, it has to at some point, right? I do wonder if that might happen in the context of a, there was a pitch, it's quite a while ago now, to redo the package manifest and do it in a, um, what's it called?
The builder, um, mechanism, you know, like the DSL mechanism to go away, you know, from this, um, struct that you fill in kind of mechanism to, uh, a, a builder DSL kind of mechanism. And I wonder if that might happen all at the same time, maybe for Swift six or something that, that, that format will change and then incorporate the other things at the same time. I don't know. But I do feel it's not ideal the way it is right now.
- So anyway, the good news is it will get a little bit easier if we, or should I say, when we deploy these improvements. - Yeah, definitely. - There's another thing which has been going on this week. At the end of, it was actually at the end of last week, that we submitted a pull request onto Swift.org with the first stage of an integration between some of the data coming out of the Swift package index and the official Swift.org website.
So this is something we've been working on for a little while now. And it's in pull request at the moment. So this is very much a kind of first step towards some kind of integration between the two sites. And the first thing that we're doing there is some package lists. So we've proposed a new page on Swift.org and it's in the top level menu as packages. And you can, in fact, you can actually see a mock-up or a prototype of what we are proposing to merge into the site.
If you go to the Swift.org open source project and look for the issue that was opened by me. And the very first title in that issue is a link to the hosted prototype that we've got. So it's a packages page, and on that page is a list of currently three sets of different packages. There's one called Community Showcase, which is going to link to packages that we mention here on this podcast.
And actually, this is, the reason I'm talking about this, one of the reasons is we would love to know if you write a newsletter or run a podcast or something like that where you talk about other people's Swift packages. And if you do, please get in touch.
You can get in touch via our Discord, which we'll link in the show notes, because we'd love to get more sources of people talking and writing about the package ecosystem and include those packages on the Community Showcase section of this new packages page. We then have a couple, and I think this will be expanded before the pull request is merged, a couple of lists based on keywords.
So we currently have packages that are referenced by the networking keyword and the testing keyword, but I think we're gonna potentially expand that a little bit more before we look at merging it. And of course, there will be a whole process of review before any of this gets merged.
So this is not just gonna go straight through, This is genuinely an open source pull request that's gonna go through to the site and we hope that it gets merged, but of course it may look different to what we proposed by the time that happens. - And of course the list would be changing, I mean not daily or anything, but they'd be on a refresh cycle of some sort, maybe a couple of weeks.
But the idea would be obviously that they, especially the categories are collecting packages that are good starting points for certain topics like networking and testing as the examples that would host packages there that you should take a look at if you're working in that realm. Something else I kind of thought of, but might be a nice section as I was preparing for the podcast, and that was highlighting packages that coincide with new language features.
So for instance, when Swift 5.9 comes out officially, I mean, obviously we're already using it, we're even already testing it, but it's in pre-release form. But it might be interesting to have a section about macro packages, for instance, when 5.9 officially comes out and more people will start adopting it. Obviously people are beginning to adopt it now, but I guess we're early days in the adoption curve. So in September, maybe there might be an interesting collection to have.
And then obviously, you know, other Swift languages, language versions will have other things. So stuff like that might be interesting as well for a section there. - We could definitely do that. And that could also be one of the, so the testing and networking tagged packages, they're not fully automated, but we do have a tool that will generate the data that goes into the Swift.org website for those two tags.
And anything that could go through our search system, So for example, we can now search on packages that have the macro product type in there. We could do a similar thing for really anything on that search criteria, couldn't we? - Yeah, yeah, definitely. I mean, it's a question, open question, how long those lists should be.
We probably need to sort and truncate at some point, but it's certainly easy to at least get started their list and then go through and apply some further selection criteria, I guess. So if you have, either if you do something yourself or if you know of somebody who is interested in talking about Swift packages, maybe a podcast that you listen to has a section or something like that where people can pick a package. Pick a package? It's a tongue twister.
Yeah, please do get in touch and we'll see if we can get something more structured together to do with how the Community Showcase packages are built up. Yeah, or even just for the podcast, let us know if... I mean, we do monitor new additions to the index or releases and stuff like that. But there's enough coming in now that it's easy to miss one or maybe not give it the attention it deserves. And a ping and a nudge
is a great way to highlight a package that is worth talking about. And then we discussed that one of the sections, I mean, obviously our podcast would also be a source of input for that community selection. So that's certainly a good way of getting something in. Yeah, absolutely. There's one thing I noticed looking at these lists, and I wonder if you feel the same. And I think I even mentioned this before. When I look at this networking packages, the first package is
Swift-neo. Then we have alarmofire, Pulse, Moya. It strikes me there's a, there's this weird inconsistency about Swift package names. We have a couple others that sprung out and I think it's, I got reminded because this is one of the few areas that I've seen multiple packages listed side by side and then it becomes more pronounced. Like we have combined Dash schedulers, all lowercase, Swift Dash, Snapshot Dash testing, all lowercase.
So we have a couple of packages that follow, I think it's Apple's guideline to have these package names that are lowercase and K-Bop case, you know, with dashes in between the words. Interestingly, the very first word in Swift Neo is, Swift Neo is an open source network application framework and Swift Neo there is spelled like Swift Data or Swift UI. It's Swift and then capital N I O. So apparently the actual package name is Swift Neo.
Like, like I just described in the Swift UI kind of spelling. It's weird to me that the. Identifier that is used in the package manifest is sort of like an identifier type label, you know, it's, it's almost as if something's leaking out that shouldn't be leaking out and the proper package name should be something else.
And I wonder if that's ever going to change, if there's ever going to be some sort of guideline, what the, what the name should be, but I, it strikes me as weird that these, these names pop up like this and, and we're not doing anything special, we're picking the package name here as it is defined in the package manifest and it could very well be something different. I'm a bit puzzled why it's been chosen like this. I don't know, do you feel the same or is that just me being OCD?
- Don't get me started. (both laughing) My biggest problem with all of this is why do we need Swift in the name? - Yes, yeah, yeah. - I mean, I can understand. So on GitHub, if you want your repository to be descriptive on GitHub, where it lives in an ecosystem of every possible language. I can understand it there. But why in the package name are we including the word Swift? I do not understand it. My personal preference would be to just use camel case. Sorry, not camel case, what they call it.
The one where every letter is capitalized. - Pascal case. - Pascal case, that's right. Yeah, my personal preference would be for Pascal case or something like that. But I don't really care what we pick as a community. You mentioned an Apple guideline. I'm not familiar with an Apple guideline. I'm only familiar with the way they've started to name all their packages. So maybe that's referencing a guideline I haven't seen. But it does seem to be hyphens and all lowercase.
But they all also include the word Swift, which baffles me. - I mean, by all means, call your repository Swift- if it's on GitHub and you really want to be sure that people don't stumble into your project thinking it's Rust or something.
But the package name, I mean, I mentioned this before, like if you look in your sidebar in Xcode and you look at dependencies, it's Swift-Swift-Swift- it's all Swift- and there's so much noise in there and you can't even tell at first glance what your dependencies are. And then there are the sort order because some actually start with S and they're mixed in with all the Swift ones. And it's, it's a huge mess.
And I understand why, why we've gone down this path to, to leak all this, you know, it's like, we're not naming. I mean, I know in Fortran, you used to, in your variable names, you'd have the type, you know, an integer type, I think started or ended with an I, um, and F for real, R for real and, and, you know, we're not doing that anymore because the type system can actually reflect that properly. But we're always tacking stuff into names when there's no need. It's bizarre. I don't like it.
Yeah. I forget what the convention was called, but I think that it was very popular in the C days and you would encode the type in your variable name. So the one I always remember is LPSZ and then a name, which was a long pointer to a string zero terminated. And then the name of your variable. And I agree, we don't do that anymore and that's a good thing. But that's weird. I thought everything was just "void* in C". Do you remember the naming convention name? I forgot.
But in C? No. Yeah, in C, where you did the LPSZ and I and whatever. No, no, no. I never really did that. I remember it in Fortran. Was it Hungarian? I think it might even have been required in Fortran. That's all I know. I only use C with proper variable names. I think it might have been Hungarian notation. I think that might have been the name of it, but I'm not sure. Somebody I'm sure is going to point out that I'm incorrect.
We'll be sure to follow up. The other thing we should just briefly talk about before we move onto package recommendations is our sponsors. So for quite a while now we've had the support of a couple of corporate sponsors. We've had both Stream and Emerge Tools, who have both very kindly supported the site for, I think, over a year now. In fact, yeah, way over a year. And they have been just wonderful. They believed in the project from the very beginning. And we thank them so much for
their support. But what we don't want to do is just have the same set of sponsors over and over again. And we want to keep the site a little bit fresh. We want to make sure that people coming to the site see different links every now and then. And so we've been in conversations with a couple of new companies who just went live with their sponsorships on the site last week. So those companies are Point Free and Telemetry Deck. So why don't you tell us a bit about those two companies.
Yeah so Point Free you might know Brandon Williams and Stephen Celis who are creating a great video series about architecture testing and more. It's a really great site, you should check it out. I use that stuff personally. They have lots of open source packages as well, so that's a really great place to check. Telemetry Deck is a service providing lightweight privacy focused analytics for apps and websites, so that's also a great place to check out. I think in particular recently there
was a change with Google Analytics not being supported anymore. I think you can't use it in the EU anymore. So that might be a good reason to look at Telemetry Deck to change your analytics on your website. I think just like with Stream and Emerge tools, the key thing about both of these new sponsors is they are part of this community. This is not some company that's just kind of
coming in looking for the eyeballs of iOS developers. I mean, I'm sure they would love it if you went and checked out what they do. But Stream, Emerge Tools, Telemetry Deck, and Point Free are all absolutely at the heart of this community as well. And that's really important to us because we want to, you know, we don't want to overload the site with advertising and that was something that we've been very keen to keep top of our minds since the beginning.
But we do have a little bit of advertising on the homepage. But I think it's better if that advertising comes from the community, and that's what we're trying to do here. It's also worth just noting that this is not any increase in the number of adverts or the amount of advertising or anything like that.
This is just rotating around some sponsors and we would love to have Stream and EmojTools back at some time in the future, and they would love to come back at some point, but we want to keep that cycle fresh. Yeah, definitely. I do think there's a real indie vibe there. I did mention Brandon and Steven. I should also mention Daniel Jiig, who's the creator of Telemetry Deck.
And these are, you know, just indie developers that have started these companies and they're now supporting us and that's just great. - And Lisa Figas as well is at Telemetry Deck too. - Right, yeah, sorry, I only knew of Daniel. - No problem. Yes, I've been doing most of the conversations with them. So yeah, thank you so much to our new sponsors And thank you also to our sponsors who are currently cycling out. So that's just a little bit of an update on the sponsorship of the site.
Of course, the other main sponsorship we have is we have GitHub sponsors. So if you can go to any of our open source repositories, there should be a button there for GitHub sponsors. Or on the site itself, just above the two advertisements is a button for how to support us on GitHub sponsors. And then of course the other sponsor that we have is Apple. And you can see all of that information on our supporters page, which is on the home page, linked from the menu bar on the home page of the site.
- There you go. - So thank you so much to all of everybody who keeps this project going. - Absolutely, thank you. - All right, let's do some recommendations. - Do you wanna kick us off? Let's start with a package called Color Toolbox. I'm continuing my theme of color-based packages from last episode. Color Toolbox by Ramon Torres. And this is, unlike the last one that I mentioned, this is not a color palette library. This is a individual color utility library.
So it provides, it's not a huge package. it's a kind of utility package. It will help you kind of shorthand a little bit of your color management code. And then probably one of the most useful things, which I am surprised that the standards, well, we talked about how complex color is last time, but also at the same time, it would be great to be able to bring in web hex colors into UI and NS colors and SwiftUI colors. And that's one of the things that this does.
You can also take a color and get a hex value out of it. But then it's got a couple of also useful little features like you can detect the contrast ratio, which is really useful when you're checking your site for accessibility. So you can check the WCAG contrast ratio of any color to any other color. And you can also, and this is something I really find very useful. you can lighten or darken a color by a certain amount. So you can say, make this color 20% lighter than it was previously.
And that's so useful for little things like, if you have like a header and you might want to have, to differentiate the background color of page or a view or something like that from the header, you can just lighten it or darken it a little bit. And that's a really nice way to get some subtlety in there. So it's a small package. It's the kind of thing that if you use it, it's only been developed for 22 days, so it's fairly new, but it might come in useful. And it's Color Toolbox by Ramon Torres.
- Nice. Right, my first pick is called File Monitor by Kris Simon. That's a really nice package. And what it does is monitor file system changes. So imagine you want to monitor a directory for any changes within, you know, like creations, deletions, and modifications of files, you can spin this up and then have a sort of a subscription or a callback to notify you of stuff that's happening. And it's really nice.
The thing that I noticed that I've found especially nice is that it supports Linux as well. And obviously you can imagine there might be some significant differences in doing this on Linux. believe there are. So this is a nice package if you have need for this both on macros and Linux. It's a very simple interface, you can try it out on a playground as well to get a feel for it. It works as advertised and it's a nice neat package giving you file system notifications
for whenever you need that. You know, might be doing some... I remember seeing this being used for instance, in Publish the other day where it's monitoring the file system for changes and then retrigger a build of the package. Publish obviously being a package to create a website and then you could automatically trigger rebuilds and then you would have to reload your page and all that. So that's perhaps a nice application for that if you're looking for for that sort of thing.
So that's File Monitor by Kris Simon. - Yeah, sounds useful. My next package continues a theme that I think I'm becoming, like I think it's becoming my thing on-- - Is it about colors? - It's not about colors, no. It's about having an amazing name for a package. Actually, it goes on to our discussion around Swift-lovercase uppercase. This does not have the word Swift in the name. And it instantly stood out to me as I need to know what that package does.
So the package is called Rearrange and it's by Matt Masigotti, who I think you mentioned earlier in the podcast actually. - I did, yeah. - So again, this is a small package that is dealing with extensions and utilities for making it easier to work with ranges. So NS range, NS text range. Matt says in the readme, it says it's particularly handy when used with the Cocoa text system. So the kind of thing you can do here with like an NS range, you can shift a range by a delta.
You can shift the start of a range. You can shift the end of a range. So you can very quickly, if you're, for example, as Matt mentions that if you're working with text, you might want to change the range of a selection of text and you might want to shrink it or shift it left or right. And then there are various other things you can do with NSTextRange and UITextRange and IndexSet and String.
And again, not a package that's going to be immediately useful to everybody, but I'm a sucker for a good name and this is a great name. - Nice. Yeah, Matt, he's here, he's there, he's everywhere. - He is, yes. He's actually a great supporter of the project as well. So it's nice to give him a shout out on the podcast. - Absolutely, yeah. Right, my second package is called Swift-Concurrency Extras. And it's a package by Point Free.
And disclosure, which we've just given you, Point Free are a sponsor, but anyone who's been following me knows I'm a huge Point Free fan and can hardly be surprised that I'm again mentioning a package of theirs. So here you go, Swift concurrency extras. This is a package they released just last week, I believe. And it's about testing asynchronous code, which is notoriously difficult.
There is sort of a motivational link that I'll add to the show notes where they've raised issues around testing, in particular, Swift concurrency code on the Swift forums that sort of spawned all their investigation into this. And they actually came up with a solution to deal with this.
And the problem is that it's, in a heavily concurrent system, it's difficult to do testing because you sort of need to assert on an order of tasks or an order of execution, which you don't really have because if it's concurrent, stuff can happen out of order. But that's really hard to assert on then.
And what they've done is they came up with something to actually use a serial executor in test context, so that everything really happens deterministically and you can actually rely on the order of the tests. So you're not actually changing your production code, that stays all the same, but you inject a serial executor that sort of then takes all the concurrency out of the equation and just execute stuff serially, as if you had only one single task and a single executor that's doing everything.
And that then allows you to assert on all the steps and have reason about the order in which things are happening. And in case that wasn't clear, this is really for testing only. You shouldn't be messing with this in production, obviously, because, you know, you'd screw, you'd screw over your concurrency system with that. And the repository comes with a really good example to illustrate why that is necessary, why you might want that, why you would need that.
Um, and it's not a convoluted example. You, you very easily end up in situations where it might appear to be working, but if you run a test often enough, it'll eventually fail and eventually isn't, isn't a large number, it can be tens or 20 or a hundred runs where it'll happen. And obviously that's, that's no good in CI. If every 10th run fails, that's, that's terrible because you'll always be chasing some odd failures. So this is a really great tool to be able to deal with that.
The package comes with a couple of other nice things, things that we're actually already using in the Swift package index, because they are structures that have actually published individually earlier on, and they've now pushed this into this package, and they're called actor isolated and lock isolated.
These are little wrappers around structs to make them safe for use in testing and to make them, to avoid race conditions in your testing when you're asserting on stuff that, you know, for instance, you have a variable that you want to save stuff into, and it's not living in a concurrency context. You could use lock_isolator to allow access to that struct without worrying about race conditions and stuff like that.
So this is a really nice package if you're into testing And if you're having trouble with testing of things that are heavily concurrent or making use of async/await. And that's called Swift Concurrency Extras by Point Free. - I think if there was a feature in Swift Package Manager where you could subscribe to every package from an organization, then Point Free would be added to the Swift Package Index manifest in that way. - Well, you're trolling me right now, right?
Because-- (laughing) - A little bit. - All right. I'm not gonna bite then. (laughing) - Okay, my final package for today is a SwiftUI package. And it's from Vansun Leung, and it's called SwiftUI-VPSwitch. And it's basically a replacement for the iOS style toggle, where you have a rounded kind of lozenge shape with a circle at one end and in one position it's on, and when you slide that across it into the other position, it's off.
And this is just a really nice implementation of a design style that I've seen all over the place actually. If you ever look through Dribbble or any of the design inspiration sites, you'll see this kind of effect quite often. And this is an implementation of it in SwiftUI. So imagine if you had, for example, a switch that was representing day mode and night mode.
You might have an image that at the top of the image represented a starry night sky, something like that, with maybe the moon in it or something similar to represent the concept of night. And on the bottom of the image, you could have a set of clouds and bright blue sky
something like that to represent a daytime toggle. And as you toggle the switch from on to off, what it does is it animates the background of the switch up and down to move between the day and the night states in the kind of viewport, the masking viewport of the switch itself. Hard to explain. Go and have a look at the readme. There's a beautiful animation there. I was just going to ask if it's in the readme because I had trouble following along.
Yeah, I got halfway through, Anil, I had to continue because I couldn't just stop it halfway. But also the best thing to look at here is just go and have a look at the readme. And it's the kind of thing that I think is a lovely little... I wouldn't advocate putting this kind of effect on every switch in your application. But if you've got a really important switch, then this is the kind of thing that can highlight how important that switch is. - Yeah, nice. Definitely need to check that out.
That sounded really interesting. - Yeah, go and have a look at the readme. So it's SwiftUI-VPSwitch by Vanson Leong. - Nice. Right, my third pick is called TLD Extract Swift by Marco Eidinger. Not sure why he put Swift in the name there, but otherwise the name gives away what it does. It's one of these packages. I picked it mainly to talk a bit about things that are deceptively simple. Not that it's overly complicated, but it's really easy to fall into this slight trap.
And what it does is it extracts the TLD top-level domain and the root domain and subdomain from a host name. And this package is recommended to you by the Ministry of How Hard Can It Be, right? because you just split by the dots and then take the last two elements, right? That's your root domain. Except greetings for example, .co.uk, right? Because that isn't the root domain, the last two, because that co.uk are considered as the root domain. So that's not a domain you can register.
And there's actually, I didn't know this, a public suffix list on the web that lists out and Japan has the same. There's .co.jp and Australia I think as well. Some countries have a second level of official domains under their national domain that they hand out. They're sort of, I don't know what you call them, like
like Lamented, you know, you can't freely get those domains there. And it's one of these things, right, it's very easy to not consider that when you're doing that sort of thing and then suddenly Co is your subdomain or rather your top domain and when it actually isn't because you've had enough by one error. The other thing this package has, it has a CI setup to actually refresh from from this public suffix list automatically.
So it does checks and I guess releases as well, if it changes and you can even run, if you use the package, you can run it yourself. So you can actually refresh this list on the fly. Not that I think it changes that often, but it's always nice to have this sort of thing considered because you can rely on this package to track any sort of changes there. So nice little package, TLD Extract Swift by Marco Eidinger.
When you first said the name of that package, I thought you said TLDR, but no, it's TLD. And that brings another episode of the podcast to an end. So we will be back in a couple of weeks. Please do let us know if you have any packages or ideas for sources of community package recommendations for our Swift.org community showcase. And yeah, we will be back in a couple of weeks. - Yeah, see you in two weeks. Bye bye. - See you then, bye bye.