216: ruff, uv, and Astral: Python tooling, much faster, with Rust
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 tool chain. 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 speed ups improve my day to day workflow.
Brian:Today on Python test, I've got Charlie Marsh, and I asked him on to talk about UV, but I kinda wanna talk about actually, I don't even know if you pronounce UV UV. So we'll we'll start with that and then, a little bit about ruff and astral. But so, Charlie, first off, like, how do you pronounce it?
Charlie:Yeah. UV is right. No. UV is right. Your first instinct was correct.
Charlie:Don't worry.
Brian:Okay. Let's back up a little bit. Yeah. Ruff isn't even that old. So, tell me that, like, the short version of, your life from conception of ruff to now?
Brian:Or
Charlie:Yeah. Yeah. No. Of course. Well, I started, I started working on ruff in, like, the summer of 2022, I think.
Charlie:I mean, you can look back at the commit history, but I think I think I did the first release. It was like a year and a half ago, maybe. And, you know, 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, you know, broadly, like, our software infrastructure. So we had, like, a lot of Python code because we were doing scientific computing.
Charlie:And, I'd just spent a lot of time with, our tool chain and that included like linters, formatters, type checkers, also like packaging tooling. And, when I left that job, one of the I had this sort of idea in my head for like, could we build much faster Python tooling by leveraging Rust? Because this is something that I'd seen in, like, some other programming ecosystems. It was a trend that was happening, like, in the in the JavaScript ecosystem, for example. And I'd started to get exposed to Rust and the way that, like, Rust and Python could be used together, at that job and over the course of some of the things we were doing.
Charlie:So, Ruff kind of started out as me a way for 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 it was pretty bare bones. Like, I think it supported, I should look back at some point, but I think it's important something like 20 rules. So it could, like, it could, like, parse Python source code. It could, like, traverse it.
Charlie:It could do things like find unused imports. So So it could do like some analysis. But I was really focused on, like, am I convinced that, like, this won't get much slower? Right? So like that, that you can build tools that do a lot of the same things, but are much, much faster.
Charlie:That's the thing I wanted to prove out. And they released it, I think maybe like August of 2022. And, it just grew really, really quickly. It turned out 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, you know, we had a couple, a couple big projects for very early adopters, like, like Pydantic and FastAPI, and Zulip.
Charlie:So, you know, that kind of gave the project a lot of, 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 just knock them out 1 by 1. 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, you know, very rapidly over the course of the year.
Brian:In Well, when I when I started use looking at it, it it was, to me, kinda like like, it did some of what flake 8 did, some of the flake 8 lite. I mean, flake 8 with no plug ins. Yeah. Yeah. And, but it was just, like, super fast.
Brian: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 parity for flak8, eyesort in black, but that is just touching the surface, isn't it? You do.
Charlie:Yeah. We have like, I don't know, like somewhere between like 700, some we have like over 700 rules. And so, it can be used, like often when we see people migrating, they're, they're going from they're, they're replacing like, like, literally like 10 or 20 tools, with ruff. And it means they can get like, you know, like, the sort of the flagship feature of ruff that the reason that I started working on it was performance. But it turns out there are like a bunch of other things, some of which are intentional, some of which were sort of, like, accidental that also made it very appealing to people.
Charlie: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, you know, 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 like the fact that instead of, you know, isort is a great project, but the fact that instead of learning how to use isort, you can just add the isort rules to your ruff configuration. For a lot of people, that simplification is really, really helpful. So, yeah, we've we've added a lot of things over time.
Charlie:We shipped support for formatting. So we have, like, a black a largely black compatible formatter built in as ruff format. And that we shipped in October, I think. So a couple of months ago. And, that followed a lot of the same, you know, the same premise.
Charlie:It was like black is a is a really amazing tool. It's like it has like, it's enormously popular. We're not necessarily trying to innovate right now on, like, 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 ruff and ruff can be your linter and your formatter in a way that feels familiar.
Brian:Okay. So So there's that, but how did that become a company?
Charlie:So I started I started the company, the company is called Astral. And, our, our goal is to build, unified, high performance Python tooling. So I announced the company, like, just before PyCon last year. So, like, in April. And, you know, part of what we want to do is just, like, bring more, like, energy and experimentation into, like, Python tooling.
Charlie:And, know, even like bringing people who don't work on Python and like come convince them to come like build a lot of great Python tooling. Like those are all very intentional things for us. And, we've grown you know, since then we've grown the team, we're like, I guess, we're 8 people as of today. And we we work on and maintain obviously ruff and now also UV. And our, you know, our goal for the future is to, we want to keep building out this kind of unified tooling.
Charlie:So our dream is like you download this single binary that bootstraps and installs Python for you, and then gives you like everything you need to be productive with Python. So, UV is like some of the core packaging fundamentals of what that would be, like ways to install and manage dependencies. Roth is kind of like the linter and the formatter. We want to kind of all bring that all together into, like, a cohesive experience. Okay.
Charlie: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 I
Brian:was gonna ask I was gonna put that off till later, but while we're at it, build and sell extra tooling around it. I was gonna ask, like, you're all this work so far is open source. Yeah. How are you guys making money? Or how We
Charlie:don't make any money right now. Yeah. So we we are we are what you would call free revenue, so we don't make any money. And we're venture we're venture backed. So we have investors, right, who have invested money into the company in return for ownership stakes.
Charlie:And, you know, the vision is to, like, build out this tooling and then, use it as sort of like an entry point for people, in 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 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. You know, 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, you know, they hosted on AWS or wherever else.
Charlie: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 CICD solutions that are really well integrated with with Raf 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.
Brian:Yeah. I can imagine. Well, you didn't ask me, but I can imagine in the future, a 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?
Charlie:Yeah. That's possible too. Yeah. Yeah. Yeah.
Charlie: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.
Charlie:And then I think that creates really interesting opportunities for things that we can build on top of it or, you know, for enterprise user users of the tooling.
Brian:Well, yeah, mostly partly, I wanted to ask about this because I thought of a joke this morning, of I was just curious if if in your company, if you talk about your financial, outlook, if if those are astral projections.
Charlie:Yeah. I do have a spreadsheet called astral projections. Yes. You do? Yes.
Brian:That's awesome.
Charlie:The spreadsheet for our 2024 budget is called astral projections. Yeah. Thank you. I'm glad that you thought of that. That's I don't know.
Charlie:I actually don't know if I ever told anyone that even internally. But yeah, I do make that joke myself. Okay. Good.
Brian:Yeah. Nice.
Charlie:Yeah. And we're good.
Brian:This is crazy. This is a year like, just a your your life is very different than a year and a half ago then.
Charlie:Oh, it's extremely different. Yeah. And a year and a half ago I mean, well, I also became a father. And so that was also really different. But like a year and a half ago, I mean, you know, like my whole career, you know, I've been a Python user for a very long time, or I don't know, I'm not that old, I guess.
Charlie:But you know, my whole career I've used I've, I've worked at companies that ran on Python. Like, I was at Khan Academy. We were on, like, App Engine. It was, like, all Python. Okay.
Charlie:And then, you know, the company I was at most recently, it was also, like, the computational biotech company I was talking about before. That was also all Python. And so I've been like a Python user for a very long time, but I have not been a member of the community, like, at all. And I also haven't really been that involved in open source. Right?
Charlie: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 I've 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, you know, meeting all the people in the Python ecosystem and learning, you know, how, like, the PEP process works.
Charlie:And, you know, now I'm, like, actually expected to, you know, participate in in in PEPs and, like and, like, my people want me to chime in on things on the Python discussion forums and like, that's all very, very new to me. So, it's been, it's just very different. Yeah. My life's very, very different from where it was, you know, a
Brian:year, a year and a half ago. Well, head
Charlie:of a company, are you still coding?
Brian:Yeah. Yeah.
Charlie:A lot. Yeah. Which takes a honestly, it takes a lot of yeah. I mean, I have, like, a lot of other responsibilities. Right?
Charlie:Like, you know, foremost to, like, the people who work at the company, right, making sure that, like, they're supported and, you know, the 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 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?
Charlie: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 it's I I try and have it be hours of most of my time.
Brian:Okay. So let's jump into UV. So UV is, is what? It's, it's PIP and PIP tools and Yep. Virtualenv.
Charlie:Is that Exactly. That's exactly right. Yeah. And this is something that we started talking about doing this, like really at PyCon. So, like, almost a year ago, we started talking about doing this, internally.
Charlie:It was just 3 of us at the time. And like, I knew that I wanted to do something like that something I thought packaging could be really important part of what we're doing, because I just thought there were, it's an area where people just, you know, they feel frustration or I see frustration. 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, etcetera, etcetera.
Brian:But the
Charlie:thing that happened was, like, ruff just was it just needed so much of our time. And and we decided to do the formatter and such. So we only started working on this really in, like, October. Wow. And, you know, it's it's meant to be effectively like a drop in alternative for PIP PIP tools virtualenv.
Charlie:So that, you know, it's not I wouldn't say it's, you know, if people on the show are familiar with like Poetry or PDM, like it's not quite at that level of abstraction right now. Like those are pretty those tools come with like a pretty opinionated workflow, right? Where you're doing like 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.
Charlie:And that's the level that we're starting at. So if you right now, like, use PIP, blot or PIP tools or virtualenv, 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 ruff, it's a single tool that tries to do multiple things so that you can focus on like learning that interface rather than chaining together a bunch of different tools. And also like ruff, it's, you know, we designed the whole thing to be as fast as we could make it. So like performance was a really big focus from the start.
Charlie:And, you know, a lot of the choices that we made were driven by how can you make this thing 10 times faster than like 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 things there are some areas where it's not faster. And I have like some thoughts about like, you know, directions we want to take things in in the future to try and try and, like, continue to change things and make them faster.
Charlie:But, like, for example, like, if you need to build, like, NumPy on your machine in order to install it, like, that's going to be as slow with PIP with UV as it would be with PIP because, like, we don't make, like, building NumPy faster. But, you know, if it I
Brian: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.
Charlie:Sometimes. So it depends. So in Python, there's there's really 2 kinds of, like, artifacts, quote unquote, that are uploaded to PyPI. And so when you pip and and those are, source distributions and build distributions. A build distribution in pipelines typically called a wheel.
Charlie:So, if you ever seen the dot WHL or heard of a wheel, effectively what happens is as as someone who, like, let's say I am the NumPy maintainer, I'm not, but like imagine I was, when I upload my NumPy release to PyPI, I can also, like, pre build it on a bunch of target architectures. So I could say I'm gonna build a version for Windows, for Mac, and for Linux, and I can upload those prebuilt, 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 like a version that's built for my machine? And if they 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.
Charlie:So that's why sometimes when you pip install things, they might fail for what looks like, oh, you were missing a native dependency or, you know, there's a lot of different reasons it could fail, but, 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 the preview. So like if you need to compile NumPy from source on your machine, like, that's still going to be that's going to be the same speed. But, like 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.
Brian:Yeah. Sure. While you're at it, can you just go ahead and make GCC faster?
Charlie:Yeah, exactly. Right. So, so, I think there is some interesting things you could think about doing there, but like, not with not make GCC faster, but, like, how can we leverage build artifacts in, in more places? But, but
Brian:When when we covered this on, Python bytes, one of the, one commenter said that, they were looking into what UV is doing. And one of the things that you're doing that's quite a bit different is is it's a different approach to caching than
Charlie:It's very different. Yeah.
Brian:PIP uses. So can do you to understand do can you describe that? Or
Charlie:I yeah. I can describe how our cache works for sure. I can't describe PIP 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 ruffs cache, or sorry, pips cash is we kind of have like a global store of all the packages that you have installed on in any of your projects. And if you install the same dependency in, like, 2 different projects, what we'll generally do is instead of, like, redownloading that thing and, like, copying it into your virtual environment in, like, the 2 different projects, we put the package in one place and then we use various forms of, like, SIM linking, and, this thing called copy on write, which is a little a little different than sim linking, but you could think of it similarly.
Charlie:But effectively, you know, if you have 2 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 kind of just link it in instead of copying over all the artifacts or redownloading it or anything like that. So this is good for a bunch of reasons. So one, it's really, really fast because like creating those symlinks, is just much, much faster than like copying the project multiple times or other work that you might have to do. The other is that it's like a lot more space efficient, because you no longer have to store, like, a separate copy of requests in, like, every project that you have.
Charlie:You're basically storing one copy and then linking to it from all the projects that need it. And, so those are the primary benefits, really. It's like it's speed and disk space efficiency.
Brian:So it's making my virtual environments more lightweight than is also. Right? It should
Charlie:be much more lightweight. Yeah. That's cool. Yeah. So it's, you know, it's interesting because I think these are things that, you know, I've talked to some PIP maintainers, and I think these are things that PIP is interested in doing in general.
Charlie:And there's like some other package managers and other ecosystems that do some similar things. Like, 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, like, one cool thing could be, you know, the fact that we shipped this approach to caching. We might kind of like normalize that a little bit for users.
Charlie: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, you know, I want everyone to use UV, of course, but, like, PIP is also a foundational project in the in the ecosystem and and used by, I would assume, millions and millions of people. So, it's 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 to pull some of them into.
Brian:Yeah. Well so okay. UV, where did the name come from?
Charlie:Well, it stands for ultraviolet. Okay. And we wanted some.
Brian:It's not after that. That movie, is it?
Charlie:No. I don't what movie? Okay. I didn't do my research. No.
Charlie:It's not.
Brian:Okay.
Charlie:We liked it. We wanted something really short. Like, this is also something I thought about a lot with Raf. Like, we're building tools whose names people are typing a lot. And so, like, ruff I mean, I actually don't know if I have good typing form, but, like, when I type ruff, I only need to use my 2 index fingers, and it's it's just really easy to type.
Charlie:It's very easy to come 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 gonna be typing this. If it's successful, people will be typing it over and over and over.
Charlie: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.
Brian:It's also index fingers.
Charlie: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 Ruff Ruff predated Astral. So the name Ruff, it doesn't really there's no, like, thematic consistency between, like, Ruff and the company name Astral.
Charlie: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 them there to be something. I wanted there to be something that felt a little bit more cohesive.
Brian:So is is ruff an abbreviation? Is it like rust fast format or something?
Charlie:No. It doesn't really mean anything. Yeah. It's more like 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, ruff, like rust, like anyway, I don't know.
Charlie:So, yeah, the ruff doesn't make anything. No. No. And I kinda liked that it was like a pun. Like, it's a rough draft.
Charlie:That was, like, something that I was, like, kinda saying to myself at the time.
Brian:Oh, nice.
Charlie:Yeah. Had some jokes about that in the early days, but I kinda moved on from them.
Brian:Well, so Vuev so one of the things that surprised me there's a couple a lot of things that surprised me about uv so far. And and both in a good way, some not I guess, nothing negative. It's just
Charlie:either It's it's it's fine if it's negative, by the way.
Brian:I'm sure you've heard it. But, the amount of release this is, like, a week old or something like that or maybe 2. It hasn't been around for very long.
Charlie:Yeah. Week and a half, I think. I think we did it. I think it was Thursday of the of of, like, last last week. Yeah.
Brian:Okay. So, last last week. Yeah. Sure.
Charlie:Not last week. The week before. Right?
Brian:Yep. There's been Lot
Charlie:of releases. Been, like,
Brian:a whole bunch of releases and which is cool. But is that it's gotta be a little bit hard to deal with, or are you just, just happy? How many how many core peep you got 8 people in your company. Is everybody working on this? Or
Charlie:no. No. Okay. Well, so for the week after the release, we kind of opened the door to, like, is anyone willing to come help us because we have, like, a lot of issues or there's a lot of activity. So we had a couple extra people.
Charlie:In general, it's been kind of 4 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 ruff, like the early days of ruff were even worse for users. I think because sometimes I'd ship twice a day because, like, there was something someone wanted and I decide, why not just get it out? Like, the thing that the thing right now is, like, it's just it's very energizing to have users because we, you know, we developed this thing for a couple months in a private repo.
Charlie: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 a project, they run into some problem, you fix it, and then they have a good experience because they try the new release and, like, the, you know, the stuff is working. So, like, part of it is just it's just energizing to, like, have users and be back in the form of in the mode of, like, shipping things just consistently, we'll definitely slow that down quite a bit once the project has stabilized.
Brian:Well, GitHub says that you have 4848 contributors, so there's other people outside your company contributing it as well. Right?
Charlie:Yeah. Yeah. That's in, like, a week too. Yeah. Yeah.
Charlie:Well, no. Because when we released, there were only probably 5 contributors, maybe 4 or 5. So those are all new. Yeah.
Brian:But, week into it, you got 231 issues open. Is that stressful? Or you're just kinda used to it? Because ruffs
Charlie:got, like used to it.
Brian:681. Not to, like
Charlie:No. No. No. It's fine. Having lots of issues isn't necessarily bad.
Charlie:I mean, issues issues means people are using it. Right? So if we had fewer issues than we received, I think I would be worried that people aren'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.
Charlie:Like, we kind of know what we need to do. And it's just a matter of grinding through a lot of it. We we closed, like, I think, over 200 issues, like, over the course of the week, over the course of the 1st week. Now I think it's at 150 something because it's a rolling it's a rolling tally. But, like, we close a lot of stuff.
Charlie:Yeah.
Brian:There's 544 closed dishes right now. That's
Charlie:Yeah. Like the the we just, yeah. I guess the week after the release, I guess it was stressful. There was definitely, like, a lot of things I want we wanted to fix. And so we were basically trying to just fix them quickly.
Charlie:And
Brian:So the 2 things that I that, like, tripped me up is the, the virtualenv, using the, prompt dot not showing not working right, and that was fixed.
Charlie:I think we fixed that. Yeah.
Brian:You fixed it even before I noticed it.
Charlie:It just wasn't I didn't fix that. Someone else did.
Brian:But, yeah, I think
Charlie:it was fixed quickly.
Brian:And then, and then PIP list, which, I didn't even know pip I don't I'm just not normally using pip freeze, so I use pip list instead. So pip freeze worked right away. Pip list.
Charlie:Pip list now is now out, I think.
Brian:Yeah. Just like As
Charlie:of today. A
Brian:few hours ago.
Charlie:Yeah. Yeah. Yeah. That was a a contributor did that. Yeah.
Brian:So.
Charlie: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, like, not the end. Right? So, like, we ship something, like, there's a bunch of bugs and, like but I want the feeling of, like, the product should just be compoundingly getting, like, better and better and more and more steep.
Charlie:Right? Like, every time we close an issue and fix a bug, like, that's just making the project, like, better and stronger. So that's really been the focus for the past week. It's just been on, like, correctness and fixing issues.
Brian:The well, some of the questions around it, though, is because ruff was ruff is new. Like, that's a new name. People aren't expecting it to be anything. Since uv uses uv pip and uv venv , and does it use I don't I don't use pip-tools every day. I don't know what the uv command for pip tools is.
Charlie:We just use uv pip compile. uv space pip space compile. Yeah.
Brian: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 100% compatible, are you?
Charlie:You? No. We're not we're not trying to be a 100% compatible. But we are trying to be, like, largely compatible. And, like, for, like, the intention there and we've gotten a lot of feedback around this in both the positive and constructive event.
Charlie:Like, 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 kind of trying to figure out, like, how we feel about it. But the intention of using pip as the subcommand was really to give an immediate sense for, like, how the c what the CLI looks like and, like, what commands are supposed to be supported and how people are supposed to use it. Like, if we had our own UV install command, like, maybe we'll have that eventually, but, like, then that could kinda do on, like, almost anything.
Charlie:Like like, poetry has, like, a poetry install command, and, like, that's really different than, like, pip the pips pip install command. Like, those just operate with very different semantics and mean very different things. And so the intention there was just to try and, like, immediately convey, like, okay, if you run, like, UV pip install, like, requests, it installs requests into the current virtual environment. And, like, that's something that I was hoping would be, like, immediately conveyed by the subcommand. We're not the goal is not to support, like, every single flag of pip, for example.
Charlie:Although we do support, like, we support a good number of them, but, like, we're not gonna support all of them. And I don't think we'll support every subcommand. The goal is more to kind of convey, like, what's the scope of the interface and, like, how does it how does it generally work. Okay. And so that's why we did that.
Charlie:But, yeah, it doesn't it doesn't use PIP under the hood or VM under the hood or like that, which I guess is another source of con of potential confusion.
Brian:But one of the things that so I 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
Charlie:We did the same thing.
Brian:Yeah. We did
Charlie:the same thing. You
Brian:know, ask me to have a
Charlie:Yeah. We did the same thing as pet. Yeah.
Brian:Okay. Because some people probably do put it into tool chains or something.
Charlie:Yeah. And I think there wasn't I didn't have, like, a strong reason to deviate from it. But, like, 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 might add a UV install in the future, but if we add that, it'll work really differently than, like, than pip install.
Charlie: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, like, break them in the future. If we add our own UV install, we'll still have those commands available. So that that was another part of the.
Brian:And I have seen some blowback, at least, from the sidelines, of some people like you said, some people saying, well, may you should have not used the word pip. Yeah. It should have been something else. But then there's also, is it even fair for a venture backed company to be taking over these projects? I've got my own opinions about that.
Brian:But before I say anything, have have you thought about that? Is there is that a consideration?
Charlie:Well, I think I mean, I don't I think I would maybe object to the idea that we're, like, taking over Pip, if that's maybe what's being suggested there. Because, like, in my view, I think
Brian: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 wanna 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.
Charlie:Well, what I want is, like, I want there to be and I think there I really think there can be, like, a symbiotic relationship between, like, our projects and obviously and other open source projects, even if they are sometimes seen as, like, competing or, like, substitutable. So, like, for example, like, it's similar with Raf and Pylent. Like, we have a good relationship with, like, the Pylent project and, we sponsor 1 of the maintainers, for example. And part of and you know, if we need to make changes like to our pilot rules, we'll often like talk to them about it or like if we're gonna add if they're gonna add rules to Pylent, like, there's often dialogue between the tools. And, like, from my perspective, you know, part of the reason for that is, like, first of all, there's a lot of people who still who use Pylint and a lot of people who use Raf, like, use it alongside Pylint.
Charlie:And so I want there to be, like, a healthy ecosystem Pylint necessarily because, like, there's just a lot of projects that are going to keep using, Pylint necessarily because like there's just a lot of projects that are going to keep using that keep using Pylint and that are using Pylint. And so I want to have like a good ecosystem between these projects because I see them as somewhat symbiotic. And similar with honestly, 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 like, PIP and UV, like, we have a lot of overlapping goals, but also a lot of, like, very difficult. Like PIP has to be like totally rock solid.
Charlie:Like PIP's primary goal is it needs to be like extremely stable. And, I'm sorry, I shouldn't speak for the project, but my impression of the project Anne from Talking Maintainers is like, you know, the primary goal there is it needs to be like rock solid and reliable. And it needs to work even for very old things. Often it needs to work. For us, like we don't have to we can make different trade offs.
Charlie:Like there are things we can choose to support and we're just in a different position around it. And so we can kind of like experiment with things and maybe that even funnels back into PIP, But we can also bring, like, different perspectives to a lot of the packaging discourse. Like, I actually think it's a good thing if the Python ecosystem has multiple, like, viable package installers, that are centered on a set of shared standards. Like, I think that's actually a really healthy thing for the ecosystem. So, like, I don't know, at least from my perspective, in a very genuine way, like, I want there to be a symbiotic relationship between the work that we're doing and, you know, the other projects in the Python ecosystem.
Charlie: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 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 that that that could could thrive even if the company doesn't. That's also something I think about quite a bit.
Charlie: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, like, that relationship. And, 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 that it it does create, you know, it could it could create tension. Yeah.
Brian:Yeah. Well, so far, the, 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.
Charlie:I appreciate it. Well, I I appreciate that that's your impression because it's certainly how I feel. I mean, like, PIP PIP is, like, I don't know, at least in my opinion, at least, like, pretty incredible project. Like, and I have a lot of respect for the people that have, like, maintained it and worked on it. And, like, that's basically my perspective on it.
Charlie:Right? It's not I'm not here to say, like, that project viable and and built around a set of shared standards. And I I actually think that people the people who work on PIP would agree with that. But, yeah, it's it's, you know, I guess one thing I would say, like, to this point more broadly is like, I do generally feel like, I know it's, I think it's very possible for like, someone, someone like me, for example, or like a company, right, to, like, come in and, like, build a bunch of stuff in Python and, like, do things in a in a in a way that is not, like respectful to the community and not integrated in a genuine way, like with the community. And like, first of all, I don't want to be that.
Charlie:And I don't feel I also don't feel that way. And I'm also really grateful because I think the Python community, by and large, has been extremely welcoming. Like, I feel I don't know, I that's just how I felt. Like I said, I didn't really know anyone in this community like a year and a half ago. And I've just felt a lot of positivity and respect and, like, good intentions from like, pretty much all the interactions I have.
Charlie: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 just not at all what I've experienced. So 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 very nice. So, I am glad that that's the dynamic that we have. You know, it's important that we, you know, we we compare ourselves in the same way.
Brian:Cool. What's next For
Charlie:Oscar, man. I mean, like, focus right now is just on fixing as many issues as possible. That's the focus.
Brian:There's gonna be more tools that you're gonna take care take over in the we'll probably see another something out here in
Charlie:the at least There's nothing to wonder. Yeah. I mean, I think from here, like, I want the UV road map to be very public. Like, I'm not I'm sure we'll do projects again in the future where they're private for a few months, and then we like drop them or whatever. But like, it's not it is not my preferred way of working.
Charlie:I think there are good reasons to do that, but, like, I would prefer that our road map for UV at least is now, like, kind of pub more public and, that we can kinda sketch it out in public and also get feedback on it in public. Like, those are all really good things. I think the thing that we wanna do next, for UV at least or probably the thing we'll do next to me is, we wanna add support for bootstrapping and managing your Python versions. So if you've used something like Pyenv before,
Brian:I've tried.
Charlie:Yeah. Or I'm sure you or or if you use, like, Homebrew for this. Right? Like there's a lot of different ways to manage, like how do you quote unquote how do you install Python? Like Conda is also an answer to that question.
Charlie: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 said and it actually downloads and installs Python and then downloads all the dependencies. And so, you didn't, you know, 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 of managing that too. So that's probably the next, like, big feature, I would think, that we'll start working on, but it won't be this week.
Charlie:But, you know, and then on the ruff side, there's a couple I mean, yeah, I don't know. I like the things I choose to share and don't share, it's always about managing expectations, I think. Because like some of the things that we want to do, it's just gonna take a long time. And I don't want people to say like, oh, they're gonna do x. But I think, you know, one thing that I do want to do on the ruff side is, we want to be investing more in our editor integrations.
Charlie:So we have, like, a language server that powers our Versus Code extension. And, 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 write rewrite it in Rust and make it part of Raf itself. Because right now it's like a separate thing that kind of calls Rust. But if it was built into Rust, there's just a bunch of interesting stuff we could do around persistent state, like in the server, like, and, making it more robust, making it possible to do analysis across multiple files at once. So, like, investing more in the editor integrations will was another big thing for this year.
Brian:That's pretty cool. Yeah. I'm just one of my to do list on this year is to try to investigate more of the options in ruff, because it can do way more than it did a year ago. It keeps growing. So Yeah.
Brian:It's pretty cool. Well, thanks so much for your time, Charlie, and, yeah, we'll talk later.
Charlie:Awesome. Thanks so much.
Creators and Guests
