Swift Package Indexing

So it's warm where you are? It is quite warm, yes. Summer has arrived. Well, it's been here for a while, but it clearly has.

We were just discussing the hardship of having to record a podcast in 33 degree heat with no windows open.

A problem that I do not have. Yeah, I mean, technically I could, so I'm recording this in the winter garden,

and I could, there is AC in here, but it feels like madness cooling this room down for an hour of recording.

I'll just sit through it and I'll try not to make any dripping noises while we record.

Well, it's been very nice here, but actually the last few days have been a little cooler.

It's kind of 15 degrees at the moment, which is very cool for this time of year.

Very pleasant weather to record a podcast in.

Definitely, yeah. More pleasant than here right now. Although I won't trade in general, I'll state that.

Sure, sure. But people are not here for a weather report. They're here for information.

What are people here for? They're not here for the sports, they're not here for the weather. This is confusing.

It confuses me why they're here too. It's possible they're not here. That is a possibility.

There's that, yes.

It's possible we're shouting into the void. But no, they're here for information on package index.

We just finished a new run of the Ready for Swift 6 testing using Xcode 16 Beta 4.

That kicked off just over a week ago and finished a couple of days ago.

I can see the line of packages that are showing zero data race errors is very slowly increasing.

It is and the errors are going down. This is a good trend, but I think we still haven't hit the compiler builds that iron out a fair number of these issues that are known, but just haven't arrived in the public betas yet.

I believe, I hope. We know about a couple of them. There's hope that this moves a bit faster.

We'll have to see how it goes, but at least the trend is right.

I think the main time that we'll see a big increase, if we see a big increase, but I think the main time that we'll see that is actually once Xcode 16 gets released.

Because that's when the rubber hits the road in terms of what the main adoption that people will do is after the release.

Suddenly, there will be increased activity, I think, around this because it'll become a much more real-world problem.

Of course, it's great having as many packages as possible pre-release with showing zero data race errors, but I think that's when we'll really see people step up the activity.

Yeah, it's pretty much still early adopters, isn't it?

Yeah.

The other thing I wanted to mention while we talk about this Swift 6 run, there is an issue we discovered and we're tracking this.

It's issue 3233. That's almost four threes there in the issue number. We're getting close.

We're reporting a slightly higher error count in some cases than there actually are.

We've reported this and it's believed to be related to pre-concurrency errors being counted when they shouldn't be.

Likely, there are pre-concurrency imports that should suppress any errors, but they might still be counted by the mechanism that we're using.

So there's an internal compiler diagnosis reporting that we're using to report these numbers.

We're not grepping through compiler output and counting errors that way.

There's actually a mechanism to output JSON with compiler diagnostics and that's counting these Swift 6 errors.

That's the number we're reporting and it looks like there might be a problem where this is over-reporting a slightly higher count.

We've seen at least two packages where you don't get any Swift 6 warnings and yet the number reported is one and three or something like that.

So it hopefully isn't a huge additional error count. That remains to be seen.

In the cases that we've seen, it hasn't been huge.

It certainly would prevent a package to be completely marked as error-free.

And that's the problem, isn't it?

That's that one number, but at least the error count number wouldn't be as dramatically impacted by that.

And if your package is affected by this, please do let us know.

It would be good to have a number of packages to investigate this with to make sure that this reporting lines up and we're reporting the thing that people also see when they build their packages.

And if you have any doubt around how we actually run the builds, the build commands, the actual build commands that we're running is logged at the top of the package, the build details page.

So if on the package page you click on the matrix, you go to the builds overview page and there you see the whole matrix, not just the condensed matrix, but every build that we make.

And if you click on a cell through there, you land on the builds detail page and there we list the actual build that we run and the build log.

And then you have all the details there to investigate further.

And if you have any questions, just ping us and we'll take a look or help you find your way around those details.

