216: ruff, uv, and Astral: Python tooling, much faster, with Rust
47:46 Share

Today we're talking with Charlie Marsh about Ruff, Astral, and UV. Mostly about UV, a tool that can be used in place of pip, pip tools, and virtualenv. Since it's written in Rust, it's really fast. This is kind of a theme with Charlie and Astral, using Rust to speed up the Python toolchain. If you only use pip or create virtual environments once in a while, it's probably not a big deal. But if you do it a lot, as I do, these speedups improve my day-to-day workflow.

Welcome to Test & Code. This episode is brought to you by HelloPyTest, the new fastest way to learn PyTest, and by the Python Test community. Find out more at courses.pythontest.com.

Today on Python Test, I've got Charlie Marsh, and I asked him on to talk about UV, but I kind of want to talk about... Actually, I don't even know if you pronounce UV UV, so we'll start with that, and then a little bit about Ruff and Astral. So, Charlie, first off, how do you pronounce it? Yeah, UV is right. No, UV is right. Your first instinct was correct. Don't worry. Okay. Let's back up a little bit. Yeah. Ruff isn't even that old. So...

Tell me the short version of your life from conception of Ruff to now. Yeah, no, of course. Well, I started working on Ruff in the summer of 2022, I think. I mean, you can look back at the commit history, but I think I did the first release, it was like a year and a half ago, maybe.

And at that point in time, I had most recently been working as a software engineer at a sort of computational biotech company. And I was in charge of broadly our software infrastructure. So we had a lot of Python code because we were doing scientific computing. And I'd just spent a lot of time with our tool chain. And that included linters, formatters, type checkers, also packaging tooling,

And when I left that job, I had this idea in my head for, could we build much faster Python tooling by leveraging Rust? Because this is something that I'd seen in some other programming ecosystems. It was a trend that was happening in the JavaScript ecosystem, for example. And I'd started to get exposed to Rust and the way that Rust and Python could be used together.

at that job and over the course of some of the things we were doing. So rough kind of started out as me away from me to test this hypothesis very concretely of like, could we build better Python tooling and what would it look like? And in the first version I released,

It was pretty bare bones. I think it supported, I should look back at some point, but I think it supported something like 20 rules. So it could parse Python source code. It could traverse it. It could do things like find unused imports. So it could do some analysis. But I was really focused on, am I convinced that this won't get much slower? So that you can build tools that do a lot of the same things, but are much, much faster. That's the thing I wanted to prove out.

And I released it, I think, maybe August of 2022. And it just grew really, really quickly. It turns out a lot of people cared about this and that the idea of faster tooling and more performant Python tooling really resonated with them. So we had a couple big projects for very early adopters, like Pydantic and FastAPI.

and Zulip. So, you know, that kind of gave the project a lot of momentum. And from there, I was just like,

I'm going to look at all the things that are preventing people from using this and just knock them out one by one. And we just kind of expanded the scope of the project, made it capable of doing more and more. And it just continued to grow very rapidly over the course of the year. Go ahead. Well, when I started looking at it, it was, to me, kind of like,

like it did some of what flake eight did some of the flake eight light i mean flake eight with no plugins um yeah yeah and uh but it was just like super fast so i even liked it for that but it's a lot more than that it's so even on the front page it says drop in parody for flake eight eyesword and black but that is just touching the surface isn't it you do yeah we have like

I don't know, somewhere between 700. We have over 700 rules. And so it can be used-- often when we see people migrating, they're replacing literally 10 or 20 tools with ROUGH. And it means they can get-- the flagship feature of ROUGH

The reason that I started working on it was performance. But it turns out there are a bunch of other things, some of which are intentional, some of which were sort of accidental, that also made it very appealing to people. And one was the fact that we just bundle more things together. So you can kind of learn this one tool and put this one tool in your

in your project, in your tool chain, instead of having to learn a bunch of disparate tools and figure out how to chain them together. So the fact that instead of-- iSort's a great project, but the fact that instead of learning how to use iSort, you can just add the iSort rules to your rough configuration, for a lot of people, that simplification is really, really helpful. So yeah, we've added a lot of things over time. We shipped--

