Package and Dependency Management with Poetry

Speaker 1 [00:04]

Yeah, I didn't put up the installation instructions before the conference, so if you have some time now and have internet, does everyone here have access to the internet? I'm the only one. I really can't. I was like working from my phone. And yeah, then you can follow the instructions here. So today I'll talk about package and dependency management with poetry. But before that, I would like to introduce myself. My name's Steph. You can reach me in my email for any feedback or questions, complaints, issues with me. And yeah, also there's my GitHub. I have no Twitter, so yeah. In 2014, I attended the Reeker Center, formerly known as Hacker School, and it was there that I actually sat down and learned Python. Before that, I was unfortunately a JavaScript developer. And yeah, it was also when I published my very first Python package. It was actually at the Rieker Center. And back then, three people had to help me because I had no idea what I was doing. And it was really complicated. And currently, I work as a software developer here in Berlin at Mercedes-Benz IO. And I'm also one of the maintainers of poetry. So, yeah, I've only been maintaining poetry since June. And it's really been quite a lot. but also at the same time not much because it's usually either only me active or Sebastian Sebastian is the author of poetry or Bryce and never really all three of us together so yeah progress has been really slow but thanks to all the contributors we have been pushing bug fixes to Masa, at least. Yeah, so I'll just jump right in to talk about Python packaging. And I also want to talk a bit about the timeline of Python packaging, a little bit of history to kind of understand why we are here today and how we got into this mess. Configuration files, because there's a lot of them. The two peps that kind of made poetry possible. and of course I'll talk a bit about poetry itself. So hopefully by the end of this workshop you will be able to use poetry on your own and see how it works and also be able to write your own pyproject.toml file. So a brief timeline of Python packaging history. In 1991, Python was announced to the world by Guido at the alt.sources mailing list in Usenet. That's how Usenet looked like. And back then, Python didn't come with any kind of packaging tool or distribution tool. So when people would write their own Python code and they wanted to share it to the world, they would just put it up on their personal website or somewhere. And you couldn't really find these things very easily because Google wouldn't come out until 1998, and it was really hard to find other people's Python code. So you usually found out through word of mouth or you somehow stumbled upon some Python package on the Usenet or something. But some people decided to write their own indexes where they could put Python projects that they found and put it up on a website. And one of the most famous ones is called the Vault of Parnassus. Very catchy name. there's a lot of really good like um references to greek mythology if you're into that if you go to the wayback machine on the vaults of paranasis website and something that i found interesting that the author acknowledged and i actually don't know who the author is i tried to find out like i was digging around the website and doing some like investigative work but i wasn't very successful so anyways the author acknowledged that you know he was like they were not the first ones to write the python index and then they go on to say well i figured another can't hurt can it and to me this was really interesting because this has been like almost 20 years ago or even over 20 years ago and like we're still doing the same thing like we do the same thing over and over differently like um yeah i think um nothing has changed in two decades and this is how that website looked like um so maintainers of this uh website would really just put up whatever they found interesting to their heart's desire on this um like index and it may not even be um python packages it could just be snippets of code and so there was no standard really and if there was no standard everyone had their own way of building their packages when you downloaded them so it could either be a makefile or a custom Python build script or an installation readme. So in 1998, the distutils SIG mailing list was formed to discuss the design, implementation, and maintenance of a suite of module distribution utilities for Python. And so this eventually became distutils, and distutils in 2000 was shipped with a Python standard library 1.6. And distutils gave us this command, python setup.py build. And from distutils, with this command, you could put the files into a build directory and simply install it. And if you had any C extensions, it would compile those too. So this really made it possible to for people to not like muck around with custom make files custom build scripts or like readmes and yeah it was like the beginning of a standard and in pep241 metadata for python software packages were formalized so these would include things like the metadata version the author author information license platform supported and so on and these metadata would be extracted from keyword arguments by distutils sdist, and sdist would then generate the package info with all that metadata. So with this metadata, you could distribute your code for others to use. And you could package up code too with distutils using this command, and it would package it up to source distributions. Source distributions or SDISCs are compressed archives that contain one or more packages or modules. And they also usually contain the metadata that were formalized in PEP241. However, building SDISCs usually takes quite a long time. So built distributions were introduced to mitigate that slow build time. So BDISCs are distributions pre-built for your platform. So you can simply move it to the location of your choice to be installed and you just install that um oops and in 2004 setup tools easy install and the egg format were introduced so the egg format were one of the was one of the first built distribution formats so it wasn't the only one but because it came with setup tools and easy install like it was one of the most widely adopted. So, does anyone here not know what an egg is? Okay. So, yeah, don't worry. I'm still kind of also like, what is an egg? So, an egg is kind of like a compressed, well, it is a compressed archive. So, if you change the extension of a .egg to a .zip, you can actually unzip it and then see the contents in there. So you can think of an egg as like a single directory or file that contains an entire project unmingled with other projects' resources. So they're very similar to Java's jars. Eggs also included Python bytecode so that it's already prepared for your platform. And setup tools itself was a collection of enhancements. That's the euphemism. but I don't know, a lot of people also call it like as monkey patching distutils. I think it works, so whatever. So it was built to make it even easier to use distutils to distribute and package Python packages. And setup tools also came with easy install to install eggs on your machine. So easy install was the de facto standard for installing third-party Python packages back then. So if you read some old Python tutorials, they tell you to use easy install instead of pip. No, you should use pip. And in 2005, package files were hosted on PyPI for the first time, and it was made possible with this command, python setup.py upload. And yeah, so you could finally upload to the Python Packaging Index with setup tools. But fun fact, the PyPI had been around for two years by 2005. So it was actually already in 2003 launched. and does anyone know like what the other name of pypi is yes exactly and do you know why it's called the cheese shop do you want to elaborate yeah exactly so it was a pretty similar situation you know we have this like python packaging index which had no python packages so that's why people called it the cheese shop but nowadays there's so many python packages in there so i'm not sure if it still the name still applies but yeah now you know if someone refers to the cheese shop why it's called like that and what it's about so the year is like 2005 right and now we have a packaging index packaging installer a package installer and packaging distribution tools and these are enough to actually harness the power of the python community's creative works and other packages and you can install python packages to your heart's desire except there were two problems you can install two versions of the same package and you can't uninstall stuff because easy install is one of those really well-named packages which just installs stuff but doesn't actually uninstall things for you so in 2007 and 2008 virtual amps and pip were introduced to kind of fix those issues so with virtual amps you could isolate your project's environment from the rest of your machine, which meant that you could finally have a package with two different versions on your system. And with pip, you could uninstall stuff, amongst other things. And yeah, so to recap, it took us 18 years to... 17 or 18 years from Python's first release until we had something that looked like a proper packaging ecosystem. But the journey doesn't end there because we just love reinventing the wheel. and in 2013, the wheel was introduced and the wheel is also a built distribution format meant to replace the egg format. But unlike the egg format, the wheel has an official PEP which enforced it as a standard in the Python community. Additionally, a wheel did not include Python bytecode files so it should be compatible for both Python 2 and 3. And this is now the Python Packaging Authority's recommended format for built distributions. So yeah, it's pretty great. Now I can package libraries, install them, and even distribute them. At least that's what I thought. In reality, it's not that easy. Setting up tooling looks just as complicated as setting up your local machine for Python development. Like, we just can't catch a break. And if you want to develop a library, you usually needed at least pip to install virtual and to isolate app-specific dependencies and something like pip tools or pip and to manage your dependencies. Or you don't need the last part at all. Some people don't use it, but it's nice to use for sanity. And if you want to distribute a library, you need even more things because you also need setup tools to define projects and create source distributions and Twine to upload to the PyPI. So yeah, with many dependencies comes many config files, and one of those is a, or not necessarily config files, but it comes with many files, and one of those files is the famous requirements.txt, where your dependencies usually live. You define your dependency, and the version of that dependency that you want to use, and you install it with pip install, and you also have the setup.py, which is a Python file that tells us that the package we are about to install was built, packaged, and distributed with these two tools. And so this file also helps us to actually create packages that we can redistribute. Some people also see it as a kind of config file that tells setup tools what the package needs in order to work in addition to other metadata. But it differs from the requirements that txt file, because here you also see the dependencies, and that in the requirements.txt file, it makes it really easy for people who want to contribute to your project to just download the dependencies without having to build the project. Setup.config file, which is the config file for your config file, which is the setup.py. And it's different from the setup.py because it does not provide parameters to the setup function. So it should really only configure behavior of various setup commands for your project. but I've seen people use it to write metadata in there, like so. And finally, this is the fourth file that I'm going to talk about. In this series, there's more coming. It's the manifest.in, and in this file, you list non-Python files that you want to be distributed along with your package. So these could include stuff like the readme requirements, the txt file, and any, I don't know, data files that you might have. and to recap these are like the four files that you will probably end up with um if you are developing a library or application and if you use pipenv you'll add even more to that list you have a pip file there too um yes it's getting pretty out of hand i think um it was so bad that but I thought that I'd head out. If any of you are also tired of the situation, this is a good time to leave. But if you want to hear about Poetry, keep talking about it. So Poetry is a Python packaging and dependency management tool made by Sebastian. And he also wrote from scratch the dependency resolver, and I think it took him, I forgot whether it was six months or a year, but it was a long time. just to write the dependency resolver from scratch. So Poetry aims to get rid of all of these file dependencies using just one file, which is the PyProject.tomo. And I actually gave this talk already before, an even less funnier version of this talk at PyCon Lithuania. And someone put this up on the Slack channel after I gave my talk. And, yeah, we just love, like, introducing new standards in the Python community. And so let me introduce to you the pyproject.toml file, which came out of the PEP 5.17 and PEP 5.18. But it's not like other config files because it is extensible and it has arbitrary fields. So other tools, like Black, for example, and also Flit, also use PyProject.toml. And also Tox, they have added support for configuration in the PyProject.toml. So it is meant to be the one config file that hopefully becomes the only source of truth in your project. Yeah, so the PyProject.tomo file was born out of the PEP 5.17 and PEP 5.18. So PEP 5.17 specifies how to build a package, a wheel, from source code, so an SDIS. And PEP 5.18 specifies which packages need to be installed before trying to build. So these are the build requirements. so pep 517 and pep 518 break that convention break uh this kind of like gatekeeping that was happening from setup tools and disk utils and also um let's pry project tomo tell pip how to build build wheels and install them so i i think pep 517 if i remember correctly what um actually came about because of flit that another tool that would help you to build python packages so yeah pyprojectoml is not just for poetry it's also for other python packages out there so i'm just going to quickly go through how the information that you have in these four different files could translate to a single file. So from requirements.txt, you have the dependencies listed under the dependencies namespace. And also for setup.py, it's not much different. You can also specify where the packages live and which packages you want to include to your build distribution. And for setup.config, so if you just put metadata and you set up the config, you'll add the metadata under tool.poetry namespace, and for the manifest.in file, any includes look like this, and also, yeah, read me. It's pretty straightforward, and interestingly, anything that you have in your .gitignore is automatically considered an exclude. Yeah, I think that's pretty handy. And there's also scripts for the command line, because setup.py also enables you to have scripts on the command line, right? And actually, Poetry uses that, too. So if you run Poetry, it's actually running as a script from this namespace. So using Poetry, download Poetry from this website, and it's also like the docs. Otherwise, I also have installation instructions here, and if anyone doesn't have connections to the internet, you can install Poetry with a Raspberry Pi that I set up in the corner, which I also published to it using Poetry. so can i get a show of hands just to see who have poetry in their machine already nice um perfect so i just also would like you all to remember the username and password so you could publish to the private repository that i have set up with the raspberry pi in the corner so about virtual ENVs how does Poetry take care of them right now it's still a bit buggy but in version 1 a lot of things will be improved and the ENV command in Poetry will also make it easier to activate and deactivate virtual environments and interact with virtual environments in your machine in tandem with Poetry so when you execute the install command or any other install like commands like poetry add or poetry remove poetry will check if it's currently inside a virtual env and if not it will use an existing one or create a brand new one for you to always work isolated from your system so projects are always isolated but if you want finer control over your virtual ends you can configure that using this command, like poetry config settings virtual ems create false. So this will disable that functionality that I was just talking about. From the workshop readme file that I shared, there's three different ways where we can go through the tutorial at the moment, and I think all of them are pretty good ways to be introduced to the pyproject.toml file. So if you already have a library that you are developing, you can try and translate the different configuration files of pyproject.toml file and try and build them. Or you can also create your own poetry package with, or a brand new Python package with poetry using Poetry New and then the name of that package. Also, if you are making a new project from scratch and you want to publish to the private repository that we have at the moment, try to think of a very creative name because otherwise there will be conflicts. So we can maybe just take the next five or ten minutes to try and write a PyProject.toml file that Poetry can read so you can publish, so that you can build the project and then publish it to our repository. Also, feel free to ask me questions. It's at gist.github.com slash Steph Samson. Oh, also, a lot of people have asked me, and also on the issues tracker on Poetry, like what is the preferred setup for Poetry with your Python installation. And both myself and Sebastian use Poetry with PyEnv because otherwise Poetry will use whatever Python is in your user bin Python, which is Python 2 probably. And we live in the future now. Let's use Python 3. So, or whatever Python version that you want. So, yeah. 80 days. Something like that. So, did anyone here use the new command? Cool. So, you might have noticed that it created a project directory that looks like this, which I think is very opinionated because it puts tests in the top level and also names the source directory the same name as the project. And you don't have to do it like that. It's just like a suggestion. And you'll also see that PyProject.tomo was automatically generated for you. And if anyone here is already working on an existing project, just cd into the existing project and run poetry in it. So if you already have a PyProjectOML file in your current project, it's going to fail. And yeah, if you run this command, it will generate the PyProjectOML file for you. Can I get another show of hands of who's already got a PyProjectOML in some project. Okay, cool. I think it's a good number of amount to move on. Did any of you try adding dependencies other than PyTest in the PyProjectOML? Okay, cool. Let's see if that works with PoetryInstall. Yes, question. Is it possible to install it with problem requirements? I don't think... Let me remember. I don't think we have that yet. You can use Depp Health. I think it translates for you. Yeah, I think that's also one of our most widely requested features. So you can look on the issue tracker and then vote for it. Please, because I also want it. But it's a community project. So, oops. Yeah, so if you run poetry install, you might have noticed that a poetry.log file was generated. And you should commit this poetry.log file to Git or whatever subversioning system you're using, because this lock file contains the versions and the SHAs of the packages when you ran poetry install. So this just makes sure that everyone is working on the same dependencies with the right versions. So you can think of it as similar to the pipfile lock or I think, I forgot what it is in JavaScript, but package lock. Yeah. And you can also actually add dependencies from the command line with poetry add and then the name of the dependencies and this will already add it to the PyProject.oml file for you, which I think is pretty cool because you couldn't really do that in pip. You had to freeze the requirements after installing VirtualMs. I don't know if there's any other... I don't know if PIP has improved in that respect because I haven't used PIP in a while because I just use Poetry exclusively now for my Python projects. No stupid questions in this room. You don't have to. It can live on the same... You can both have PyProjectOMO and setup.py coexisting if you are not comfortable with deleting setup.py yet. No, it's no longer necessary. So... Uh-huh, yeah, mm-hmm. Mm, okay, yeah, then probably, yeah, it's better to delete it, but it can also co-exist, because some of my projects still have both setup.py and pyproject.ml. Yes? Very quick, very hard question. I noticed that both of these can also be installed via PIM. Yeah. And then you can get that traffic for free by using the Yes, if I remember correctly, there are issues if you use the Python, like system Python, which is usually Python 2. I forgot what the exact issue was, but like some missing library bindings or something. Is that your question? Did I answer it correctly? Yeah. Oh, wow. I'm surprised. Maybe it was fixed finally. Okay. Yeah. Yeah, well then if, as long as it's like, if your system Python is anything other than Python 2, it will work fine. Yeah. Yeah. Do you have any experience for people using pipenv, just for comparison? Because there are some interesting similarities. Yeah, yeah, yeah, very good question. I actually used to use pipenv before Poetry. And this was, so I was using pipenv in the better part of 2018, so last year, like the first part of 2018. But I had issues with its dependency resolver. Sometimes it would just take a long time. Or, I don't know, it was just so messy with the virtual ants, and I just didn't want to keep debugging what was wrong with my virtual environment or dependencies. And one of my co-workers actually introduced me to Poetry. And, yeah, that's also another thing. really like about Poetry in comparison to pipenv is that now it just uses piproject. Yeah, it's really hard to, I think, keep track of all of these different files, especially for a new developer joining the team. When I tried running the poetry in it, in the existing, I'm sorry, it still asked me all the questions about the specific. Yeah. Is there like a path feature that it will actually generate the type project from? From setup.py? Yes, it's also like one of the other most requested features. Yes? I guess now, MyProject.exe will open. Hold on, I don't think I've ever seen this. MyProject.exe will open. I actually haven't seen that before. I just created a new project, and then it was... Okay, so that egg file, it looks like it's because of the ZOAP package that you installed. And yeah, so that was because of your dependency. So if Poetry doesn't find a built distribution to download, it will download. Oh, if it doesn't find a wheel, it will download the egg for you and put it into your project. Yeah, yeah, you have to ignore it now. Yes, did you have a question? The question was if I will talk about integrating poetry with Docker in this talk, but I won't. There's a bunch of discussions on it in the repository, so you can see there if you want. Can you just give some order? Yeah, so it's pretty straightforward, I think. Like other packages that you might use with Docker, as long as you have Python 3 installed beforehand, or yeah, as a directive in your Docker file to install Python 3, then there's no problem, because otherwise it will use the default Python 2 and there will be problems, but otherwise it's pretty straightforward. Yes, you would use poetry in that docker file as well too. Yeah, because then if you also want to build with poetry, you'll need poetry in your docker container. You can build it inside your docker container, yeah. Yes. Maybe you'll get to this, but I was curious if there is any explicit interaction between virtualenv, like workflow, and poetry, like corebond, for example? Not yet, but in version one, there will be. So with the poetryenv command, that makes it much easier to work with virtualenvs. Yeah, and it's kind of, it's like the API that we encourage people to use to work with virtualenvs in version one. So at the moment, if you want to use Poetry with Perseverance, and you have a version one, or you have kind of like a full flow where you can switch to that, and you can do that manually? Yes, yeah, unfortunately. But hopefully in version one, that's like all ironed out. And you can actually already use version one if in the installation, or with Python get poetry.py, you can specify which version of Poetry you want to use. So yeah, if you wanted to try out the new version one features, you can do so. If you want to now build your project to a distribution, you can run poetry build, and by default, it will make both a source distribution and a wheel for you, and it will go under this folder. But I have also specified instructions in the readme if you only want to build one or the other, but not both. So as you can see, it makes both a build distribution and a source distribution for you. And that's because that's the recommended way that PyPI wants you to distribute your Python packages. They want both build distributions and source distributions. And so distributions are like the just-in-case, where someone wants to build the distribution on their own. Yes? Yeah, so there's the, yeah, that's a very good question. So if you have a different directory structure than what poetry, the poetry default, then you can specify where the source directory is under packages, and then include the module name from the source file. So that's what it is. And you don't have to specify every subdirectory. Poetry is smart enough to find out which are modules. So just specify the root directory. Yes? Yeah. or there's some files that I don't get and I don't have another thing to add to that. Is there a problem that I don't see? So, no, this is because I installed my own package with dash E, or no, I built my own package as an egg, so that's why it's there. And I don't think Poetry builds an egg at the moment. So I actually built this with a setupPy build BDIS. No, Python setupPy BDIS underscore egg. Yeah. Hopefully, we will all be just using wheels and source distributions from now on. And if you don't have a Poetry log file, it's probably because you didn't run Poetry install. Or did you? Oh, if you did pip install, it won't generate poetry log for you. You have to do poetry install. Yeah. All right. Yeah. No Yes, so get poetry only downloads poetry to your system so that you can work with poetry. Yes Yes, yes, it's it's it's totally fine Yeah Yes, yes, you can specify these under tool.poetry.dev-dependencies. Yes, yeah, you can. And you can also, you can use whichever unit test No, it will always include PyTest, yeah. Any other questions? Yes? Yes? So the question was, does Poetry build conda packages? And I don't think so because neither Sebastian nor I have any experience with conda and I know that people have been asking this as well. So yeah, we will definitely look into it because at this point I think it's now also one of the other most featured requests. Yeah. no no i i'm not and i don't think either bryce or sebastian are because yeah it seems like sebastian himself is super busy so and we're like trying to trying like trying really hard to cut the issue log down and also like the PR backlog it's quite a lot oh if anyone's interested in contributing reach out to me let me know yes uh-huh uh-huh uh-huh uh-huh um sorry let I'll have to come over and take a look. and I provide the name of the package without the value and you're going to get the latest So, I'm not sure if you can do that actually in the PyProject.toml, but if you do poetry add from the command line, then it will simply fetch the latest version for you. But there's a section on the documentation about versions, about downloading specific dependencies for versions, and also how you can version your own project. Yeah. Yeah, so I will actually go, that's the next section of the talk. So the question was, how can poetry help you to share distributions with your colleagues without uploading it publicly? Did I phrase that right? Yeah. Okay, cool. So the answer is to have your own packaging index repository, which I have also today. So you can configure with Poetry a private repository like so. So poetry config repositories dot and the name of the repository that you want to refer it as in future commands. So for this one, I just call it workshop. And this is the IP address of the Raspberry Pi where you can upload packages to. And once you have that, then you can publish it with this command. Poetry publish. Yeah. Yeah, so the username is Steph, and the password is poetry. So today we are all Steph. Yes. Do you have a question? Yes. So, poetry will use, wait, if I, I'm not sure if I understood your question correctly, but No, it actually will. So it will first look at the public index, so the PyPI by default, and then your private repository. And I think that's also the behavior of pip. It will first look in... If you specified an extra index when you install stuff, it will look first in PyPI, and then it will look into your private repository. Yes? Yeah, you have to specify the repository with this command. because no poetry only considers only looks at PyProjectOMO as the single source of truth yeah it should I think it should be there but otherwise you can also I think it is in the current version which is 0.12 or it might be in version 1 where you can now override config settings using environmental variables so you don't have to keep using the config command and you can even you can specify in your Dockerfile Yes? Yes, you can download with Git as well, using Poetry. Oh, but you mean if you can publish with Poetry to Git? I don't think so, but I will have to double-check that and come back to you, yes? Oh, it's not working? Okay. Hmm. Interesting. Oh, okay. Okay. Sorry, I couldn't join the workshop Wi-Fi, so we're using the normal one, like right here, this one. Yeah, I think it should be under .poetry.virtualenv, but don't quote me on that, because I think it might be somewhere else. So if you made poetry new, and it should show in the command line, in the output, where the virtualenv were generated. Has anyone here been able to publish to the PyPI repository? Nice, cool. Yeah, I'm really sorry to the people who couldn't access the Raspberry Pi, but there were some that I found, some people were able to publish, it looks like. Yeah, there's several. But if you want to, If you want to try it with another private repository, you can set one up on your own machine using PyPy server or DevPy, and then you can try publishing to that repository. So you can have the PyPy server running on your machine, and you can also publish to it on the same machine if you want to emulate what we've done in this workshop. Yeah, does anyone here use talks? Sorry. So, yeah, if you use talks, you might be wondering, well, there's no setup.py. Like, how can I use talks then if there's no setup.py and we just have PyProjectOMO? you can specify talks to whitelist poetry and use poetry to run PyTest. And also since PyTest is the preferred test runner for poetry, it works quite nicely. You can find this in the poetry repository under issues because someone asked about it already. And also Tox now supports configuration in PyProject.toml as well, but right now it's the legacy Tox.ini, so you could copy this and paste this into your toml file if you really want to get rid of Tox.ini. It's almost lunchtime. Anyone else here hungry? I'm pretty hungry. At the start of this workshop, you might have all of these files and hopefully like by the end of it you would just have this and that's really the goal is to just have one configuration file mm-hmm thank you anyone else have questions There's also a section in the docs just for the PyProject, the tomo. So you can find out more about there, like how it can translate from setup.py to the PyProject tomo. Yeah. And there's also some resources. Yeah. That's pretty much all I have today. Oh, also, I got asked this question quite often when I talk about Poetry, and I just also want to let all of you know that Poetry doesn't do dynamic versioning natively, so you have to use a plugin called Poetry Dynamic Versioning so that it can do dynamic versioning based on like tags in your version control system. Handy for deployment. And yeah, yes? Is there an accomplished roadmap for the project before you see the project? Oh, that's a very good question. I just had a talk with Sebastian last week, so he will publish a roadmap when version one is out, and version one should be out in end of October or beginning of November, depending on how fast we can go through bug fixes. So yeah. Does version one write API or anything? No, it doesn't. It's not. It's backwards compatible, actually. Yeah, hopefully. All right. I know you want to go to London, but how do you test poetry? I mean, what is your strategy? Yeah, I just download the different versions and play around with them usually. I get exposed to testing poetry a lot because I look at people's PRs. So I don't have a methodical way of doing it. So, if anyone actually has a better way, let me know. I'm probably wasting a lot of time. So, if there are no more questions, I think we can say this was a great workshop. And let's say thank you to Steph.