And while we're on the subject of data race safety and the user interface around data race safety, we just merged a change this afternoon that slightly changes the wording around the indicator we give for data race safety.

Yes or no on data race safety in a package.

It previously said safe from data race errors, which is a wonderful statement to be able to make, but we had some feedback, which made some really good points about the fact that all we're really doing there is we're saying that the Swift compiler is reporting zero data race safety errors.

And no matter how you fix your data race safety errors, by either fixing them by changing your code to become data race safe or by suppressing them with something like an unchecked sendable or something like that, we still confidently say or said safe from data race errors, which was a little bit misleading.

And it was good feedback.

So we've just deployed a change this afternoon that now just says zero data race safety errors, which is a much more accurate way of describing it.

And we've put a bit of information in the documentation around this feature.

So there's an extra question in the frequently asked questions on the Ready for Swift 6 page and a little bit more information around the conditions that we're making that claim under.

So just a little bit more accurate or a little bit less misleading, potentially.

Yeah, it's actually, I just thought about this and it might be interesting in the future to see if there might be a mode where you build and actually can make stronger guarantees by looking if there's any unsafe shenanigans going on.

And that might be interesting to see if that's actually possible to surface at some point as an extra label flag or something, a thing that gets reported up.

Because I think that would be a great guarantee to have, right?

If you're using packages that have no pre-concurrency imports or no unsafe sort of things, I wonder if that would be possible at some point.

We'll just grab the source code for unchecked.

Yeah, that'll work.

Ship it.

Yeah, join us for more ideas how to improve your projects.

Right. There is another interesting bit of news that I saw fly by. It's actually been a couple of weeks now.

I had this in the list of things to talk about for last time, but we ran long then.

And this is from Filippo Valzorda. I saw this on Masternode a while ago.

And I think Filippo is a former Google engineer and he's now maintaining security related open source projects written in Go.

So it's not quite a Swift topic, but I think it sort of relates to what we do over here in Swift land as well.

And he's sort of managed to get companies to pay him as an open source maintainer.

And I suppose that's given what he's doing, you know, like he's maintaining security related projects.

I think the most popular one is Age, which is a, I think, an encryption or a signing project.

I'm a bit hazy on the details, but I imagine that's probably an easier pitch to get someone to pay you for that maintenance.

But I wanted to bring this up because recently he published a blog post,

made an announcement that he's converted this into a bigger project, which he called GeoMIS.

And he's brought on board three other collaborators and they're maintaining now an ensemble of Go open source packages.

And I thought it was really interesting because it's a long standing thing.

I think we've even talked about this a couple of times on the podcast before.

How does open source get funded?

I mean, we're actually facing that problem or we have faced that problem. We're in a good place right now.

But it's not the common case. Right.

Everyone knows this XKCD comic where that lone person is maintaining critical infrastructure and is effectively doing it just for the fun of it.

There's no contractual obligation. There's certainly no financial commitment by anyone for this kind of work.

And nobody prepares you from the entitlement and abuse you'll get as well.

Yes. God forbid stuff breaks. Right. Then suddenly you have everyone's attention.

Yeah.

Not in a good way.

But, you know, every time that pops up, I wonder, is that the thing that might spark a bigger thing happening?

And then I wonder, well, how is the biggest thing ever going to happen?

What would that look like?

I'm kind of hopeful that at some point, either a person like Filippo with enough clout manages to bring this up and sort of set an example that's then perhaps followed.

Or maybe one or more companies with deep pockets set up sort of a foundation or something similar that will help fund open source projects, maybe in their area.

So maybe by language, maybe by topic. I don't know what a good model would be.

It feels like we're reaching the end of this process being workable, the way it's being run, that just people hope there's someone who doesn't need the financial support and can manage to maintain this open source software, which everyone uses.

But we're just cruising on luck here, you know, like all these security issues happen and it's not the fault of the people, it's just they're spread thin and they get exploited.

Right, last time, was it the XC thing where it was effectively social engineering that's exploiting the fact that someone is just spread too thin and is happy for someone to help.