support for formatting so we have like a black a largely black compatible formatter built in as rough format um and that we shipped in uh october i think um so a couple months ago um and uh that followed a lot of the same you know the same premise it was like black is a is a really amazing tool it's like

It's enormously popular. We're not necessarily trying to innovate right now on code style. What we're trying to do is build something that we think is like build something more performant and something that's kind of feels more unified for people. So instead of learning a linter and a formatter, they can use rough and rough can be your linter and your formatter in a way that feels familiar. Okay. So there's that. But how did that become a company?

So I started the company. The company is called Astral. And our goal is to build unified, high-performance Python tooling. So I announced the company just before PyCon last year, so in April. And part of what we want to do is just bring...

more energy and experimentation into Python tooling. And even bringing people who don't work on Python in, come convince them to come build a lot of great Python tooling. Those are all very intentional things for us.

Since then, we've grown the team. I guess we're eight people as of today. And we work on and maintain, obviously, Ruff and now also UV. And our goal for the future is to... We want to keep building out this kind of unified tooling. So our dream is you download this single binary that

bootstraps and installs Python for you, and then gives you everything you need to be productive with Python. So UV is some of the core packaging fundamentals of what that would be, like ways to install and manage dependencies. ROUGH is kind of like the linter and the formatter. We want to bring that all together into a cohesive experience. And from there--

build and sell services on top of the tooling that just integrate with it really well. The kind of natural next thing you would need when working with Python and using our tooling already. So I was going to put that off till later, but while we're at it, build and sell extra tooling around it. I was going to ask, all this work so far is open source.

How are you guys making money? We don't make any money right now. We are what you would call pre-revenue. We don't make any money. We're venture-backed. We have investors who have invested money into the company in return for ownership stakes. The vision is to build out this tooling and then...

use it as sort of like an entry point for people and a way to build and sell software that just integrates with it really well. And like, you know, in that world, like all our stuff remains open source and free and like no one has to pay for any of these things that we are doing. But, you know, the hope is that we can build services on top of the tooling

I don't know if we'll actually do any of these, but examples would be like, oh, a custom, we can do like package hosting, like private registries for companies that already pay for those. And they hosted on AWS or wherever else we could build our own version of that, right? That's really well integrated with our package manager, for example, or we could build like CI CD solutions that are really well integrated with rough and with the other tools that we build.

But the idea there would be like, try to build things that really like just work if you're already using our tooling and integrate with them really well. So like the incentive structure we want to have is that we want to be incentivized to like grow, invest in and build the open source in a very like holistic and genuine way and have that translate to, you know, services for enterprise users of our tooling that just integrate really well with it.

Yeah, I can imagine. Well, you didn't ask me, but I can imagine in the future, a portion being a consulting wing to have, you know, a company says, this is what we're doing now. I don't care what it does, but can you make it faster? Yeah, that's possible too. Yeah, yeah, yeah.

But that's kind of like the, you know, I don't have like, I'm, I'm, I'm very happy to like talk about like how the company works and stuff. Like, I just don't talk about it very often because I think it's not necessarily what people are interested in, but like, I, that's kind of like, that's kind of like our goal, right? It's like, we're using like our goal right now is to like build and invest in the open source. And then I think that creates really interesting opportunities for things that we can build on top of it or, you know, for enterprise users of the tooling. Yeah.

Well, yeah, mostly, partly I wanted to ask about this because I thought of a joke this morning. I was just curious if in your company, if you talk about your financial outlook, if those are astral projections.

Yeah. I do have a spreadsheet called astral projections. Yes. Yes. That's awesome. Yeah. The spreadsheet for our 2024 budget is called astral projections. Yeah. Thank you. I'm glad that you thought of that. I actually don't know if I ever told anyone that even internally, but yeah, I do make that joke myself. Okay. Good. Nice. Yeah. And we're good. This is crazy. This is a year, like just a year ago.

