Something like this. Right? You mentioned that you already worked in package manager in the past, but how do you do something like this? And how does it look like to develop a package manager from scratch? Yeah, so I wouldn't really say like from scratch, it's true. But I think a package manager also always comes with like, another part, and that's really the community around it. Hello and welcome to the Pibytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Baldebos. If you're looking to improve your python, your career, and learn the mindset for success, this is the podcast for you. Let's get started. Welcome back, everybody, to the Pibytes podcast. I'm Bob Adbos and I'm here with Robin and Wolf Vulprecht, who currently works at Prefix Dot de V and is also working on a very exciting package manager project called Pixie. And today, yeah, we're going to pick his brain about that and the exciting world of packaging. Probably a bit of rust Python and all the related stuff. So, yeah, welcome, Wolf. How are you doing today? I'm great. I'm very excited for this week. It's the week of packaging Con and I'm organizing it or I'm part of the organization community. Amazing, amazing. What does that entail? Packaging con? First time I hear about that. Yeah. So the idea is to bring together all the different package managers and package manager developers. So like, we're trying to assemble people from like the NPM world, Python Pip World, the Conda world. There are a bunch of C package managers like Conan also, of course, like Docker and all these technologies, Nix Nixos, Linux distributions, and we all share sort of the same problems if you look at it closely. And so, yeah, basically PackagingCon is an effort to bring everyone at a table and listen to a bunch of talks and try to learn from each other. Nice, nice, nice. Yeah. So that's going to happen here in Berlin, right? I saw it earlier. That is happening basically on Thursday. So in two days from now. Nice. I'm not sure when we will publish the podcast, but if it's early enough, maybe go there, check it out. Otherwise, I guess there will be also recordings online, right? So maybe. Yeah, for sure that in the show notes. Yeah, we will upload everything to YouTube. Nice. Yeah. So I guess that can be called a win, right? As we usually start with wins or it's going to be a win, I guess. Hopefully I can just continue with the wins. I just came back actually from Spain, from offside, where I was able to meet Bob and Julian in person. So if you ever get the chance, they don't bite. At least for me it didn't happen. So it was really nice to not only see Bob and Julian in the general setup online, but now for the first time since we worked together, even in person and did some good sports, my legs still hurt and otherwise did a lot of content that you probably soon see as a listener. Nice. Yeah, it was super nice and figure related win. We went together to a volleyball match with my daughter and they lost, but was one of the strongest opponents in the competition and they played, played very heroically. They really, really made it difficult on the best other teams. Although they lost, they had a lot of mindset and it was a great match. That was cool that you joined me, Robin, and cheering hard to support them. So thanks. Nice. Yeah. So just in general maybe going more to the Python realm, what do you love about Python? So you're working obviously on Python, at least at some point or sometime during a day. What do you love about it and why did you choose to work with it? Yeah, I think Python is a great language. Like it's super expressive and it's very easy to put things together, basically. I also have some criticisms of python projects where it becomes pretty cumbersome without typing. I think if you have really large projects, and I mean, I've tried to work with projects that are like pretty old code bases in Python and that becomes sometimes a bit hard to follow. But my background is from robotics, and in robotics it's usually C and Python. And so I've written a lot of python in that. And then when during university, it was also one of the first languages that I really tried to get more into to build a little app. That app is called Apostrophe now, and it's a Linux Markdown editor. And that was really fun. And that taught me a lot about Python. And yeah, I think also if you dive deeper and really explore how dynamic Python is, it's also pretty fun actually. But that also makes it really hard to do static analysis, which is sometimes something that I would like to do better than I currently can. So I guess that's also just speaks a lot. Right? Like on the one side it's the, what do you say in German? Flukensing. Like, it's great that it's dynamic, but it also has this disadvantages and yeah, it's always, I guess, a compromise to make. Right, like choose your suffering, basically. Yeah. So, yeah, you already mentioned that there are some things you dislike about Python. I guess package management is also somehow related to that, or why would you otherwise come up with the idea to create yet another package manager? Well, so, yeah, I think that's like, maybe I was already hinting at parts of this, but basically what we are doing, or what I've been doing for the past like four years, is trying to improve the state of the condo ecosystem and Conda as a package manager. And it's mostly associated with Python and data science. And it is written in Python, which is also part of where my criticism came from for these big projects that are really hard to follow because Conda and Conda build, which is another project of the Conda ecosystem that actually creates the packages, has been growing for, I don't know, ten years or so, and quite organically, I like to say. So the code base is a bit all over the place. What I did with Mamba was to reverse engineer it and rebuild it in c. And we're doing it for a third time now with the Pixie package manager that's written in rust, and then there's an underlying library that's called Retla. But the thing, because we're talking about Python package management, I also always try to tell people that Conda or Pixi or Mamba are not Python specific. Actually, they're very general package managers. Actually, they are not language specific. So you can also manage our packages with it, or you could manage your Julia installation. You can also get C and C packages from it and all these kind of things. And they are, at the same time, they are cross platform, so they work on all the major operating systems. I'm not really trying to only fix Python package management, let's say, but also really trying to build something a little bit unique, which is a cross platform package manager that works for any kind of package and any kind of language. Yeah. And I definitely feel some of that pain. I have gone through some of that pain just recently, actually, I installed Cuda on the cloud. Yeah, I guess you're already smiling. Yeah. I thought I didn't do things properly because I'm not doing so much machine learning, let's say, and so on. So I thought, okay, probably there's a better way. But then I saw these whole discussions on Twitter that said, basically, hey, the day when AI can install cuda in one run, then we are really close to Agi, kind of. So, yeah, I use conda a lot, because what I like about Conda is that you get the python you set the python version, and you set all the dependencies, both the condo dependencies and the pip dependencies, when you can kind of install everything with one command. So that's the nice part about it, I guess. But then also, I guess when you dig a little bit deeper, sometimes it's really slow. And then maybe you go to Mamba, for example, or micro mamba, and then it's super fast. But then I observed that certain things were not installable, or at least maybe I did something wrong. But then it didn't resolve anymore with micro mamba, so I had to use conda. So there's always some pain, let's say again, the pain you choose, right? And now I started to try a pixie, and it really feels like a mix between poetry and conda. So really usable, really intuitive, faster, like micro number maybe, but also, yeah, really practical. And you have all the different packages, so yeah, I'm curious to learn more about that and see how that grows. Yeah, I think the poetry for Conda was one of the taglines that we came up with initially. And really pixie is sort of like a mix of multiple projects that already exist in the Conda ecosystem. So there was already a project called Conda Lock, and that's what we are very inspired from, or also what we are using actually the same log file format for our log files. Then the other project that we were inspired from is called Condax. That's for global installs. If you want to install some package globally, you can just do pixie global install, whatever, and it installs that package into a separate virtual environment that is unrelated to anything else on your system. And so we're trying to find the best inspirations from packages or tools that are out there already and putting it into pikce and making it really nice to use. And whether it looks or it feels a bit similar to what Sebastian Ramirez is doing on the back end site with Fastapi, he said, hey, I took all these inspirations from the different frameworks, and when the frameworks were created, these and these tools didn't exist yet. So of course a lot of the things are now established and it's harder to change. Maybe you have the luck to build a package manager from scratch, basically. Right? So maybe a related question is, how do you tackle something like this? You mentioned that you already worked in package manager in the past, but how do you do something like this? And how does it look like to develop a package manager from scratch? Yeah, so I wouldn't really say like from scratch. It's true, but I think a package manager also always comes with like another part, and that's really the community around it. So like, the people that are creating the packages and package managers always live in some sort of ecosystem that supplies all of the things that you can actually install. In that sense, we don't start from scratch at all, because Kona Forge, for example, is the biggest corner channel and it's completely open source. It's not actually affected by any anaconda licensing changes and things like this, which is also another common misconception. It has over 5000 individuals that are creating these packages for us. What you do to build a package manager is, at least if you want to piggyback on an existing ecosystem, is that you need to analyze how do the packages look like, what's the archive format, how do you extract them, how do you install them, how do you make sure that they get into the target environment in the right way? For example, in the Conda world, we usually create hard links. So you have one central package cache, and then we only have one copy of the package and then only link it into the environment so that you don't duplicate the like, don't use too much space on your disk and things like this. And one of the hardest parts and that we are really happy with right now is the solving. So pip and Conda both use some form of SAT solving, which is like Boolean satisfiability solving that resolves basically the best package versions that fit to all the other things that you want to install. If you want numpy and Jupyter and, I don't know, some version of tornado, the web server, or fast API, then you need to figure out. They usually share a lot of dependencies and you need to figure out what are the latest versions of all the dependencies that I can install to make sure that everything keeps working. We took the time to write an SAT solver that was very inspired by lip Solve and lib Solve is the library that we've been using in Mamba for a long time now, and that works really nicely. And our new SAT solve us called Resolvo. The good things about it are that it's written in rust, so it's like memory safe, et cetera, et cetera. But it's also much easier for us to maintain than libsolve because lip solve was really written in like c and very hard to read and understand, see? And so we're quite, in a quite happy place right now. And then the other exciting thing that we've recently done with Resolvo is built sort of another package management library that's like the low level tooling that's called rip. And Rip is a rust based replacement for Pip, or implements all the logic that you need to resolve pip packages and also install pip packages from pypi. That's the next exciting thing that we want to integrate into PKCe. What you already mentioned that you use Conda and then you mix some pip packages into them. So we also want to make sure that that use case is covered so that you can also install PI PI packages or pip packages into your conda or like pixie environment, let's say. So the meme ability is then rip pip. It's kind of. Can you say that? So, yeah, our image is a wheel that makes a burnout, you know? Okay. Okay, nice. Yeah, actually that's a good thing because I just before also played again with Pixie. And so the way you would install it would be you create a pixie in it, right, to set up the pixie project, and then afterwards you can pixie add packages. And if you already have a requirements file, you would just install it as well with Pixie Pip install minus our requirements or how would that work? What's there the best practice? So let's say it's not yet 100% defined how the interaction with PI PI packages is going to look like. But I think it's like we will most definitely add another field to the pixie tunnel for now, so that you define your pipe PI dependencies there, and then it's in your pixitoml file, and then also it's going to appear in your log file. So Pixilock file will also have support for the pipi packages because that's really one of the key things that we want to do is always have this log file so you can reproduce your environments in the future and you kind of know exactly what's in them and all this kind of stuff. And yeah, maybe we should talk just briefly about the Pixitoml file, because like before there was only this environment Yaml file, but that's kind of limited because you can only specify channels and dependencies mostly. And so with Pixi, what we're doing is we have this Pixie Tumblr file, and it's very project specific. So you make your project and you add your dependencies. Then another thing that you can do is you can add tasks into that pixel tummy file. Tasks can do something like you can define a task that's called start and then start does something like Python app py or something and then starts fast API or whatever, or any other random thing that you can think about like prepare some data or run some pipelines. The other cool thing is that tasks can also depend on other tasks, so you can make a little sort of script. And then the third cool thing about tasks is that they are completely cross platform. So we use something called Deno task Shell, which is used by the Deno project which comes out of the JavaScript world. And luckily it's also implemented in rust, so we were able to pretty much immediately use it. And it implements like simplified version of Bash syntax because that was or is always a pain to kind of have the Windows support that uses quite different syntax for expanding environment variables and all these kind of things. So using PKCE is very easy to create these cross platform tasks, and I think that's going to be a very powerful building block for the future. It makes it also easier to build your package and then share it with others. Right, because it seems like you can just run one command and then basically runs an arbitrary amount or complex number of tasks that test things, maybe do some setup or so, and then run the app for example. Yeah, that's definitely like our big sort of goal is that you just do a git clone whatever repository and then you do pixie run start and it will get you everything you need. Like if you need a rust compiler, if you need a C compiler, if you need like Python 3.12, it can just go fetch all of that with the right versions from Condaforge or Pipi and get you going basically with the project and get you developing or using whatever you have just git cloned. Nice. Yeah, I guess that already opens up the question for how to best go into rust also Python. And what would be some advice there? But maybe just one question before that. What is your experience building pixie in public? Because I guess you have posted it a couple of months ago that this is what you have already planned or started working on. And since then I experienced your way of developing really kind of public like showing this, the progress and so on. How does it feel like from your perspective? Yeah, I've been quite lucky in my life, so to say that I have had the opportunity to build open source projects since roughly five years ago when I joined Quantstech, which was the company that I used to work before, where we did a lot of, where Mamba started and where we also did a lot of open source in the Jupyter space and also c was like a library called extensor, et cetera. So, I mean, I am kind of like an open source person, but now, I guess, and building public is, to me, at least, a really nice way to kind of collect feedback very early on. And we have, well, we have people that are kind of, like, very eager to try all the new things that we are bringing out, and it's always really motivating and cool to see. And I think the entire team is super motivated whenever someone comes and says, hey, I've tried pixie, and it's working. Or even if it's not working, it's always great to see people trying it and, yeah, just getting the experiences. And, I mean, we are doing this to make a tool that works for a lot of people and really kind of changes, hopefully changes the game a bit in terms of how people do package management. So we need that feedback. And I think it's really a mistake to sort of think that you know best what you're doing in that sense. Like, it's really a mistake to kind of just isolate yourself from everyone and then just, like, work on something for two years and then ship it, and then you realize, okay, nobody actually wanted this, so we're trying to do it the other way around. Yeah, I think that's critical. And, like, you have a piece of art that isn't used in public, but people will be like, oh, yeah, that was this one guy who had this idea about how package management should look like. But that sounds good. Also, there are a couple of other new kids on the blog. I heard about Rye. I didn't try it out yet. I mean, poetry is one that we, of course, already tried, but I kept going back to Quanda because I just needed it for some data science libraries and so on. So do you want to make comments on the other packages, package managers that are out there now? Maybe how you differentiate it or how you see that develop, maybe also synergistically and so on? Yeah, sure. We're talking to everybody who was trying to do package management for Python and rust. There's, like, a group of people, and I think. And that was also really important to us to kind of ship rip, because the idea is that if we all, at least our idea or motivation is that if we all collaborate on the same sort of fundamental core libraries, like the resolver, like installing the packages and this kind of stuff, we could make sure that we are all compatible. On the Python side, you have pip, which is the standard. And so what we may be trying to do is with Rip maybe have that same sort of building block that is pip on the python side and then we have rip on the rust Python side. And if we all built on top of it, then Pixie would be compatible with whatever Rai is doing and whatever some other implementations that might or may not happen do. I think that's our motivation, and that's also why I reached out to Amin again to tell him about Rip and see if he would be interested in trying to use it in RaI. Because I think if we achieve some sort of widespread usage of this low level library, then that would be great for Pikce because we could make sure that we install the same packages in the same way. Yeah, that sounds really inspirational actually, that it's not always needs to be against each other and the fight and so on, but we can see like, hey, what is the common ground where we have the same opinion, let's say, how things should be done, and then maybe we have different opinions on how to build on top of that, but at least we can create synergies on those levels where we have the same opinion actually, and gain from that. Yeah, so you mentioned already, I mean, you have been working on Python for a long time now, also some rust, I guess, right? That anything that you would recommend people new to Python or also to rust, how would you learn it if you would learn it again these days? So I think for me, and that's also how I learned Python basically, or any other programming language, I always start with a project and then I kind of bang my head on the project for a little while. And that's how, I don't know, learn turbo Pascal back in the days where we were trying to build like a breakout game or like Sudoku, sort of this kind of thing. So I think my approach, but I mean, it's always a bit unique to the person, is to think of some interesting problem that I would like to solve or some little game that I would like to do and then just try to learn by doing. I think with rust it's nice because they've really been able to have some good tooling around the library. So you have cargo and you have rust up and these tools that make it easy to get started and install it on your system. And then, yeah, just do some developments, read tutorials on the Internet, watch videos and get better. Nice. I mean, we didn't compare this, right, but this fits perfectly to our PDM program where we, we always say, choose two to three apps and then build them. And we, as the coaches help you get unstuck, because as a developer, of course you get stuck, and it's also important. It's an important part of the learning. But the question is just how long do you get stuck? And do you get so stuck that you are not motivated to continue anymore and then just being a bit, maybe getting some guidance on where you'll find resources or just problems we already have solved ourselves, and we can give some hints on how to solve them more efficiently or with less pain. Let's say that's exactly part of the program. So glide, how do you say for lager in German? But yeah, that's also like the most fun way to learn, right? Not only the effective, but then you can really show an app to your friends and or family. Yeah. And if you're ready, please contribute to Pixie. Yeah, that's the next question I would have asked. Exactly. Talking about, yeah, contribution. Right. What advice would you have for open source developers or aspiring open source developers, be it contributing to Pixi or something else? Yeah, I think just to walk through the way that I think open source is a new contributor that comes. Usually what I think they should do is read through the existing issues, maybe find the ones that are good first issues, or write one issue of what they're planning to do, because that can also really help a lot, usually to figure out if that would be going in the right direction or not, like if you want to develop a new feature. And then my other recommendation is maybe to open a pull request as early as possible so you can get a lot of feedback early on. And don't be afraid of basically sending an incomplete pr or one that's not working. I think that I'm much more appreciated. If you like, do something early, communicate a lot about it, come to our Discord channel and yeah, talk to us. We are sort of always there as we have. Like, we also use it for internal company communication stuff and so on. And basically what I said, we are happy to help people, also to get better at rust in that sense. So if you want to do some open source contributions and you're stuck somewhere, and you open a pr to Pixi or Redla or any of our other repositories, we're always happy and eager to help. You ever bought a course and saw zero results? I've definitely been there. There are very great courses and materials out there, but if you don't implement, nothing will change. But with Pyrites developer mindset coaching, it's a whole new game. In just twelve weeks, you transform from a Python intermediate to a pro how? Through one on one coaching, building real applications and mastering advanced python techniques. Our hands on approach isn't just about learning, it's about doing and achieving. Get certified, push your career and join an empowering community. Apply for the Pibytes PDM program now. Check out the link in the description below. It's really good to hear. It's something that we say to our clients, like some of them said, yeah, I only make the pr when I'm already done. And like, no, please. Like there are companies who say that, right then that ask you to do like comparisons between git branches if you have questions. But I prefer to do the pr really early on. I mean, you have these work in progress tags and so on. It's just, I mean, the basic, very basic thing would be after the issue where you hopefully have defined really well what should be implemented. You could, for example, create a pr in which you just implement the tests, and then with the tests you can further refine the requirements. Like hey, it should be a function that if you put in four and two it returns six. It's a summing function, and then afterwards you can do the actual implementation. So yeah, that's really good to hear that also from you. And opening issues, not only going by the existing ones, but also open new ones. Yeah, awesome. Nice. Yeah. Otherwise, regarding the Discord channel, actually in preparation of the podcast, I wanted to quickly check how easy it is to install cuda with Pixie. And it worked rather good. But I also came to a short block, let's say, and it went into the discord server and actually found exactly a thread where this question was taken care of and answered. So that was pretty good. So yeah, go check out this discord server if you're listening. We can also really put it to the test next week with a code clinic and go deep and then see if we have any issues or enhancements. Right, Robin? Nice. Yeah, exactly. Yeah, good. I guess like a couple of small, I have some couple of lower level questions which we could have a look at, but maybe first some more higher level which are maybe more interesting, one of it being pixie AI. Everyone is doing generative AI somehow now, right? Some packages already leverage it in their products, so prefect. For example, now they came up with a small AI that whenever you have an error in one of your pipelines, it tries to give a good root cause. What could be the reason for Lumi AI is this thing where it suggests you how to set up AI like infrastructure. With AI, do you already think about something where AI could come into play, the dream would be, hey, I just installed packages and if there are version conflicts, then it just changes things automatically and I just make a coffee and 15 minutes afterwards everything is installed, or somehow. But I guess that sounds really complicated. I'm not sure. Yeah, I've actually recently had this discussion with there's a project called Robo Stack, where we're building all the robotics packages into conda packages, essentially so that you can install them with Pixie. And we have a collaborator in Australia who is a researcher, Tobias Fisher. He was looking for interesting things to work on and maybe related to package management, SaT solving. And there are projects where they use, basically you can guide the SAT solver, you can tell the SAT solver, explore this package next, or explore that package next, or things like that. That changes subtly your solution, because you reach maybe different local maxima or minima and things like this. And so that could be an interesting idea to apply AI to if you really want to. What we try to do for version conflicts is to print really human friendly error messages that might also end up being AI friendly if you paste them. So it could be interesting to take the error message and then let chat GPT derive something even easier from it, or have our own sort of simple algorithm. But it's not that part, I think it's not really so interesting to us right now. One hard problem in package management is building all these packages, and that's obviously different from like the Pip world, where in the pip world you basically have the author of the package usually being the person that also, or the author of the software, also being the person that makes the package where in the contour forge world. And also Linux distributions and things like this. The people, like volunteers, are packaging the software for Conor Forge. And that includes software where we might not even know the author. And that has nothing to do with the python world. And do you need cmake, do you need auto tools, etcetera? And so one thing we've been wondering is, can you take a random git repository and let an AI run over it and figure out, ok, this needs cmake, this needs a c compiler, this needs like boost as a library or I don't know, and then generate, because in conda we have these recipes and so generate recipe from a git repository. So that's something that we might be looking at at some point. Nice. Yeah, that sounds exciting, I guess. Bob, regarding the package management, did you have some more questions in general? Because that's something of course we also face frequently, I think this has been pretty exhaustive. Like the link with poetry, the rust site, the inspiration were both inspired it on and its features. I'm pretty satisfied with all this info. I don't have any remaining questions about that. Yeah, maybe just the last one. Regarding the existing packages. So I saw on the prefix site, you have both Mamba and and Pixie now, right? So what is the future for the tool, or especially for mamba, I guess. Would it be somehow integrated into Pixi so that you can. That is also another question that you can, for example, just create a pixie environment based on an enfjamel, like from the Conda days, or how does that look like? Or will mamba soon, apart from us? No, mamba I don't like. It's definitely not going away. So there are some things happening. Like Conda, for example. They have started to, or like a while ago, actually. They've started this project called Conda Lib Mamba Solva, and that replaces the internal solver of Conda. That was also the part that was relatively slow and the part that Mamba really improved upon with the mamba implementation that uses libsolve under the hood. And that's a project that is going to be basically shipped or turned on by default in like a few weeks from now, or maybe when the podcast comes out, it's already has happened. And that is basically the continuation of the mamba story. But because Mamba started out as this python project that was like a hybrid between Conda and some C parts, and then Mamba itself is going to turn into a pure c project where the python parts of mamba are going to be. If you want to use Python and mamba, then you should use Conda Libra server. If you want to use mamba, mamba that is derived from micro Mamba, but as shared libraries, which has some benefits for updating and stuff like this, then you can continue to use mamba and micro Mamba. Then Pikce doesn't really have the goal of doing what Mamba does in terms of having environments that have a name and are located in different places on your system. With Pixie, we were focusing on the single vision. You have your project, you have your pixie tumbler, you have your pixilog file, and make that really work nicely for this project specific use case. But there are people that legitimately have this use case where you want to have multiple environments stack them, or have them really live independently, or have kitchen sink environments. We're not super keen on adding that into Pixie what could happen is that we make another project that's based on Retla as like the rust open source libraries that we also have. But yeah, I think we're working pretty closely with Quantstack and Anaconda on all these mamba related developments, and we are going to meet tomorrow for dinner with all of them. So that's going to be fun. Nice. Yeah, it's good to know that they're like the core developers, kind of the package management and so on, meeting and exchanging thoughts so that we, the developers that are rather just using these tools and are happy that they make a lot of improvements can focus on that, and the package management gets always smoother and smoother. So which books are we reading currently? Bob, do you want to start? Sure. I had a podcast yesterday with Adam Johnson, so I'm still reading his Bush jar git DX. So he has some really great books about the developer experience, tooling and stuff. And on a completely different note, I'm also reading the story of art by Gombrich. I think it's a german name, right? Yeah, something entirely unrelated, but definitely just interesting history of art and stuff. So. Yeah. What about you guys? When I was at the airport in Spain, I saw this book and I wanted to buy it anyway, and then I saw it was in Spanish, if you can see this. But I found it a super good idea to buy it in Spanish to finally improve my spanish knowledge a little bit. So just in the same philosophy, let's say, to look into different programming languages to inspire yourself here and there, maybe also look into other human languages and. Yeah, I guess the interest in Elon Musk drives the motivation to learn more Spanish. In that case, interesting book. Yeah. And you also do like highlighting and stuff, right? And then you can some GPT upload photo and then you had a whole easy vocabulary training. Translation, right? Yeah, exactly. Cool. Did you already try to speak Spanish with chats PT? Not yet, no. That's a good question. It's really crazy. I think it's the future of language learning, but, yeah. What am I reading? Well, I've been reading this book of Rust, the rust book that helped me quite a bit. And then we're also working quite closely with Martina Locengo, and I have a book that's called Loft, and so that's about tech products and how to make tech products that people really like. So. Sounds good. That's how I checked that out. Yeah. Nice. Yeah. Otherwise, if you want any last words for how you envision Python in 2025 and maybe Python package management. I'm like, personally, okay, I think I'm pretty excited about Mojo and these kind of things, like how compiled Python is going to look like and how fast can we get and stuff like this. That is one of the areas where I'm kind of interested in, because what I told you before, I used to work on that numeric library in C, and I tried to really go to the limits of what C can do. And so I'm curious what Mojo can deliver and how nice it will be and so on. So I think that's where I am currently most maybe excited about in terms of Python development, even though it's not really Python. Sounds good. All right, I guess with that we can pack it. And it was really amazing to have you on the podcast. Looking forward to pixie development. And now I finally looked into it, I'm convinced. So I will use it and let you know if anything breaks or. Please do. Yes, any feedback is appreciated. Very exciting, and thanks for sharing a lot of cool stuff we've discussed. So thanks for hopping on our podcast and good luck. And maybe we can grab a coffee here in Berlin. Yeah, let's do that. Nice. All right, see you. Cheers. We hope you enjoyed this episode. To hear more from us, go to Pybite friends, that is Pibit es friends, and receive a free gift just for being a friend of the show. And to join our thriving community of python programmers, go to Pibytes community. That's pibit es forward slash community. We hope to see you there and catch you in the next episode.