And unless there's another mechanism that actually makes this a job, where it's seen as a proper responsibility and maintained, managed like a job, doesn't make it 100% guaranteed that nothing happens, but at least gives you a fighting chance.

Because the way this is working right now, I can't see this going on forever like this.

Well, I think you say you can't see it going on forever like this. Unfortunately, I think I can see it going on forever because it needs that there have been enough catastrophic situations caused by this kind of problem that I think if there was going to be a fundamental change, we might have seen a fundamental change.

And I'm not, I think this project that has been set up here is wonderful. And I hope and wish that we are at the end of what you say there. But I fear that we may not be because it's always going to be incredibly challenging to get a company to pay for something that they don't have to pay for.

And the fact of it is that they don't have to pay for these things. And you look back at history and you look at the outcomes of these catastrophic errors. And yes, there are significant impacts to them.

But everything always recovers and it goes back to the status quo. And by the time you'd get that funding request through, the panic's over, right? It's a fundamental problem, I think, with open source.

And also with the way that we structure open source is that quite often open source projects start up as somebody's little pet project and they generally develop something because they have a need or an interest in it themselves.

And then over time, if it becomes a successful open source project, then other people get involved. And sometimes what happens is that original maintainer no longer needs that project and kind of has mentally moved on from it.

But they are tied to this kind of open source project that they founded. And I think it can just be so difficult to organize funding around that. And you're right that security related open source projects are the most likely to get funded.

But I don't think it should only be the security related ones because there are enormous amount of product. I mean, you look at most Swift applications have some kind of dependency in them.

And they rely, probably rely quite heavily on at least one dependency to do what they do, whether it's a server side Swift one, whether it's an iOS or a Mac app.

And to make that decision to go, okay, well, I'm going to seek out the authors of this project and fund them.

And it's not, and what I'm not talking about here is small independent developers. I'm talking about big companies. So what that takes is a developer to say, we're really, we're really dependent on this project.

And then to raise that up in a big company to get money for it is not a trivial task. And so I think it's wonderful that they've managed to do this with the Go, I forget the name of the company, but the Go company that you were just talking about.

But I do fear that, I do fear for whether it's possible for that to become a sustainable model.

Yeah, I think some of it is around actually even pitching the thing and how would the transaction work, right?

Because I think many open source projects aren't even set up to invoice that kind of thing or companies, because you know how purchase processes work in companies, sometimes it's easier to get to sign up for a service, you know, through a website rather than to make a one-off purchase.

Some of it is just logistics around that kind of stuff. I do wonder if the increased sensitivity around software bill of materials might change that in some respect.

Because, and what that is, is a software bill of materials is a list of all the dependencies that are being used to assemble a software project. And that's gotten some attention.

I think it was even in the US somewhere, it's sort of like an official thing that's being looked at as a requirement, I think for government funded projects, which are obviously sensitive, especially in some areas around what's the input into the programs, software that's being built.

And that's appearing there might raise some awareness even in other projects, well, what is it actually we pull in? And that has changed over time.

So in the last iOS project that I was on, it was always a requirement to at least list all the open source projects in a view.

So that was a first step that didn't actually happen before. I think it was always sort of a requirement, but never happened. And obviously, listing them in a screen isn't really a high bar.

I mean, we're really just talking about giving credit, but it is a step towards raising awareness. Look, this is what we're using.

And then the next step is, well, we're using this for free, we have no contractual relationship to these vendors, because that's what they are, they're third party vendors that we're using.

And maybe if we want something from them, we should have one.

And that might change and maybe start that conversation at some point. And I guess it'll always have to be, you know, sort of like an app store for open source software that'll probably have to form at some point,

because no small third party library author will end up engaging with a big company and selling your maintenance or whatever.

However, that's going to work like it has to be some aggregator that gets stuff together and then funnels, you know, is sort of the place where funding ends up and then gets distributed through some key towards the library authors.