Your life is very different than a year and a half ago then. Oh, it's extremely different. Yeah. And a year and a half ago, I mean-- well, I also became a father. And so that's also really different. But a year and a half ago-- I mean, my whole career-- I've been a Python user for a very long time. Or I don't know. I'm not that old, I guess. But my whole career, I've worked at companies that ran on Python. I was at Khan Academy.

We were on App Engine. It was all Python. And then the company I was at most recently, it was also the computational biotech company I was talking about before. That was also all Python. And so I've been a Python user for a very long time, but I have not been a member of the community at all. And I also haven't really been a...

that involved an open source, right? Again, I've been a consumer of open source, but not really an active participant. And so like one of the biggest changes for me over the past year and a half has been like, I didn't know anyone in Python a year and a half ago. And I've had to really grow and learn, you know, obviously how to be a maintainer because now we have these projects that, you know, thankfully have a lot of activity. And so it's been a little bit of a trial by fire to learn, you know, how to be a good maintainer or a passable maintainer.

And then the other is just learning, meeting all the people in the Python ecosystem and learning

how the pep process works. And now I'm actually expected to participate in peps. And my people want me to chime in on things on the Python discussion forums. And that's all very, very new to me. So it's just very different. Yeah, my life's very, very different from where it was a year, year and a half ago. Well, head of a company, are you still coding? Yeah. Yeah, a lot. Okay. Yeah, which...

takes a honestly it takes a lot of um yeah i mean i have like a lot of other responsibilities right like um uh you know foremost to like the people who work at the company right making sure that like they're supported and

you know, that payroll works and that everything, you know, legal, all that kind of stuff. Like that's just a lot of responsibility, hiring, recruiting. But I sort of try and I guess I do some funny things with my schedule. Like I try and only do meetings really on like Tuesdays and Thursdays. And then that creates a lot of space for like Wednesdays, we don't do any meetings. So I can I just try and like chunk lots of like heads down time.

I don't know if I'll be able to code forever if we keep growing, unless I'm like really diligent about that being my priority. But but right now, yeah, I'm it's probably I try and have it the most of my time. Okay, so let's jump into UV. So UV is is what it's a it's pip and pip tools and virtual. Amp. Yeah, exactly. That's exactly right. Yeah. And this is something that

We started talking about doing this really at PyCon. So almost a year ago, we started talking about doing this internally. It was just three of us at the time. And I knew that I wanted to do something like that. I thought packaging could be a really important part of what we're doing because I just thought there were-- it's an area where people

uh just you know they feel frustration or i see frustration um and i thought there were at least opportunities to do something different so we started talking about this like almost a year ago and we were like to the to the amount of detail that we were like maybe this is what the first release would be this is what the second release would be etc etc but the thing that happened was like rough just um

It just needed so much of our time. And we decided to do the formatter and such. So we only started working on this really in October.

It's meant to be effectively a drop-in alternative for pip/tools/virtualenv. I wouldn't say it's-- if people on the show are familiar with Poetry or PDM, it's not quite at that level of abstraction right now. Those tools come with a pretty opinionated workflow, where you're doing Poetry Add, Poetry Lock, Poetry Sync.

In my mind, pip and pip tools kind of sit at this lower level of control. Like when you use pip, you're kind of doing these low level commands of like add this thing, install this thing, remove this thing. And that's the level that we're starting at. So if you right now like use pip a lot or pip tools or virtual web, like UV is really designed to be something that you could drop in and use in lieu of those. So it's, you know, like rough, it's a single tool that tries to do multiple things so that you can

focus on learning that interface rather than chaining together a bunch of different tools. And also, like Ruff, we designed the whole thing to be as fast as we could make it. So performance was a really big focus from the start. And a lot of the choices that we made were driven by, how can we make these things 10 times faster than the other things that exist out there right now?

So I feel pretty good about how that turned out. It's like really, really, really fast. And there are

There are some areas where it's not faster. And I have some thoughts about directions we want to take things in in the future to try and continue to change things and make them faster. But for example, if you need to build NumPy on your machine in order to install it, that's going to be as slow with UV as it would be with pip because we don't

