Charlie Marsh: Accelerating Python Tooling With Ruff and uv | Real Python Podcast #238

Key Takeaways

welcome to the real python podcast this is episode 238 are you looking for fast tools to lint your code and manage your projects how is the rust programming language being used to speed up python tools this week on the show we speak with Charlie Marsh about his company astral and their tools UV and Ruff Charlie started working on Ruff as a proof of concept stating that python tooling could be much faster he had seen similar gains in the JavaScript script tools written in Rust the project started as a speedy linter with a small rule set it's grown to include code formatting and over 800 built-in linting rules last year the team at astral started working on a python package and project manager written in Rust as a single tool UV can replace pip pip tools pip X poetry pm and more we discuss how UV can install and manage versions of python and run scripts without thinking about virtual environments or Tendencies Charlie talks about growing the team at astrol over the past couple of years we also discuss the funding model astrol has adopted and sustaining open-source software this episode is sponsored by Postman Postman is the world's leading API collaboration platform and they just launched Postman AI agent Builder the quickest way to build AI agents start building at post.com podcast python all right let's get [Music] started the real python podcast is a weekly conversation about using python in the real world my name is Christopher Bailey your host each week we feature interviews with experts in the community and discussions about the topics articles and courses found at real python. after the podcast join us and learn real world python skills with a community of experts at real python. hey Charlie welcome to the show hey thanks so much for having me I'm really excited to be here yeah I'm stoked to talk to you it's been an interesting couple years watching all the stuff that you're working on there at astral excited to dig in yeah yeah no it's been uh I guess I guess a lot has happened over the past it's weird to say now I guess it's been over two years since I started working on this full-time yeah which is wild so I keep having to like remember how long it's been basically and just that say the right thing yeah yeah well we were just kind of talking offline before we started about working from home and I don't if that some has something to do with the uh the weird warping of time yeah I think it does I think it does yeah I also like when I started I started the company the same month that my son was born oh wow so like the first six months I don't really remember very well cuz I was like yeah I was like in the hospital like fixing bugs like the project was like blowing up and I was like that's wild um so yeah it was an interesting like the first six months are a little bit of a blur uh that's kind of a cool uh behind the scenes yeah yeah and then I made my we made our first hire like started growing the team in March 2023 so almost two so that's kind of when I consider like the start of Astral theany is when I brought on you another so that was about two years ago I wanted to talk you a little bit about the company um and we'll probably dig into that a little bit further what I wanted to do is just I've been doing this with a handful of guests especially people that make tools that everybody's using and yeah and I'm very interested in this being kind of a person who's entering programming late in their life but I always wonder about how people got not necessarily into programming but how do they got involved in open source and do you have a story there yeah yeah let's see I mean I most of my programming career I've been more of like a passive consumer of Open Source than an actual like contributor and maintainer yeah I mean I think by first brush with with open source was when I worked at KH Academy and we we maintained a couple open source projects but we also uh it was the very start of my career and I got really into react and the whole react ecosystem and I started in a couple small things okay I made a few really small contributions to react I was like maybe I should become a react contributor and I made a couple contributions there although I wouldn't say you know anything anything nearly notable and then you know I was mostly like I said kind of a passive consumer of open source for a lot of my career until I started working on rough and Ruff it's funny because like rough is really my first time being a maintainer and so uh and it grew really quickly so like over the course of the last two years I was kind of like thrown right into the fire of like being an open source maintainer I think it's a different from a contributor to a maintainer is a is a whole L thing yeah it's very different yeah it's really really different and i' I think it's been it's been cool to see kind of like all the the different phases of a project where like at the very start you're just like so excited that anyone would interact with it and you're like oh my gosh someone cares about what I'm doing look at these Stars I'm getting yeah rough like it's not like anyone in the python Community like knew who I was or like cared about you know had any reason to like think that what I was doing was interesting so you know it was just really amazing to see like people coming people I'd never heard of before coming in then suddenly people I had heard of coming in and seeing the project me' be like oh wow like this is really is really kind of amazing and then you know now it's like being a maintainer now is even pretty different than it was then for us because the project is so much more popular so now it's like you know we get like hundreds of interactions a day and it's more like how do we keep up with the volume like how do we try to scale like helping people like answering questions and making sure they don't get stuck how do we we have to be way more thoughtful about like the changes we do make yeah because now anything we ship just affects a much larger group of people if we ship a really bad bug it might halt a lot of people in their tracks or or get them waste a lot of their time so okay you like the St get higher yeah you know it gets it just becomes a lot more work it's just been interesting for me to go from not being a maintainer really at all um to to now being a maintainer on you know two or three pretty pretty large projects yeah yeah it's been a lot to learn there aren't really a lot of great you know there's no book necessarily on how to do it yeah I like that's why I like asking the question too is how people got into it you know the like you know what was their reaction and how welcoming was the community has been interesting kind of conversation and this is a oh yeah a very interesting one because your project like you said has just gotten you know hugely popular and so there's a lot more traffic and things you're dealing with and you know how to continue to Foster that Community is always an interesting thing too yeah it's a lot of um I think a big part of the success of the project of rough or at least one part of it that really wasn't about anything technical was just that I was so excited that people cared and I spent a lot of time with people in issues basically trying to understand their problems and make sure they had a good experience and I actually think that had a big impact on like what the project became and the fact that it grew it's like people felt really comfortable at least this is what I I hear and I hope um you know coming to the project and like opening issues and like asking for things and like even you know the thing I often say is like even if we say no to the thing you want I want that person to have a good experience and they should feel like we actually like listened and and that we had some sort of rationale for why we didn't do whatever whatever they want or whatnot yeah you know we still try and adhere to that pretty closely today even as we've like grown the team and the projects have grown a lot and it does it takes a lot of time you know like that's a big it's a very conscious decision to be like we're actually gonna spend a lot of time yeah talking like helping users in issues because it's a lot easier is necessarily programming these are these interesting other skills yeah and it's way easier to just close an issue be like you didn't read the docs blah blah blah and like I actually like really empathize with maintainers who who do that because it's just you know it's kind of a grind it's like every day you wake up and you have like a bunch of issues and like we're you know we're fortunate enough that we're working on this stuff fulltime so it's like I can devote a lot of time to it and it's like very much part of my job yeah but you know especially for people where they're trying to maintain a project that grows a lot and they're doing it alongside so much else like I definitely empathize it can be especially as time goes on it's it can be pretty draining and you know I think for us there's a lot of positivity in the issues in general like even when people have bugs that they'll often say things like I really love the project and that that's kind of like the thing that gets you keeps you going is right right but occasionally you do get people for sure who are you know rude or short or um you know they're frustrated and if you see that repeatedly you see that in any project you know it can be it can be kind of a drain so you know you get energy and you lose energy in different ways and um I think for us you know I just tried to make sure that as a team we really value putting time into helping users and like recognize that within the team and such yeah yeah I mean the the whole idea and we'll talk a little bit more about the company maybe but that someone can actually do it as a full-time thing we see that with python itself and having these developers and residents and I don't know two or three different people and and having that has just I don't know it's just changed so much for them and I feel like a weight has been lifted ac across you know python as a language and the continued development and then I've seen it in a handful of other uh people that I've talked to about this yeah Russell Keith McGee and he's getting help from Anaconda which is really cool it's something that you can at least see movement and see these project continue and I think it's something that I think there has to be lots of different answers to how to do this I agree I agree I I think it's I mean I think it's actually a really good thing for python that I I mean people shouldn't take my opinions on python like too seriously because I'm pretty new to the ecosystem and the grand scheme of how long it's been around but like I think that I think is good is you know Microsoft has a team of people working on there's like a faster SE python team Y which is great uh meta funds multiple people especially working on the the sort of like I'm not supposed to call it like no Gill but like the the free threading right work I don't know from my perspective those companies investing in like the language and the ecosystem and kind of professionalizing the development of those things is is great because everyone benefits and python is just so big now that the impact you can have even from just having like one person work full-time it's it's actually kind of ridiculous like the The Leverage that you could get even from having like one person work full-time on some of these things yeah yeah it's like a continuity kind of thing too you know yeah yeah yeah exactly what's interesting is then you coming into working on Python and I'm not sure how long ago that was but one of the first posts that you have I think it was on your own personal blog that I found kind of connected there is like python tooling could be much much faster and I I wonder about that why were you concerned about speeding up the tools that python developers use yeah totally well that was kind of like the blog post that launched rough and it accompanied the rough releas the initial rough release and it sort of like launched what came to be the company and then led to UV and so that was really like the Genesis for a lot of this and that that feeling came from you know before this I was at a computational biology company and I was in charge of a lot of the like software infrastructure and data infrastructure okay and so we had like a a relatively large python code base and I was responsible for all the tooling around it and I was just finding that I was spending a lot of time trying to get the tooling to work for us especially as we scaled up a little bit Yeah and even when I did invest all that time the experience was still I felt lacking compared to work I've done in other ecosystems like even in the JavaScript ecosystem I was seeing things with tooling that like didn't really exist in Python and you the other piece to that was in the JavaScript ecosystem there was more and more of a focus on trying to build faster Tools in part because you have all these things that happen when you like work with JavaScript in the hot Loop of your work you need to like transpile your code or like bundle your code or all these things that happen on your machine as you're working and these problems that are like right in your face okay so people started spending more and more time focusing on performance and trying to make those things fast because they were having such a big impact on development because they were like creating these like pauses in their workday large applications yeah large applications and okay every time I save I have to wait for this thing to rebuild and show up in my browser right okay so in the JavaScript ecosystem more tooling started to be written in not JavaScript like in original go and then in like rust and they were like it's a good investment to build this kind of fundamental Tooling in a really fast language to make everyone else's work faster was sort of a little bit of the perspective and I was kind of left thinking well could we do the same thing for python could we build Tooling in Faster kind of lower level languages and then let the enormous community that works with python like benefit from that investment of of trying to build Tooling in this case in Rust and so that original blog post was really me sort of testing out that thesis of like could we do it like what what would it look like is there a reason it's not impossible you know how big would the impact be yeah what would the tradeoffs be and kind of putting it out there and see if anyone seeing if anyone cared that was the idea was like I built this minimal that was the first version of rough it was a very minimal linter so it could it would like parse your python code and then do some some basic analysis on it like try to find unusing Imports I mean things that Russ still does today but that was the first version of it much more minimal first set of rules or whatever first set of rules yeah was some maybe like between 10 and 20 rules it was you know was relatively small but the point was I wanted to I wanted it to be sufficiently complete that I could draw some conclusions about what the performance would be and like what would be hard and what would be easy okay and so yeah I put that blog post out there and it just it got a lot of traction people were very interested and that's always been kind of interesting to me because I'm not I can't run this experiment now but it is interesting to think if I had gone around to a bunch of people before releasing the before even working on rough and I was like how important to you is like the speed of your linter like I actually don't know that a lot of people would have said that's a really important problem for me yeah and yet I put it out there and like suddenly like huge projects that had been around for decades were adopting this like super new like rust based tool like I was seeing like scipi and pandas and you know and and to me it was like wow there's real there's a lot of demand for kind of a different take on python tooling so everything kind of stemmed Downstream from that but that was me trying to kind of Market my work a little bit you know and like I tried to explain to people what I was doing and why and why I thought it was important so a couple things that kind of came through that blog post and and your work there these ideas that you wanted to change some of the tools and see how the tools can change how the developers work and right you also use the term ergonomics I think in there yeah which I think is interesting how did you see it changing those ergonomics or is that sort of feedback that you got as people started to adopt them it's something I've I I guess if I wrote it in that post and it's something I've believed for a long time right but um I uh I do think about it a lot it's kind of like like if you have a tool and you make it like 5% faster like that's great yeah but but it doesn't necessarily change like how people work or how the people use the tool but at some point if you make things like much much much faster suddenly like the way that you use the tool can change really dramatically and your relationship to the tool can change a lot and and this is what we saw with Ru and and now with UV like an example with Ru would be you know I talked to people at uh that work on dagster which is this big sort of a data infrastructure project open source and originally they were using a different tool and it was slower and what that meant was that people couldn't really run it locally over their code okay and instead it would run in CI and it would parallelize across a bunch of machines and when that happens that means first of all like it takes a lot longer like the feedback loop is not very fast right and two also like people are pushing code that constantly fail the checks also because because they can't run them locally so they don't have a way to get that feedback right so they might just run it and never really like you said get the feedback yeah then they have to fix it and push again and fix it and push again yeah do something actionable stuff that could have happened at that time at that moment yeah so it goes so like at that point your relationship to the tool is mostly like about frustration it's like the thing that's right it's like the thing it's like the Conant it's like the thing it's like getting in your way yeah okay it's like I'm trying to do my work and this thing keeps telling me no with rough they went from that setup to like a pre-commit hook right it can analyze like the whole code base in like 200 milliseconds or something so suddenly it's like real time feedback in your editor as opposed to like pushing and waiting for CI and like waiting for things to get back to you so it's not just that it's like a lot faster it's also like the way that you use it and your relationship to the tool just changes a lot yeah we've tried to do similar things with UV like with UV and you know who knows if we'll be successful in these things but like we we're trying to make virtual environments the word we use is kind of like ephemeral like yeah yeah no I want to talk about that because I'm I intrigued by some of the things that happen when you run it with scripts it's like did it install anything was that memory yeah we're sort of trying to move away from this idea of like I have my virtual environment in this like pristine State sure and if I run the wrong command like it all gets destroyed and then like my day is ruined we're trying to move away from that and move more towards tell us what your needs are for your project and we'll try to make sure that everything else just works and sometimes we'll completely throw away and recreate your virtual environment but the tool should be so fast that that shouldn't even really affect you right so again it's like performance kind it should be a pain Point yeah like if it if it took five minutes to recreate the virtual environment every time then if we were constantly removing and installing stuff it would be a huge point of friction yeah yeah but if it takes five 100 milliseconds or five milliseconds or 50 milliseconds right like Suddenly It's like you might not even notice so yeah again it's like it's a little bit of trying to change how people like use and think about the tools and performance is just one it's one part of that there's there are other parts too like yeah yeah like in UV we're really we really try and push declarative dependency management so you kind of like say what your dependencies are and then we figure out the rest as opposed to saying things like install this specific package in this virtual environment you tell us these are the set of requirements for my project and then we'll kind of figure out what environment it needs so it's not just about performance but but for me that is like something that performance enables is you can just build very different tools that would be otherwise hard to make possible yeah well I'd like to just you know maybe we can dig in initially I might have again a lot of beginners and intermediate people that come to the show of course sure and so they might not be familiar with Ruff at all yeah and what it's doing and what it's potentially I don't want to say replacing but like you know can do the job of yeah yeah yeah totally do you want to Define it for us this hundreds of times no no it's totally so rough is well at this point it's a lot of it's a lot of things but I would say it's primarily a linter so a linter is a tool that looks at your source code your python code tries to identify problems with it and then in rough's case it can often fix them automatically so like a good example would be like I said before unused Imports so if you've imported things that aren't being used anywhere without running your code Ru will like look at the code and understand you imported the Cy module but you never used it and then it can it can also remove that import for you yeah that might have been a change that you made that you initially went down a path and then forgot to remove it because it was at the top of your code yeah maybe you put in CIS the CIS module and then you remove the code that used it and you kind of forgot yeah Ruff is also a code formatter so like it can just kind of reformat your code to have a consistent style like similar to tools like black so rough like one of the goals with Ruff apart from just being fast is we kind of like kind of try to bundle a lot of different tools into one to make development simpler so often like when people migrate to rough they might be removing a bunch of different tools that they used before that should try to accomplish the same thing so it's a linter it's a formatter and it does a bunch of code transformation as in it fixes issues automatically for you A lot of people will run it in their editor like we have you know various editor Integrations like in vs code a lot of people run it on the command line but you know it can give you real-time feedback about small issues in your code and and typically fix them for you automatically Okay so you can choose to say highlight these problematic things or autofix them yep yeah that's right yeah okay yeah so I have like I have my editor configured for example to show me Diagnostics like it'll highlight the unused import and then fix them automatically on save so when I hit save it just kind of cleans up anything that anything that's problematic it reformats the code and all that kind of stuff yeah one of the things I I thought about because it does do so many different types of things and maybe you're looking at getting used to this tool where somebody might have just started with a lter then moved to a code form matter and added these things as they went and added you know something like a import you know tool or something like that yep you have kind of a elaborate configuration system how's that work like how do you configure rough yeah so rough out of the box it enables like a small set of rules okay like things that are kind of universally applicable and like mostly unobjectionable like unused Imports you know part one of the goals there at least is if you run it on your project hopefully it doesn't give you an overwhelming number of of issues because often if you take a lter and you run it on a project that hasn't used one it can be kind of intimidating so the base set of rules that come configured is is relatively small and from there you can enable different categories so like we have rules related to dock strings like how dock strings are formatted and the information that's included in them okay and again you would opt into that you would enable the doc string rules um we have rules related to kind of like code modernization so maybe saying hey you're on a version of python that supports a newer way of doing this so we'll automatically upgrade your code to use that newer API or that newer syntax and again that's something that you would kind of turn on so yeah it has a lot of rules but by default we only enable a small set and even when I'm doing my own work I actually probably only enable a couple other categories but the idea is you can kind of enable more things over time okay you can also use it like just as a linter and not as a formatter or like just as a formatter and not as a linter like it's kind of intended to be such that the tools work really well together but you can also adopt them you know kind of Peace meal over time and this is all done like in the P project tomel file or Tom yeah you can configure everything in a p project Tomo file or we have a rough Tomo file which is kind of for that don't use a p project toml for whatever reason or if you want to use like a shared set of configuration across your whole machine okay you can put that in you know in a specific directory and we'll respect that everywhere so that kind of gets me to an idea here like how this sounds like two approaches that people have done in the past of installing tools like this they may have installed them per project potentially in like a development you know environment or whatever or a variety of environments or they might have installed across their machine this comes up a lot I talk about virtual environments and managing and I'm sure we'll talk about more about that with UV yeah so you could go either path you're saying here with how you would you know install rough and then manage these configurations yeah that's right I think people generally like have a configuration for the project because you might be working on the project with a bunch of other people and you kind of want to check in that set of rules to make sure you're using like a consistent set of rules okay but sometimes you might also want you know may maybe for example you want a slightly different configuration for when you're working in your editor like on CI you want to make sure that everyone's using the same set of rules and has the same configuration but maybe when you're in your editor you want to see certain things and not see other things so in that case you might set up your the editor integration to look at a rough. file in a centralized place okay but in general you probably I generally recommend configuring like at the project level okay and then as far as like linting and so forth and these default choices are a lot of those coming from ideas from other projects or from like pep 8 or where does a lot of the the rules that You' you've done come from yeah yeah a lot of the rules come from come from other projects and or from Pepa and other sources like that okay like our doc string rules for example originally came from PI do style which was another tool and so we aim to have a pretty high level of compatibility with those other tools so if you're coming from those tools it should be easier for you to migrate over like our base rules you're not going to get a bunch of uh alerts hopefully not yeah like our base rules are are are largely based on flake G and the rules that flake a enabled okay which was itself which was itself like a combination of two other tools which was pie code style and Pie flakes this is more information than anyone needs to know but but pie code Style based pep some of our rules are based pep the the default ones and others are kind of corre rules that come from P flakes like unused Imports and such well it's interesting because you'll see a lot of these names in your documentation as you go to set up the rules yeah yeah I actually don't know if I want that long term like I yeah I think I think it's been a really good thing I think it's been a really good thing for helping people adopt the the tool and kind of yeah you know we get a lot of newcomers who will see that be like these words don't mean anything to me and so it's maybe confusing for them but we also have people who come and maybe they're coming from those tools and and being able to label the rules and that way makes it relatable and easy for them to understand I think eventually what we want though is we want to be in a we want rough to be in a world where that's a little bit more like rough Centric I think um okay like you could imagine kind of recategorizing all the rules based on properties of the rules as opposed to like where they come from like maybe you want a set of rules that are about code style and maybe you want a set of rules that are about correctness and maybe you want a set of rules that are about performance right so ultimately like we want to get to that actually which is like categories that are kind of semantically meaningful yeah yeah and kind of also rethinking the defaults of what we include but okay that's something we've wanted to do for a while it would be a big obviously a big change and something we have to be really sort of careful and thoughtful about but that is what we want to get to yeah that is what we want to get to um it would be I think it would be a lot better it would make it a much better tool I think Postman is the world's leading API collaboration platform trusted by over 35 million developers and 500,000 organizations worldwide they just launched Postman AI agent Builder the quickest way to build AI agents with centralized access to the latest llms and apis from over 1,800 companies plus no code workflows you can quickly connect critical tools and build multi-step agents all without writing a single line of code start building smarter agents today with Postman visit post man.com podcast python today that's post man.com SLP podcast SL python [Music] I talked about a a recent python tool but it was developed by an AI company for writing basically code that can create web apps very quickly the name is escaping my head right now but I I'll includ it in the show notes okay but they wrote their code in this truly functional programming style it's still python but it would not be pep eight in any way if you look at it it looks really Str is it fast HTML maybe or yeah I think okay yeah yeah yeah it looks really different yeah Howard yeah exactly yeah yeah I don't know if you've looked at it looked at their code but it looks it looks really interesting I have looked at it it's very interesting yeah so what if they did they wanted their rules to be in rough could could they configure that um they could probably configure like a set of rules that are compatible with how they like to work okay so maybe those would exclude any code Style rules for example uh maybe not trying to be too specific to that project but like for example maybe you'd want to like not have rough enforce anything about code style yeah but there are probably like relatively unobjectionable correctness things that you might still care about like okay again like unused Imports or like variables that are defined but never read okay you know things like that so you can kind of configure the tool to care more about one thing or or the other but we actually kind of disable a lot of a decent chunk of the style rules by default because okay they're a little bit pedantic and some projects want to be pedantic but like in general what we want is the tool to be like helpful and not annoying so right so uh you know you can kind of some people onun rough with all rules enabled which I think is kind of a wild thing to do but some people do it okay um it's not really rough is not really designed to be used that way it's more designed to for you to kind of think about what matters to your project but some people do it so if someone's not familiar with the performance change M with using this tool I think we just briefly touched on the idea that it's written in Rust yeah but what has that done for the performance of it comparatively to other tools and I know you guys like to talk about it so yeah yeah great question I mean I think so rough and and UV too which I'm sure we'll talk about they're both written in Rust and they are a lot faster than other I think comparable Tools in the python ecosystem like often that'll be 10 100 a thousand times faster it sort of depends on what you're what on what you're benchmarking exactly yeah yeah but rust is is really good for these kinds of things like python is great for a lot of things I don't know that python is necessarily great for writing like compilers and yeah what we've built here like rough isn't a compiler but but parts of it look like a compiler like it it has to parse like Lex and parse and analyze source code right so look at Raw python source code and turn that into like a syntax tree that it can understand and rust is really fast for that like it's really good for text processing for example it's really good for things that you know just have to do a lot of work that you can parallelize really well for example like in rough we can we kind of like parallelize analysis across all your different files and so rust is really good for things like that so it's not always doing a top down type of approach which might be a classic python Style processing it can actually you know through everything build the sytax tree and and process it across the all the files across the different files yeah yeah exactly so um yeah so you know I think rust not all rust programs are incredibly fast like you can write slow like you can write slow rust you can you can write right it's similar to like in Python you can write like Fast versions you there's like a grad gradient of like fast to slow python for like given a program that does a certain thing like you could write fast and slow versions of it it's the same is true of rust too like I think for rust you know kind of like the the ceiling and the floor are pretty different than in Python like you can write extremely fast programs if you write like the median program it'll be faster than if you wrote the medium program in Python but we do spend a lot of time trying to get from like the base level of performance in Rust to like really fast rust and that takes a lot of work but it's it's also fun and it's you know it's it's really part of what we're trying to do like we want to build tools that are both accessible to beginners and give beginners a great user experience but can also scale to the kinds of large and complicated projects that experts might have um and the companies would have for example yeah so we're both trying to like build user experiences that are great for beginners while building tools that can scale to very large code bases and large and complicated projects I think it's even more evident maybe in UV where we're like trying to build tools that are really friendly for people getting just getting started but can also scale to projects that have hundreds or thousands of dependencies so it's like design for like design for everyone but build for scale or like yeah build for everyone design for scale I actually don't know which way makes more sense but but but that's sort of how I think about what we're trying to do it's like we want to build tooling that's approachable but also scales to experts one of the things I think about that you mentioned briefly there the idea that a lot of these tools that are in the rough kind of category were set up as cicd type of things where they were only run at that moment whereas a lot of people are running them like you say now in something like vs code or or py Charm or something like that where yep they you know whenever they hit save they might have this thing run and they don't even really see a performance hit which is uh very much a different Approach at least that's the the thing that I hear exclaimed most often about about Ruff yeah yeah yeah sort of like sometimes it'll be like confusingly Fast right it's like did it actually analyze all the files yeah that was the thing that Sebastian remirez from Fast API said I remember when he first started using the project he was like I thought it was broken because it ran so fast and so I had to introduce an intentional error into one of my files to make sure that it was actually doing any work so right or you could make a little sound effect go ding or something yeah yeah you know we kind of just want like the tools to like get out of your way and not be the bottleneck in your work yeah and we try to apply that to everything we build you know I think we're not just trying to do performance like I also we also want to be solving user experience problems right and thinking hard about like what makes tools hard to work with what makes for a good developer experience but I think performance is a great yeah it's one of many levers I think to try and build a great tool just briefly what's the preferred way to install rough uh with UV but you uh which which is our own project and package manager and installer but you can also install it with Pip okay A lot of people do that because pip is obviously very popular and it comes it comes with python most cases yeah so you can actually just pip install rough or if you use pipex pipex install rough okay again like I said we have UV so you can UV tool install rough or uvx rough either of those would work but basically it's available a package on pyi so you can install from pii you can install with Homebrew you can install it however you typically install those kinds of packages okay I think the important thing to that maybe isn't obvious on first glance is even though rough is written in Rust you don't need to have rust installed on your machine or anything like that in order to use it because we distribute it through pii um as a sort of a pre-built binary program yeah so when you install it from Pipi we're just kind of unzipping the binary and you can run it immediately so even though it's written in Rust you don't need to know anything about rust or have rust installed in order to use it yeah yeah it's kind of this nice benefit it's definitely been the conversation that I've been having for the last two years is and definitely the tools that you guys are developing keep coming up in this conversation but the rustifer was the buzz two years ago and I would argue that 2024 was the year of UV as far as the amount of uh because we do another type of show where we you know talk about articles and other things and I think 2023 was all about packaging and arguing about like what packaging is going on with you know Python's been like this forever and then 2024 came along and UV kind of answered a lot of those ideas and that's cool to hear so that's been interesting yeah yeah yeah I don't think we figured everything out but I think we've hopefully made some good progress on it and yeah you've had lots of releases over the year yeah yeah kind of put ourselves in a position to I think to like keep taking on hard problem the hard problems that we haven't solved yeah I think yeah rust I mean it plays a kind of like the one of the beautiful things about python for for a long time has been that python is often like when you run python code you're often actually like not running just python code like if you use like numpy or scipi data science world yeah yeah um python ends up being kind of this like front end to high performance code and like you as a user don't have to know anything about C C++ like a blast like all these like scary things but you can run like vector accelerated operations or vectorized operations like just by calling python code and that's kind of an amazing thing yeah you know with rust it's similar it's like people are building stuff in Rust to enable people this huge audience of people that work in Python to work faster and and and benefit from it pantic would be another example like pantic they rewrote the core of it in Rust so there you have people are just calling a python installing and calling a python Library like they otherwise would but that huge user base that ptic has like the entire ecosystem benefits from you know a faster a faster more efficient tool yeah so it's kind of amazing that we can just like build these these tools in Rust and distribute them and everyone can just use them without having to think about the fact that it's written in Rust and you know it's both it is a source of a lot of complexity in the python packaging ecosystem that this is possible yeah to distribute and install native code but it's also like a superpower and the thing that I is pretty unique to the python ecosystem that this happens yeah it's it's been really cool to see and like I think I think rust is a good fit for building this kind of like core tooling that you know again we kind of pay I guess some sort of like productivity tax we're building everything in Rust right but ideally everyone else in the ecosystem benefits from like those Investments that we're making at the fundamental level just like how python much of python itself or much of cpython itself is written in C right like we are writing a lot of the tooling and rust in order to benefit everyone that works with python yeah yeah totally I think the initial release was that February of last year is that right it was yeah yeah okay yeah almost a year go at that time maybe we talk about the feature set growing across that but what was the what was the initial release designed to do yeah yeah great question yeah so UV the initial UV release was yeah February of last year so almost year ago and the initial version it wasn't intended to introduce any like fundamentally new workflows for people that were okay for python packaging it was intended to give us the foundations to like eventually do that but the initial release was very much focused on being sort of a pip compatible API okay so if you'd use tools like virtual M or python dmvm yeah if you'd use pip if you'd use like pip tools like pip compile or pip sync that was that's also a popular thing like those were kind of the workflows that we were aiming to replicate in Rust okay so the initial release had like a UV VM command to make a virtual environment and then a bunch of UV pip commands like UV pip install UV pip compile UV pip uninstall so it was kind of like your using a pip interface but you just put UV before it and it works kind of the same way that was pretty controversial or it was somewhat controversial at the time because a lot of people are like why do I need to put pip why do I need to put pip here like why do I need to do UV pip install why can't it just be UV install yeah it was very intentional for us we were we were like we're going to share a worse experience right now because we want to ship a fundamentally different experience later okay so later that year in I think August we launched like this whole new set of kind of like first class apis yeah and that was like UV sync UV lock UV run these are like the way we really want UV to be used but they require you to kind of opt into a different way of working so like you need to have a p project Tomo file and we create a lock file for you and we do bunch of stuff for you so it's kind of like if you're willing to work in in the way that UV wants you to you can use all these new apis that should make your life really easy okay but if you don't want to or you can't you can keep using the UV pip apis and like we'll support those forever they're just kind of I think of them as kind of lower level like when you're using those right you're saying things like install this package into this environment right right you're going individual piece by piece building up your project it's like create this environment activate it install this package remove this package whereas in the world over here with UV run UV sync UV lock that's more like tell us your dependencies and then we'll just handle it all for you so those are kind of like the two approaches that we offer one is more of kind of manual and looks a lot more like ways that people use additional existing python packaging tools like if you're really used to pip you can just move to UV pip and you know your experience should be mo you know the same except much much faster and with some other features that we have but if you want to work in the sort of UV run UV sync UV lock like first class UV world then you get a bunch of other benefits so that's why we did kind of the two releases and again the first release in February was just the UV pip stuff so it was just like this is a pip alternative but much much faster yeah and that ended up being I think a really good decision because in order to ship like that the UV pip stuff we had to build a resolver a pack like a dependency resolver a package installer yeah that's what I was thinking about a virtual environment Creator like all this stuff and from February to August when we did the second release with like UV lock and UV sync we basically just got like UV grew a lot and we got a ton of testing and a lot of people were using it and we just made the resolver and the installer way way better in addition to building a bunch of new features so you know over over that period of time we could just like keep hardening and improving like that core infrastructure of like the resolver and the installer while we built this like next Generation user interface okay so one of the other things that kind of got inserted in there is this way of installing python um which is kind of between the two I don't know if it was part of the initial release or not no it wasn't no okay it wasn't yeah and I I find that to be one of the more interesting things and uh I had somebody correct me online because I'm like fairly certain it wasn't sorry now I'm second guessing I'm pretty sure it wasn't no no installing python was part of the August the second yeah yeah which I I think is really great because that again if we look at tools that used to kind of do all these sort of things that were somewhat fragmented that you'd need to be familiar with and my six years or so in Python I I've seen a lot of these tools done tutorials or uh you know spoken about things like pm and yep the sort of Shifting landscape of peps in this you know goal of trying to get like things like the P project toml stuff so it's nice to see all these stuff sort of coales into like this one thing coming together yeah yeah it really has yeah yeah yeah which is really cool yeah like UV now actually does a lot more like we kind of want it to be you install UV and it gives you everything you need to start being productive with python so now it's not just about being a pip alternative it's like if you've used tools like poetry PDM Pym yeah pipex like all those fun all that functionality UV can do all those things so like you install UV and let's say you install it on like a brand new Linux machine like a VM or something yeah you can just type go like clone your project and type like UV run you know project file whatever we will figure out what version of python you need install it create the virtual environment sync all the dependencies and on the command like we will do all of that for you like you don't need to do anything else so it's like it's kind it's actually like really really cool I like my mind kind of still gets blown when I do it myself because I'm like this is just we just want to take all the complexity out of like figuring all that stuff out so you know when you run UV we download these pre-built pythons it's really fast and again you can use those pythons with other tools they're not like specific to UV you can use them with anything but UV is a way to install and manage python it's a way install and manage python tools like black like I mentioned earlier or rough like you have uvx which is kind of like pipex that's kind of run a python application and again like we give you all this stuff so it all works in one you know cohesive interface and the goal is like install UV and it should just like again give you everything you need to be productive with python and take all the complexity out of wiring all these things together yeah yeah one of the things I was intrigued by initially was like okay so I did what you said I bought a new Mac Mini and I was like okay I have a new machine let me just try UV and let's try installing python with it and I was initially concerned because I had used tools like PM where I had it install Python and then I went to do certain demonstration stuff for my job and suddenly there were things that weren't there there was stuff that was actually missing from the standard Library like tkinter wasn't there which was kind of weird uh and so I kind of wondered about that initially and I said some stuff on the program and somebody tried to correct me um and so um I'll ask you directly you guys are working with these I don't call them pre-built I I don't know wh