That's always in my mind. It can't be an end times end, you know, like end companies dealing with end maintainers and having all these relationships being formed.

Yeah, and that's the whole idea behind this company is that you're not dealing with that.

Exactly.

You're not dealing with, like the company signs up to, I'm going to support some open source projects, and then it's the company that's responsible for determining how to distribute that money, which is the right way to do it.

It's the right way to do it.

Yeah, absolutely.

And especially because I've come across situations where open source package authors, not specifically Swift, but open source authors, that step between not being able to accept money and being able to accept money, even if it's, you know, $1, is a huge step.

Yeah.

You've got to formalize your whole system for that.

You know, maybe you have to make a company.

Maybe you at least have to think about how that's going to work.

Does it have its own bank account?

Does it have, you know, all these questions are actually quite difficult, and it puts a lot of people who just got into it to write some open source code.

It puts quite a lot of, I've come across people who just don't want to deal with that at all, and therefore that's the end of it.

And that's fine.

But a concept like this is really good.

I just fear for it.

On the subject of displaying your acknowledgements for open source libraries that you're using in your iOS and Mac apps, there are several packages in the Swift Package Index that will help you do that.

Absolutely.

So one is called Act Now List, or I guess it's Act No List, but it's by Vincent Terrain, and that's been around for eight years.

So that's a very well-established project that will give you a view controller in an iOS application that will list all of your, gather all of the license agreements and then list them in a view controller.

There's also one called License P-List by Mayasuki Ono that seems to do the same thing.

I haven't used either of them, but I have manually put together that list many times in iOS apps.

Nice.

Yeah, is that a requirement or something?

I vaguely recall this.

It certainly was common recently, and stuff like that often doesn't happen on its own.

It is a requirement of the open source licenses, but the other problem is that nobody is enforcing that.

So it is purely based on your desire to do it rather than any kind of comeback from not doing it, because it's only the open source license agreements that you're breaking, which are very important, but there's no open source license police as far as I'm aware.

So no App Store requirement? I vaguely remember.

I don't think so.

Okay, I might misremember. I'm not reading those terms frequently enough to actually know.

If there is, it's certainly not something that the App Store review process actively checks for.

Well, how would they even, well, I guess, I mean, you could perhaps at some level, but that's just way in the weeds.

Yeah.

Right.

But yes, let's hope that you're right and I'm wrong.

There's always hope.

Well, you've sort of started the package recommendations already, I think. Are we at that stage?

We've had two unofficial package recommendations already.

It's a bumper bonus show.

But yes, I can kick us off with my first package for the day.

So my first package is called Easing by Pamel Sharanda.

And I really like this package.

It's a set of easing functions.

So this is things like ease in, ease out that you might be familiar with from animations.

But the package itself, as I understand it, is only providing the calculation.

So you can give it some values and it will give you an output based on those values using an easing function.

So, for example, you can say, give it a quadratic ease in and out equation.

And you can then use that method that it provides to apply to any property in a view.

So you can, for example, one of the sample codes that is in the readme file is taking a UI scroll view where the header is fully visible when the content offset is zero.

So you have a header at the top of your scroll view when it's scrolled to the top.

And as you scroll, when you get to 100 points of scrolling, it fades out over that point, which is easy enough to do in a linear fashion.

But it allows you to add an easing function to that calculation.

And so it's not something that you're just plugging into an animation framework.

It is something that you are taking control of yourself and saying, given this value, put it through this easing function.

And what's my actual value that I should be passing on to my user interface?

And I really like that. And there's a great set of very comprehensive set of easing functions here, including bouncing and elastic and obviously kind of easing in and out and all the rest of it, quadratic and sine and all the rest of it.

So lots and lots of different easing functions and a nice, interesting way to use them as well.

Nice. Is that like SwiftUI, UIKit, Multiplatform?