we don't make like building numpy faster but um you know if it i guess maybe i didn't even know that that happened if i do a pip install numpy it sometimes builds on the client's machine sometimes so it depends so in python there's there's really two kinds of um like artifacts quote unquote that are um uploaded to pi pi and so when you pip and those are

source distributions and build distributions. A build distribution in Python is typically called a wheel. So if you've ever seen the .WHL or heard of a wheel, effectively what happens is as someone who like-- let's say I am the NumPy maintainer. I'm not, but imagine I was.

When I upload my NumPy release to PyPI, I can also pre-build it on a bunch of target architectures. So I could say, I'm going to build a version for Windows, for Mac, and for Linux, and I can upload those pre-built files to PyPI.

And then if you are on Windows and you try to pip install NumPy, it'll look and see, did they already upload a version that's built for my machine? And if there's a compatible version, it'll pull that and it doesn't have to build. If you're on a machine for which they didn't upload a compatible version, then your machine actually does have to build it.

build it from source. So that's why sometimes when you pip install things, they might fail for what looks like, oh, you were missing a native dependency. There's a lot of different reasons it could fail. But effectively, sometimes when you install things in Python, you have to build them yourself on your machine. And sometimes you don't.

And if you have to build something yourself on your machine, it's hard to make that much faster because that's basically something that's totally outside of the control of a tool like BIP for UV. So if you need to compile a NumPy from source on your machine, that's going to be the same speed. But we do a lot of fancy things to try and minimize that work, minimize the number of times that you have to build it.

uh yeah exactly right so so uh i think there's some interesting things we could think about doing there but like um not with not make gcc faster but like how can we leverage build artifacts in uh in more places um but um

But when we covered this on Python bytes, one of the one commenter said that

they were looking into what UV's doing. And one of the things that you're doing that's quite a bit different is it's a different approach to caching than... It's very different, yeah. ...PIP uses. So do you understand? Can you describe that? Yeah, I can describe how our cache works for sure. I can't describe PIP's cache as well, but I think I can describe some of the things that I think we do that they don't. I also...

So basically, the way to think about UV's cache is we kind of have a global store of all the packages that you have installed in any of your projects. And if you install the same dependency in two different projects,

What we'll generally do is instead of redownloading that thing and copying it into your virtual environment in the two different projects, we put the package in one place. And then we use various forms of symlinking and this thing called copy on write, which is a little different than symlinking, but you could think of it similarly. But effectively, if you have two projects that need Flask or need requests,

we'll have a single version of that that we stored in the cache. And then when we install it into those projects, we can just link it in instead of copying over all the artifacts or re-downloading it or anything like that. So this is good for a bunch of reasons. So one, it's really, really fast because creating those symlinks is just much, much faster than

copying the project multiple times or other work that you might have to do. The other is that it's a lot more space efficient because you no longer have to store a separate copy of requests in every project that you have. You're basically storing one copy and then linking to it from all the projects that need it. And those are the primary benefits, really. It's speed and disk space efficiency.

So it's making my virtual environments more lightweight than is also, right? It should be much more lightweight. Yeah. Yeah. So it's, you know, it's interesting because I think these are things that, yeah, I've talked to some pip maintainers and I think these are things that pip maintainers

is interested in doing in general. And there's some other package managers and other ecosystems that do some similar things. Like in the JavaScript ecosystem, there are package managers that kind of operate with a similar approach. And that's where some of the inspiration came from. But one cool thing could be the fact that we shipped this approach to caching

we might kind of like normalize that a little bit for users and that might, and the fact that we had to solve some of the technical problems associated with it could actually make it easier for pip to ship a similar thing in the future, which I think would be a cool outcome because, um,

I want everyone to use UV, of course, but PIP is also a foundational project in the ecosystem and used by, I would assume, millions and millions of people. So it's interesting to me to think about how are things that we've done, how can they be backported, or how can they change the status quo a little bit and enable PIP to pull some of them in too. Yeah. Well, so, okay, UV, where did the name come from? Um...