I think it will work with both because I think the example here was actually not even specific to...

I think it might be a UI view that they're dealing with here, but they're not specific.

It's really just the function.

The library is purely dealing with the numbers.

Yeah, exactly. And you can do with that what you want.

Interesting. Nice. Right.

My first package is called Swift Homomorphic Encryption and it's by Apple.

It's a mouthful. It's a very interesting package that was recently announced on Swift.org.

There's a blog post announcing it.

And I found that fascinating and I had to read it up a bit, a little, what this actually means, what this is about.

And it sounds like you can run this or that's what the claim of homomorphic encryption is, that you can encrypt something,

then run computations on it and then decrypt it and you get the same result as if you'd run the computation on the original data.

And what that means is you can send data to a service that then runs a computation and returns you a result.

And you're never actually revealing your data.

So it's not even temporarily decrypted on the host running the computation.

And you can imagine how useful that is in a cloud environment where you send something off to a server and you can't be sure where that's running.

And you wouldn't even want this to be just decrypted in RAM for the computation.

And this sounds a bit like magic and it's like, how can this even work?

And I read up a little on this.

So there are some caveats around this.

There are apparently different levels of homomorphic encryption and they determine what operations you can run and in some cases even how often.

And I guess that depends on how the pre-encoding of the data and the actual encryption of the data gets sort of, I mean, in my mind is mangled.

You have to be careful what operations you can run.

This is due to the mathematical background of this.

This deals with maps and similar regions and it's all quite complicated.

But in a nutshell, and I'll link to or we'll link to another blog post that explains this a little better in easier terms how this actually works.

But the concept really is this.

You can send stuff off that is pre-encrypted and can't be looked at and can't be computed with and then you get the results and you decrypt it and you get your result as if you'd run it locally.

I've actually tried this with the package.

And that's why if I sound a bit unsure how this works is because my attempts to actually make this work locally were sort of mixed.

And I'm not sure, I mean, one thing is for sure, I don't know what I'm doing.

So this package has all sorts of parameters that you can configure and the example has an encoding scheme set up and there's all sorts of knobs you can turn to set this up.

And I think this is mainly dealing with what kind of homomorphic encryption you're setting up to ensure what kind of operations you can support on the other end.

And I think that's what might be happening here.

So what I've tried is I took the example, I encrypted some numbers and then I added up the encrypted values and then I decrypted it.

And it seems to work for numbers that are small enough and bigger numbers look like they're overflowing or something.

There must be something happening with the decryption.

So they return wrong results but many of them, the small numbers actually do return correct results.

If you're listening to this and you actually know what's going on or what I did wrong, I'd be really interested to hear about this.

But I thought it would be really interesting to talk about this package and present it even though I didn't manage to work with it correctly because it's obviously a thing that works.

It's used by Apple in their live caller ID lookup feature in iOS 18.

So it's clearly user error that I'm not getting the right thing.

And I think it might be interesting, I thought it would be interesting to talk about it anyway, even though in my testing I can't quite grasp how this works.

But it's certainly a very, very interesting package and I love that it's been open sourced by Apple for us to play around.

I'm so glad that you tackled that one because I saw that blog post too and I read the first couple of paragraphs of it and thought this is a blog post for other people.

Yeah, I mean, I really was on the verge of just not talking about it, but I thought well, it can't be just because I can't deal with it that it shouldn't get a mention at least.

And there's also one thing I should mention that's absolutely a useful takeaway from this package, which actually has nothing to do with the package itself.

But it's something I learned and it's going to be useful for everyone.

And this is the experimental command to install a package executable.

Did you know this exists? So you can run swift package experimental dash install and then this does the same as build, but it puts the executable in your home directory in .swiftpm dash bin.

And if you add that to your path, you can then run the executable.

So it's effectively like mint. People might know this little tool that did the same thing.

Mint is a tool that is actually a swift executable that you once installed can use to install any swift executable from a package into your system.

And this is a experimental feature in .swiftpm.

So I thought at the very least one takeaway for this package might be for people that this exists.

Yes, I didn't know that exists. And that is a much needed, because there's no standard way to do it.

Yes, there's mint. Yes, you could also make yourself a brew package.

Some people just put a make file in there and have a make install or something like that.

But it's all very ad hoc at the moment.

And I'm very happy to see Swift tackle this problem because Swift command line tools are great.

And this is one of the problems with people using them.

Yeah, absolutely. Yeah. Yeah. I do tend to write more and more stuff as Swift commands like that used to be shell scripts.

And stuff like this will make it so much easier to bring that into a system and to easily update it and stuff like that.

So really nice.

The thing that did it for me is argument parser.

Argument parser is so good. Oh, yes. And so usable.

And so it's so trivial to make a little command line tool that behaves exactly how you would want it to behave with Swift argument parser.

That it takes a lot of that overhead away from creating that tool.

And I'm the same as you. I reach for Swift now where I would previously have reached for Ruby for that kind of stuff.

Yeah, absolutely.

Yet another bonus package recommendation there.

Argument parser.

My next package is called Cloak String Macro by Lucas Gergel.

And this, as you might imagine from the name, is a macro.

And so before I talk about this, I'll add a disclaimer, which is you should never put API keys in your binary.

So if you find yourself putting a constant string in your application that contains an API key, you are in inverted commas doing it wrong.

And yet at the same time, for those situations where you have to do that, this is a potential way to do it slightly more safely.

Like obviously, if you're putting an API key or any other secret in your application that ships as a binary onto someone's disk,

then it is at risk of being discovered. And you shouldn't do that for anything really, really important.

But there are also times when less important strings are necessary.

And the disadvantage of putting a string in there is there are lots of tools that can very easily gather all the strings out of a binary,

because of the way binaries are constructed, all the strings tend to be stuck together in a big strings block.

And it's very easy to just grab all the strings out.

And even if you do things like chop it up and store each different bit separately, like there's a big kind of code smell there.

But what this does is it takes with a macro, which is this is a great use of macro actually,

it takes your secret API key and splits it and produces a data struct that is initialized with bytes of data

and just makes that a whole lot harder to find, not impossible to find, should make sure that's very clear,

but certainly a lot more difficult to find, because it's no longer going to be in that strings block,

no longer going to be trivial to get it out of an application.

And so I certainly have come across situations where storing this kind of stuff in an application is the way to do it,

especially if normally it comes down to if you're doing something that requires an API that doesn't have an account system,

so you can't have a login where you could provide the keys on login, then this is normally where this happens.

Very nice. I believe we had a similar package in the recommendations in the past, but I think it's really...

Oh, did we?

Yeah, but I think it's nice to bring this up again and again,

because macros are really nice with these kinds of things, embedding stuff or adding functionality, that is really easy to add.

So that's CloakedStringMacro by Lukas Gergel.

Nice. My second package recommendation is called KeyColor by Anton Herstand.

And Anton's package is one of those that can be described with a simple image, which is unfortunate for a podcast.

But if you look at the readme, it'll be very clear what this does, because it does come with some images, really nice images.

So just to describe this as an image and below the image,

like there's an image of an orange on a blue background and below the orange are three colored dots.

And you see a yellow, you see a blue and you see a bit of a red because that's from the center of the orange.

So you can pick out dominant colors from an image via this package, which is really nice.

If, for instance, you want to frame it or, you know, pick up font colors that go with the image that you're annotating or something like that.

And if I remember correctly, you can also. Yeah, there's a certain number of colors you can choose.

It's not just one. There's a range of colors you can pick.

And I suppose that sort of intelligently picks, you know, the dominant colors, shifting them around a bit, depending on how many you pick.

So I think that's a really nice package because it's sort of a problem that might seem simple if you think about it, but then turns out probably really hard.