Well, it stands for ultraviolet. Okay. And we wanted some... It's not after that movie, is it? No. What movie? Okay. I didn't do my research. No, it's not. Okay. We liked it. We wanted something really short. Like, this is also something I thought about a lot with Ruff. Like, we're building tools

whose names people are typing a lot. And so like rough, I mean, I actually don't know if I have good typing form, but like when I type rough, I only need to use my two index fingers and it's, it's just really easy to type. It's very easy to come up with cool names that are actually kind of a pain to type. But I do think about stuff like that when I'm choosing the name, I'm like, how nice does it feel to type? Because like people are going to be typing this. If it's successful, we'll be typing it over and over and over. So like,

I like UV because it's extremely short and it's right next to the home row. Right. So it's very easy to type. Also index fingers. Yeah, it's also index fingers. So I want something that was for easy to type and distinctive. And I also kind of wanted, you know, we also wanted something that felt more attached to the astral brand because rough is

rough predated astral so the name rough it doesn't really there's no like thematic consistency between like rough and the company name astral but with uv there's at least like some kind of tie-ins between like ultraviolet and like astral at least like if you kind of squint vaguely so i don't want in there to be something i wanted to be something that felt a little bit more cohesive

So is rough an abbreviation? Is it like Rust Fest formatter or something? No, it doesn't really mean anything. Yeah, it's more like I looked at a bunch of words and I was like, what's a word that I could make here? And I was like, rough, like rust, like

Anyway, I don't know. So yeah, rough doesn't mean anything. No, no. And I kind of liked that it was like a pun, like it's a rough graph. That was something that I was kind of saying to myself at the time. Oh, nice. Yeah. I had some jokes about that in the early days, but I kind of moved on from them.

So one of the things that surprised me, there's a couple, a lot of things that surprised me about VUV so far. And both in a good way, some not, I guess nothing negative. It's just either. It's fine if it's negative, by the way. I'm sure you've heard it, but the amount of release, this is like a week old or something like that, or maybe two. Yeah.

It hasn't been around for very long. Yeah, a week and a half, I think. I think we did it. I think it was Thursday of like last last week. Yeah. Okay. So last last week. Yeah. Not last week, the week before, right? Yeah. There's been a lot of releases. There's been like a whole bunch of releases, which is cool. But is that?

it's gotta be a little bit hard to deal with or are you just happy? How many core people, you got eight people in your company, is everybody working on this or? - No, no. Well, so for the week after the release,

we kind of opened the door to, is anyone willing to come help us? Because we have a lot of issues, or there's a lot of activity. So we had a couple extra people. In general, it's been kind of four of us working on UV. And the rest on Ruff and associated projects around Ruff, like our editor integrations and such.

We've had a lot of releases. That will definitely slow down. I mean, it's kind of like the early days of rough. The early days of rough were even worse for users. Because sometimes I'd ship twice a day because there was something someone wanted and I'd decide, why not just get it out? The thing right now is it's very energizing to have users because we...

you know we developed this thing for a couple months in a private repo and like we did a bunch of testing and stuff but like it's just having users is very very different because people first of all it's just energizing to see people actually trying your thing and second of all like if they try it and they like they run into an issue it's probably actually like a very real bug that like we didn't know about right or we didn't see and so it's just very nice to be in the feedback loop of like

person's trying your project, they run into some problem, you fix it, and then they have a good experience because they try the new release and the stuff is working. So part of it is just energizing to have users and be back in the mode of shipping things just consistently. We'll definitely slow that down quite a bit once the project has stabilized.

GitHub says that you have 48 contributors. So there's other people outside your company contributing it as well, right? Yeah, yeah. That's in like a week too. Yeah. Yeah. Well, no, because when we released, there were only probably five contributors, maybe four or five. So those are all new. Yeah. But a week into it, you got 231 issues open. Is that stressful?