I remember trying way, way back to frame an image with the sort of corner colors.

So sort of like think of your music player where the album art sits in the center and then the whole background of the screen is sort of continuously.

And it seems like the album art is sort of crafted onto this color, you know, it all matches up.

And I tried taking like the average from all the corner pixels and it never quite looked quite right because, you know,

averages are problematic because they get shifted by one thing that's an outlier.

And then suddenly everything is kind of off.

And so a package that deals with that and looking, I mean, obviously the examples are picked to demonstrate the capabilities of the package,

but it'll be easy enough to try with a few images to see how well that works.

It's certainly something that's going to get you started if you want to do something like that.

We had a package just a couple of weeks ago on the podcast.

In fact, I think it might have been in the last episode, which was similar in it was the package BlurHash,

which would take a similar thing where it could make an image and create a mesh gradient.

All right.

Yes.

Gave you the essence of that image.

Yeah.

The essence of that image in a gradient.

So, yeah, there's lots of lots of techniques out there to get the right colors and to get the right mechanism to represent something that would look good with an image,

you know, and yeah, it's a good technique.

It's a clever technique.

Really nice.

Yeah.

So that's KeyColor by Anton Hest and...

Fabulous.

My last package is one that I also haven't looked at in detail yet,

but it's interesting enough that I want to at least give it a mention.

It's called Lightpack and it's written by Daniel Noskin.

And I really like the concept of what this does.

So there's a lot of things you can do with some of the open source and freely available large language models that are available,

like Lama, which I think is by Meta, and Gemma.

I'm not sure who Gemma is by, but I know it's also openly available.

And the description of this package is very simple.

It says run Lama 3.1 and Gemma 2 locally in your iOS and MacOS apps in three lines of code, open source, offline and private.

And that's a very compelling description for a package.

If you can ship something, obviously, we've got Apple Intelligence coming later this year or maybe next year.

And if you can ship something that uses this kind of large language model inside your application that doesn't need network connectivity and doesn't need API costs and all the rest of it,

there are lots of lots of uses for that in many applications.

The reason I'm a little unsure about this is that I'm not quite sure why you need an API key from this lightpack.run site, which Daniel is running.

Because if you look at the site, so it's at lightpack.run, there's very little information.

In fact, there's almost no information on the homepage about why you need an account, why you need an API key.

And so I have some questions around why an API key is necessary if it is on device and secure and private and all those things that it claims.

So I just have a question mark around why that's necessary, how that works.

But I think if this is something you're looking at wanting to do in your application, I would certainly give this a check out.

And just to be completely fair to Daniel, I think the most likely reason is that there's no information on the website is that it's just not there yet.

And there is an email address for Daniel at the bottom of the page.

And so if you are thinking of using it, I'm confident that he would respond to an email.

But yeah, I think it's a powerful idea. And if this is the way to do it, then yeah, I think this looks great.

Certainly, the code sample of using it is trivially simple.

Well, it has to require a download of the models, right? And aren't they huge?

Even in the Lama case, which I believe is smaller than normal, but...

And maybe that's what the API key is for. Maybe it's for downloading the models, possibly.

So there's a recommendation just with a little question mark on the end of it.

Great. Well, I don't have a third one today.

Well, then that's the end of the podcast.

That's the end of that, then.

Actually, I do have one more thing to say before we sign off today,

which is I'm planning to do something a little different with the production of this podcast.

So look out in your podcast player for whether this podcast may have chapters so that you can skip through the news into the package recommendations.

And potentially even between each package recommendation, we'll see how my experimentation goes.

If your podcast player is not showing any chapters, then it went badly.

Stay tuned.

But I'm certainly planning to do that with this podcast episode.

And if it works out from here on out.

So there's a bit of suspense that you will, you as the audience, already know the outcome of this that I don't yet know the outcome of.

But until then, until next time, we will say goodbye for now.

And we'll speak to you next time. Until next time. Bye bye. Bye bye.