Are you just kind of used to it? No. Because Ruff's got like 681. No, I'm kind of used to it. Not to like-- No, no, no. It's fine. Having lots of issues isn't necessarily bad. I mean, issues means people are using it, right? OK. So if we had fewer issues than we received, I think I would be worried that people weren't really using it. At least is how I think about it.

But I think I'm not that stressed about it because most of them we know what kind of work is pretty well known. Like we kind of know what we need to do and it's just a matter of grinding through a lot of it. We closed like I think over 200 issues like over the course of the week.

over the course of the first week. Now I think it's at 150 something, because it's a rolling tally. But we closed a lot of stuff. Yeah, there's 544 closed issues right now. Yeah, I guess the week after the release, I guess it was stressful. There was definitely a lot of things we wanted to fix. And so we were basically trying to just fix them quickly.

So the two things that like tripped me up is the virtual env using the prompt dot not showing, not working right. And that was fixed. - I think we fixed that. - We fixed it even before I noticed it. It just wasn't. - I didn't fix that. Someone else did, but yeah, I think it was fixed quickly. - And then pip list, which I didn't even know pip. I'm just not normally using pip freeze. So I used pip list instead. So pip freeze worked right away.

pip list uh list now is now out i think yeah just like a few hours ago yeah yeah that was a contributor did that yeah um yeah so we're fixing yeah i want the i mean i do want the i do want the project to feel like you know when we ship something like like we worked on it very hard obviously but like

it's still kind of like the beginning of the project, not the end. So we should-- there's a bunch of bugs. But I want the feeling of the product should just be compoundingly getting better and better and more and more steep. Every time we close an issue and fix a bug,

That's just making the project better and stronger. So that's really been the focus for the past week. It's just been on correctness and fixing issues. Some of the questions around it, though, is because Ruff is new. It's a new name. People aren't expecting it to be anything. Since UV uses UVPIP and UVVNV, and I don't use PIP tools every day. I don't know what the UV command for PIP tools is.

We just use UV pip compile UV space, space compile. Yeah. But because you're using that, I think a lot of people are expecting their, their favorite corner feature to work. That wasn't the goal right away. And I'm, is it even the goal in you're, you're not trying to be a hundred percent compatible. Are you? No, we're not, we're not trying to be a hundred percent compatible, but we are trying to be like largely compatible and like for, for,

like the intention there and we've gotten a lot of feedback around this in both the positive and constructive

Some people think it makes a ton of sense and really like it. Some people think it's confusing and don't like it. And we're trying to figure out how we feel about it. But the intention of using pip as the subcommand was really to give an immediate sense for what the CLI looks like and what commands are supposed to be supported and how people are supposed to use it. If we had our own uvinstall command,

like, maybe we'll add that eventually. But then that could kind of do almost anything.

like poetry has a poetry install command. And that's really different than the pip's pip install command. Those just operate with very different semantics and mean very different things. And so the intention there was just to try and immediately convey, OK, if you run uv-pip install requests, it installs requests into the current virtual environment. And that's something that I was hoping would be immediately conveyed by the subcommand.

The goal is not to support every single flag of Pip, for example. Although we do support

We support a good number of them, but we're not going to support all of them. And I don't think we'll support every subcommand. The goal is more to kind of convey what's the scope of the interface and how does it generally work. And so that's why we did that. But yeah, it doesn't use pip under the hood or vm under the hood or anything like that, which I guess is another source of potential confusion. But one of the things that-- so I was watching the pip list thread a little bit.

And one of the comments that you had was, are people using pip list programmatically? Does the output need to be the same or can it just be something else? You were really watching the thread. Okay. Yeah. And I don't know what the result was. Did you decide? We did the same thing. Yeah, we did the same thing. You know, ask if it's compatible. Yeah, we did the same thing as pip. Yeah. Okay. Because some people probably do put it into pip.

tool chains or something. Yeah, and I think there wasn't-- I didn't have a strong reason to deviate from it. But part of the reason that we did this, by the way,

instead of having uv install right right we have like uv pip install like the main reason that we did that is because we want to add commands in the future that will probably be at the top level so like we we might add a uv install in the future but if we add that it'll work really differently than like than pip install and so we want to like retain space basically at the top level

to add this more opinionated workflow in the future. So we kind of scoped everything beneath these subcommands, which means we don't have to break them in the future. If we add our own UV install, we'll still have those commands available. So that was another part of the motivation for that.

And I have seen some blowback, at least from the sidelines of some people, like you said, some people saying, well, maybe you should have not used the word PIP. Yeah. But then there's also, is it even fair for a venture backed company to be taking over these projects? Yeah.

I've got my own opinions about that. But before I say anything, have you thought about that? Is that a consideration? Well, I think I would maybe object to the idea that we're taking over PIP, if that's maybe what's being suggested there. Because in my view...

I think perhaps maybe at least taking some of the, the, so if, since there's, there's UV there, if somebody wants to contribute to a project, they might want to consider contributing to UV rather than contributing to PIP or just say, I don't need to contribute it because they got money they can pay for.

Well, what I want is I want there to be-- and I really think there can be-- a symbiotic relationship between our projects and obviously in other open source projects, even if they are sometimes seen as competing or substitutable. So for example, it's similar with Ruff and Pylent.

we have a good relationship with the pilot project. And we sponsor one of the maintainers, for example. And if we need to make changes to our pilot rules, we'll often talk to them about it. Or if they're going to add rules to pilot, there's often dialogue between the tools. And from my perspective, part of the reason for that is

First of all, there's a lot of people who use Pylint. And a lot of people who use Roth use it alongside Pylint. And so I want there to be a healthy ecosystem of tools and in tooling. And so my goal or our goal is not to completely replace Pylint necessarily, because there's just a lot of projects that are going to keep using Pylint and that are using Pylint. And so I want to have a good...

ecosystem between these projects because I see them as somewhat symbiotic. And it's similar with, honestly, it's similar with pip. Like another thing that we can do is we can bring, you know, because we're kind of like a newer project and we don't have to

think as hard about-- like, pip and UV, we have a lot of overlapping goals, but also a lot of very different goals. Like, pip has to be totally rock solid. Like, pip's primary goal is it needs to be extremely stable. And I'm sorry, I shouldn't speak for the project. But my impression of the project and from talking to maintainers is the primary goal there is it needs to be rock solid and reliable. And it needs to work even for very old things often. It needs to work.

For us, we can make different trade-offs. There are things we can choose to support, and we're just in a different position around it. And so we can kind of experiment with things, and maybe that even funnels back into PIV. But we can also bring different perspectives to a lot of the packaging discourse. I actually think it's a good thing if the Python ecosystem has multiple viable package installers.

that are centered on a set of shared standards. I think that's actually a really healthy thing for the ecosystem. So I don't know, at least from my perspective, in a very genuine way, I want there to be a symbiotic relationship between the work that we're doing and the other projects in the Python ecosystem. And similarly, this is not something that I've done a good job of

like so far, but I think it is actually really important for us, which is that we need to make sure that our project is not tied to the success of the company.

Right? Because, and there are lots of other open source projects that do a very good job of this. But the idea of having a governance model and such that exists outside of the company and that could bribe even if the company doesn't, that's also something I think about quite a bit. So, I don't know. I'm not answering, I'm trying, I think I'm answering your question, but I'm kind of going about it by kind of conveying at least how I view that relationship. And

um i hope that it will be nothing but a good thing for the python ecosystem to have you know more more tools like this and more people that can spend time on them but but i totally understand that it's not um that it it does create um you know it could it could create tension yeah yeah well so far the uh interactions that i've seen through github issues and

And I guess posts on Mastodon even have been like you and other people involved in the project in, in Astral seem to be respectful to the people that are already in the community. And I have no, I have no evidence otherwise to, to doubt you. So, so far you seem like good citizens. I appreciate it. Well, I appreciate that. That's your impression. Cause it's certainly how I feel. I mean, like,

Pip is like, I don't know, at least in my opinion, at least like,

pretty incredible project. And I have a lot of respect for the people that have maintained it and worked on it. And that's basically my perspective on it. I'm not here to say that project is bad or something and ours is better. They're just different projects. And again, I think it's a good thing for the Python ecosystem to have multiple installers that are viable and built around a set of shared standards. And I actually think that the people who work on pip would agree with that.

But yeah, I guess one thing I would say to this point more broadly is I do generally feel... I think it's very possible for someone like me, for example, or a company to come in and build a bunch of stuff in Python and do things in a...

in a way that is like not um like respectful to the community and not like integrated in a genuine way like with the community and like first of all i don't want to be that and i don't feel i also don't feel that way and i'm also really grateful because i think the python community uh by and large has been extremely welcoming like i feel um

I don't know. That's just how I've felt. Like I said, I didn't really know anyone in this community a year and a half ago, and I've just felt a lot of...

positivity and respect and uh like good intentions from like pretty much all the interactions i have so i feel very fortunate that that's the case because i also think there's a world in which we came in people were really angry and hostile about it and um just not at all what i've experienced so um i i don't know i feel lucky about i mean not everyone is maybe not everyone is nice but like you know by and large like almost everyone is is is very nice about so

I am glad that that's the dynamic that we have. It's important that we, you know, we, we compare ourselves in the same way. Cool. What's next for Astro? Oh man. Oh, I mean like focus right now is just on fixing as many issues as possible.

That's a focus. There's going to be more tools that you're going to take over. We'll probably see another something out of you in at least a few years. Yeah, I mean, I think from here, I want the UV roadmap to be...

very public. I'm sure we'll do projects again in the future where they're private for a few months and then we drop them or whatever. But it is not my preferred way of working. I think there are good reasons to do that. But I would prefer that our roadmap for UV, at least, is now more public and that we can sketch it out in public and also get feedback on it in public. Those are all really good things. I think the thing that we want to do next

um for uv at least or probably the thing we'll do next to me is um we want to add support for

bootstrapping and managing your Python versions. So if you've used something like PyEmp before-- I've tried. Yeah, or I'm sure you-- or if you use Homebrew for this, there's a lot of different ways to manage how do you install Python. Conda is also an answer to that question. There's a lot of different ways to install Python.

But I would like UV to be capable of installing Python for you, and in particular, Python across different versions. So you could imagine that you just download UV, and then you run UV pip install on your project, and it actually downloads and installs Python and then downloads all the dependencies.

You didn't have to worry about, how do I get Python installed, or do I have the right Python version? I want UV to be capable of managing that too. So that's probably the next big feature, I would think, that we'll start working on. But it won't be this week. And then on the rough side, there's a couple-- I mean, I don't know.

The things I choose to share and don't share, it's always about managing expectations, I think. Because some of the things that we want to do is just going to take a long time. And I don't want people to say, oh, they're going to do x. But I think one thing that I do want to do on the rough side is we want to be investing more in our editor integrations. So we have a language server that powers our VS Code extension.

We think there's a bunch of interesting things we can do if we basically-- that language server is written in Python. But for a variety of reasons, we want to rewrite it in Rust and make it part of Ruff itself. Because right now, it's like a separate thing that kind of calls Ruff. But if it was built into Ruff, there's just a bunch of interesting stuff we could do around

persistent state in the server and making it more robust, making it possible to do analysis across multiple files at once. So investing more in the editor integrations was another big thing for this year. That's pretty cool.

Yeah. I'm just one of my to do lists on this year is to try to investigate more of the options in rough because it can do way more than it did a year ago. Yeah. Yeah, it's pretty cool. Well, thanks so much for your time, Charlie. And yeah, we'll talk later. Awesome. Thanks so much.

Thank you for listening and thank you to everyone who has supported the show through purchases of the courses, both Hello PyTest, the new fastest way to learn PyTest, and the complete PyTest course, if you'd like to really become an expert at PyTest. Both are available at courses.pythontest.com and there you can also join the Python test community. That's all for now. Now go out and test something.