Maintaining a Python Project When It's Not Your Job

huh all right all right I'm here Nick I have only ten years of Python next so I'm kind of a newbie here on a stage and my background is like quite the opposite of what Mike just talked about so I disagree with a lot so I I'm not like I'm an industry programmer basically so I'm the one who wants all the features that make his life miserable so to speak so what worse operator and f strings are the best so I also maintain way too many open-source projects most famously you may have heard of errors which is the direct ancestor of the much-beloved direct classes in Python 3.7 which currently has around 12 million downloads per month which is roughly 4x of Django so and I also for the few remaining fans I have a few stickers left so talk to me if you want some and the rest of it there's a lot of stuff that keeps a lot of companies running so this is kind of anxiety inducing and despite this body of work I'm not saying that I'm a good maintainer I'm also not saying it I'm a happy maintainer occasionally I am actually very unhappy and all those projects do not spark any joy at all and sometimes I'm pretty bad at it because I just don't have the time because I have crunch at work because I'm travelling because I have preparations to do before conferences like the weeks and months leading up to the first conference of a year are basically a dead zone for me when it comes to comes to maintenance of my project and sometimes I have time but I don't have energy to deal with box full requests and support but I'm not here to talk about how shitty it is to maintain open source software because I think there's enough content on that topic out there and instead I want to give you tools and approaches how to feel less shitty about this doing this and be less stressed while still shipping a high quality package out there and to do that I want to help you to remove friction and I talked about friction I talked mostly as friction to your contributors and as a maintainer your job is actually not writing code like you still do it but it's not your main job as a maintainer as a maintainer you're mainly a leader you become the product manager this is your only specific task you decide what goes into your project must stays out what is the scope you uphold the quality of your project because you don't want to ship a buggy software this is the best way to burn out through bug tracker and I've seen some I'm gonna say nasty hostilities happen on issue trackers because people are just so burned out by the constant influx of negativity and speaking of that you also get to set the tone of your project and I think this is the biggest upside because you get to kick out toxic people before it's too late in practice I said before you are still totally gonna write code especially in the beginning but your project your goal is that you set up your project in a way that anybody can write code for you even you and once your project majors the development velocity will go down this is just natural like major projects have less code churn it's a good thing but it also means that you're not gonna hack on your code every single day or every week or every month so once you come back you will be very grateful for everything that you put into place that helps you to hit the road running while contributing to your own project and any friction for contributors and that resistance also falls back on you because work does not get done I mean how many of you ever run into something that you wanted to fix you could fix it but you got discouraged by the process or the lack of a process yes a lot of hands and all these hands stand for work that has not been done those are actually for work that has been done but by the maintainer who as we said before this should not be their main task you should be leading and you probably wanted to contribute that code but you didn't also if every new contributor needs hand-holding to get started with your project because it's hard to get get up and running your tests this is a menial tasks to port labor is labor emotional labor is labor and this kind of labor actually can burn you out faster than writing code all night at least in my experience so when a willing contributor arrives you want them to be you want it to be for them as easy as possible to get started so you have an early sense of success because motivation tends to evaporate really fast unless you are already invested in a project in some way or not an otherwise it's just oh god this is just too hard I'm gonna stop here I'm gonna monkey Patchett class in my own code and you want to give them a clear path from start to finish so they know what what they have to do for a change to land and in my experience people don't mind to put work into quality at all because they probably have your package in production so they have an interesting interest in this package to be good to be high-quality because they might be have waking up themselves at 3:00 a.m. in the morning by their owner back the day it's contributed so this is usually not the problem the problem is that people don't know what to do and so I'm gonna say that a long concrete and actionable to-do list is much better than a short one but it's very vague and doesn't tell the people what what they have to do and finally what I find most important are short feedback loops which in this context mean the time between trying something out and seeing the result of that change this is I'm gonna say like the number one factor in development ergonomics because it encourages experimentation and the lack of that it's usually for me the number one reason to abandon work on anything so in the following I'm gonna show you how I try to remove friction from projects like from contributing to projects by taking it through the lifecycle of a contribution and it's a play in three acts featuring you who wants to contribute to a project of mine and me who wants to get it into my project get it out of the people which as little work as possible and ideally I want you to bind you to my project so you provide me with more of your free labor so sadly the program committee refused me and all-day Hynix lot so I'm gonna just have 45 minutes instead but since the schedule is down the drain already and I feel a lot less pressure right now so anyway the reason why I bring it up is I will mostly present concepts and tell you how to think about things and if you're interested in the concrete implementations of those concepts like I'm not making those up I'm actually practicing them there's gonna be a link to a page at the end that will link you to concrete examples on how to implement those concept in practice and I will say like the concrete tools are less important they're probably other tools you can use but the mindset is the one I'm trying to implore in you so we're gonna start with your part and this act is entirely about you if I have to intervene I have failed you because you encounter friction and I have failed myself because I'd rather play right at redemption to instead of helping you how to run my tests so where do you start first you need a source code and sometimes I find it surprisingly hard to find so I'm already using a project and then I have to Google for the github repo so what I do is that all my projects have this section in their github readme on pipe I and in their documentation and as you can see it cross-references all three locations so you want to find a project in one place you know all the other places to where to find it also this is the important part it is an encouragement because many people still think open source contribution is something for the Enlightenment it's not and a link to a contribution guide it explains how to contribute and this guide at least on github is actually a well-known file it's called contributing rst or MD and it gets linked prominently whenever someone opens a pull request now this file should again encourage to follow through as many people are shy and describe the development process because not everybody is especially people coming from it from scientific backgrounds they are not they don't know that much about how development process works how Pro requests work how yeah this whole workflow thing just explained you workflow and explained your expectations the code standards like how your code is supposed to look the coverage you expect it should be hundred percent the behavior you expect from people and there you can reference another well-known file called the Code of Conduct again rst MD doesn't matter you can choose yourself so and finally and probably most importantly I explained how to set up a local development environment for this quick feedback loop that I've been harping about and it really should be really easy so first of all I still use setup tools I know there are alternatives I know people have very strong opinions about setup tools and those alternatives but none of the alternatives still cover all my needs so for all is false set up tools is not that bad if you know how to use it and so I'm still there it's the most flexible by now still so first step is create a virtual and however you do it you don't want to screw up your global installation and then install a package as editable so this means that whenever you change your source code the installed package changes along with it so this helps you to catch some packaging problems instead of just accidentally importing it from your path then I use an extra dependency called death so who is familiar with this syntax with the square brackets okay not enough people has explained it so these are called optional dependencies and you can also use them in for example a requirement so txt you can have more of them or separated by a comma and what you do is here that in setup tools dot setup you pass a dictionary which maps names like in this case death to a list of dependencies so it's like additional dependencies that the user can but does not have to pull in while installing a package and since setup the PI is patent code you can build the stitcher incrementally so I have an extra D political test this is just the dependencies to run tests I have one called Docs which is just building documentation and death it's just those two added together there's no duplication of information there whatsoever now once this is installed I can run tests I can build Doc's done unless you have any type of C extensions this is really all it should take for people to get started to run tests to get their feedback loops what there's two more problems first you have to remember how to run your tests and although I personally believe it should always be PI tests because tests are code it probably should be more test code than your actual code and tighten and code needs to be maintained so you should use the best tools available and I do not buy into the notion of this test should be simpler orbs purities stuff it is code you have to maintain it make it good but still I don't want you to remember my preferences or anybody else's this problem is sometimes solved using make files which is especially popular with people who come from corporate environments that have much more homogeneous environments they can rely on but it's not great for a reason alone it's problematic on Windows which as as we've already heard the vast majority of Python developers is on Windows and it's probably going to get even more because they just added it to the Windows Store and it's probably at this point one of the simplest ways to get started with Python but a bigger problem is that we are now testing only 1 1 Python version the one that you created your virtual ant with so you probably want to support more than one so you could start building multiple virtual environments and by hand but fortunately there's a tool that solves both of these problems and it's called tox our simplified it allows you to declare virtual environments optionally built your package install it into the virtual environment which already helps caching packaging problems again and run commands from those virtual environments so I think many have seen it before but I'm gonna give you a very simple example so we won't want the page you need a tox dot ini' in your project directory you define your environment in this case is Python 2 pi 3 5 and 3.7 and the two PI PI's which means these are for good friends then you set global settings in this case we install the local package with the extra tests I've been talking about before and we don't PI test now if you add this squirrely braces thing at the end it even allows you to pass arguments to this PI test call so when you call this line tox - EEP I 27 - - - X it means that it will run PI test in Python 2.7 with the argument - X which means stop after first error so this is pretty cool this means you only need to install talks and the Python interpreter so you want to support and you can run all your tests against all the versions then that you want to support and I find that it's a valid expectation for the absolutely most patent projects that I just CD into the project directory run talks and it will test everything for me you should have very good reasons for this to not be the case there's also NOx which is based on Python so if you don't like Hecky any files I'm fine with that - now there's more - code quality than just writing tests there are issues of style because consistency makes code much more readable pap 8 came up and some things are not wrong but they are just unfortunate like unused variables and used imports they are not terrible but they waste memory and waste cycles so there's the process of checking code without actually running it and it's called blending it's based name is based on a stuff that you find in your pockets or in your belly buttons you know and it's that's called lint so it's something terrible but life is generally better without having some [ __ ] in your belly button so let's remove it and the most famous winner is of course flag eight and you may may or may not know it but it's actually just a wrapper around multiple other tools one is Pepe it for style and pie flakes which does more than the correctness checks like unused variables I'm gonna go on a limb and climb that coat that passes like it is usually better and definitely more readable so I think it's a good thing to strive for that then what is the single commit every patent project has that user set up tools it turns out this loser all just forgot to run its linters because there is a tool for it called check manifest and as a matter of fact it is made right here in Vilnius so it's true then finally ever see a project page like this it's a little bit hard to see but it is basically a broke markup and if you have a typo in your rst or your now it is in your markdown file it will be rendered as S key so it'll it does not look good there was a time where I I've seen a lot of pages like this and again there is a linter for that you can use twine which is used for uploading packages you can also check it for your long description to avoid this kind of problems now linting and checking is great but what is even better to make that computer you pay so much money for and to not just yell at you that something is wrong but to fix it for you and this is for automatic formulas come into play and they are actually a game changer at least in my experience like nothing changed my development experience as much as those because once you embrace them then you and your contributors can finally just focus on the problem you're solving and not when to hit your Enter key or what kind of clothes to use so there's a bunch of being a for matters in Python for a while but none of them were quite there yet there are all kinds of downsides until the aforementioned black appeared and black is really really good because it format your code into a canonical format so the output is deterministic it doesn't just fix violations like the others used to do and so to come back to the question from before there is only one code style in Python nowadays and black is also very way more stricker than go format go format leaves you a lot of leeway in how you format certain things black will not like will always bring your code into one format and also only monsters use single quotes so he's gone right you can talk [ __ ] all day so another thing I sort it will sort your imports into beautiful sorted blocks separated by types how much time I have spent and wasted on sorting my imports because I'm very I think they're correct words anal-retentive because I want my code through the good and I want my is my imports to talk to me so I spend a lot of time I don't have to anymore there is this tool and together with black that's like 90% of code formatting is just automated you don't have to think about it whatsoever so stuff you had to think about is gone and it cannot come up in a code review so you don't have to pester anyone about it but now how do we make sure that the user runs all those linters checkers and for matters some of them like check manifest imply packaging so you will have to put them into talks as one of the environments but for everything else there's nowadays a better way it's called pre commit and pre-commit allows you to define hooks that run before each git commit and if those hooks fail you cannot commit your code but it also allows you to run them over all of your files anytime you want and to use it you just need a config file in your repository called pre config pre-commit config dot llamo the a is sadly not optional and it drives me crazy and flag eight has direct report which doesn't come as a surprise because the author of pre-commit is now also one of the maintainer of like eight and it's really straightforward you just point to the repo you pick a version which is a good tag and this ensures that a flake eight update will not break your build which used to happen quite often for a time I don't think it happens that often anymore but I remember people being very angry on Twitter about this and I find this is a good compromise to locking everything in your open-source projects because especially if the churn goes down at some point you will have more pull requests just updating your dependencies them actual code so this is like a nice compromise and then you choose a hook to run for flake it it's just like eight and the Python version that you want to use for that hook that's it and the nice thing is pre-commit is Python aware so it will store and manage your hooks in its own virtual hands completely transparently for you you will not know how it's working but it's going to use the right Python version that right version it will do everything for you so that means black and I sort are just as easy and there is a whole ecosystem good so who has ever checked in a PDB dot set trace and to get come on I know it's more hands yes there is a hook for us that will catch it and while it is written in Python it is not Python specific so there are hooks for everything you can run docker containers as your hooks before committing code so it is very flexible now with all this in place I could ask you to install pre-commit but sadly it is a patent package and asking you to install Python packages globally will turn my back tracker into a Python packaging support forum this has happened before so I'm not making this up so let's wrap this into the dev extra I was talking about before so once you install this dev extra along with PI tests and all the other tools you get a fresh install of pre-commit - in my case so what you can run PI tests you can also run pre-commit so this solves like a whole swath of problems and questions and issues now to ensure that you actually run it of course you should install the get hook so it gets run before you commit your code but again I will not rely on anything that you have to remember because you will forget about it and I will forget about it it's not a good thing trying harder is not a solution to anything so in this case I'm gonna add a environment called lint and it'll only depend on pre-commit it will not install your package which makes it a way faster and then we just run pre-commit against all files and if one of those checkers fails this toxin environment will fail so in blacks case it means it will reformat your code but then it will fail so I can stage the changes too before you commit the final version now your code is perfect anything missing yes documentation so how do we make sure that your documentation is building dramatic sip of water of course it's talks again and I'm gonna assume you're using Sphinx which you should it's great it's so good at Apple is using it for their Swift docks and there it is this time we install the extras docks I talked before which is mostly just sinks in my case and first we ensure that you that we can build our docks HTML then we run the dock tests in our dogs and I think all your examples in dock test all your examples should be dog tests because then you know that all your examples are actually correct because they are verified when they are built and I'm gonna sell you that lying documentation is worse than no documentation because not only does it not provide the information someone is looking for it also confuses the person seeking help and they will probably question themselves and try to debug their installation but you just forgot a comma or something so try to make all the examples doctors you will save a lot of time and a lot of Tears consequently my readme also know if you read Nia has code examples run them to make them a dog test now by running tox by typing three characters you make sure that you run that the tests pass the de linters passed the codes and imports are beautiful that the dogs built and you have working examples just by typing three characters that's all I expect from my contributors to remember three characters so and everything you did happened on your local machine I may not even know that you exist at this point yet you may have the perfect patch for me that means also you can Brook anywhere and I travel a lot for those interested my flight here was very uneventful thank you for asking and sometimes I log for conference wi-fi's I mean the conference Wi-Fi is really good but especially in America the Wi-Fi SAR very usable everybody would try to use github in rural Africa will understand what I mean by this like the current internet is broken for most of the world and nobody of those responsible cares because they all live in San Francisco on their Google Fiber anyhow this is not just about like my laziness the consequences of colonialism but it's also about my insecurities I don't like to publish unfinished work I am just very self-conscious about that so I don't want to force you to publish unfinished work because you may be also shy about it and then maybe you don't do it because you just feel bad about it so I try to give you the tools that the initial work you present has it's a high quality as possible and I I have to criticize as little on your work as possible so now you're done let's open a pull request now if you look on your watch which most of the time in act 1 and I told you I want to get involved as late as possible so this is all going by plan now so far we've automated as much as possible but certain things just cannot be automated so enter another well-known file and this is called the pull request template this one has to be an MD like a mark markdown file because this one gets inserted in through your pull requests as and it allows you to add checklists which everyone will see once they open a pull request now I love checklists checklists are amazing because they're the reason why airplanes don't crash every day or why doctors wash their hands before cutting your open there are like programs for humans there is a second best thing to automate now rendered they might look like something like this and you can use it to remind people to add documentation for their new features which they always forget change log entries for their changes which they also always forget and now me or a commentator we'll use the same list to verify that you the contributor have done everything mentioned before because I don't carry all these things in my head around like I can barely remember what I had for lunch yesterday so this this is for both of us again and so while reviewing I will refer refer to this list but then to run your test I don't want to clone your fork your patch on my computer like like in the 90s basically I want to run the tests and checks somewhere else I also want to encourage contributions through the web interface like because it means if less friction and it's perfect for typos if you read if you read my documentation and there's a typo you can just click Edit and submit a pro request right there so I need a way to run a tests on internet which is called continuous integration or CI and in the dark ages of open-source only the most prestigious open-source projects had their own CIS but the best-case scenario was that someone donated a server to you that you had to run yourself I don't know if anybody of you is an open-source to be a System Operator but I'm not so that means that very few projects actually had ci back then then came Travis Travis has its ups and downs over a years but it arguably democratized continuous integration landscape adding it to your project is so simple you basically just copy pasted a bunch of llamó and you reuse the toxic environments to make sure that our CI runs the exact same code like locally always good these very gold the good old times of 2018 however then kami Dara and I'm not gonna comment on them specifically because I don't want to get sued but you should do your own research on this company and especially check out what they did to companies that they've acquired before Travis here's the fact shortly after taking old Travis the layer of a big part of their workforce so if there are a thing like red flags it's right there so that made what was supposed to be just one slide telling you AU s-- Travis a very complicated research project and unfortunately every option other than Travis is much more complex or lacking in some other way but the problem is I consider Travis a time bomb at this point so I'm sure that the free offer that they are offering still is running on borrowed time so everybody should make plans what to do once they will make it even worse than it is right now or completely remove it which is sad because I cannot understate how influential Travis was but it is what it is I guess it is good in a way that it is an end of Anna monoculture because so far there was Travis and there was everything else and maybe you used up there to test Windows but that's it everything else was Travis so right now as your pipelines is the biggest contender I have moved my main projects there incredible how fast they are so to give you an idea the address test suit or like the strut lock test you went from twenty four minutes to two minutes forty seconds so it is quite a big difference and maybe it's good if you are forced to do that on the other hand it may be that Microsoft will just cut the free offering at some point because right now we get ten peril bills which is unheard of for a free plan anyhow I'm writing currently a blog post on how to move from Travis to edger pipelines so expect it in the next one or two weeks and github is also working on a CI ironically it's called github actions but it has been in private beta for months I mean I have been waiting for months to get into this better so I have no idea when it's gonna get ready if it's gonna get ready now that github has been bought by Microsoft nobody knows but github already does provide a bunch of automation one of them are github checks which are basically third-party services that allow you to get a red X next to a pull request the most common ones of course our CI integration or failures of insufficient coverage then there's more sophisticated once or if you want artisanal called github bots and you may have heard of maryada the Calais C of C Python core development bots she's giving a talk on how to read get a bot and she completely changed the development process for the C proceed for the C Python interpreter so the main part in the pradhan because when I was more active in C Python core development around 2012 most of the work we've been doing were basically maintenance work and like busywork and a lot of that has been a lot of that work has been moved to github bots which is amazing ok so much for the mechanical parts of the process so what happens after you have to green checkmark all checks are passing someone has still to review it so in the beginning is probably always you but as the project grows you don't want to review everything yourself you can't review everything yourself get up ecologist that with its file called code owners and it allows you to map pass to contributors but you also don't want to trash all bugs answer your questions there's a natural limit to your time especially if it's you free time it tends to get less over time so you need to build a community and community building is hard there's a lot of material on that I can't say much new to that but I want to talk about one thing and it's community empowerment I think it's important to give your contributors the feeling that the project is theirs too and I have to say I've read this talk and this slides before the latest Python drama that happened around pagan idols true before it's still true it is shitty to let others do the work to build your own brand for nothing in return so contributors should be celebrated if you let others do the work especially maintenance wrote the boring work and then take all the thing for yourself it may feel good in a short term like you gets to retweet all the praise about you and your project but it will backfire eventually like people burn out or not being valued on dealing with you I've seen people get very resentful and yeah one of them now wrote a big blog post so my consequence from that is that once a ders Gruber beyond a certain size and a lot of code was coming from outside contributors like everything around typing I still don't understand the typing code I have three contributors who fortunately for me so review all related pull requests I felt bad for making it look like it's my work like my name was still in the github URL there are some practical reasons because there's a bunch of functionality that is missing from personal project versus organizational projects that I really came to appreciate so I move others into a github organization and anyone who has ever contributed can have full access now it's our project there's also a less obvious upside of this because if it's less obvious that this project is you people are less likely to at you on Twitter telling you that your free labor is ruining their lives so that's kind of nice too now how do you decide who you're gonna let in whom you give right access I'm gonna tell you something that I learned from my friend Cory Banfield who tragically lost to a fruit company and the pie pie project is the same if someone wants commit rights to your project just give it to them there is nothing people can do in get that can't be reversed you just have to protect your master branch and just force everyone to go through prayer requests including you and if the process is clear people will adhere to it and if not you just revert that changes this office sounds funky no better you just revert whatever they did take the rights from them and the problem is solved but it has never happened to me it has never happened to Cory it has never never happened to pie pie people tend to respect code people tend to respect code more than people so it's much more likely that you have to kick off people make that you have to kick people off mailing list then take their red Xs away now finally providing support can also be quite stressful especially in synchronous channels like IRC or god forbid slack so I started moving support for my more popular projects to stack overflow and this has multiple advantages first it's asynchronous so people from San Francisco can ask and I answer whenever I'm awake in Berlin if someone else doesn't answer before me it is searchable so the answer doesn't just vanish into the ether or in some weird archive so I don't have to answer the same question multiple times this is now the problem of sick overalls moderators and if I have to answer at the end I at least get some intern brownie points out of it in a form of Stack Overflow reputation then I still don't want to hang around on a page all day it's the that would be barely better than hanging out in chat so what I do is that I set up tag for my project and then I followed them on RSS yes RSS you may heard of it from Grandma talking about it very fondly it's like Instagram just without stories and not just photos and you can choose your own client it's awesome so the only downside is you need someone with enough reputation to create your tag I am not dead so on I don't have enough reputation but there are people on the Python community that can help you out with that but back to the pull requests let's assume I reviewed it while doing so I did not have to pass through you about the line length about the import order about the type of quotes about trailing commas about failing tests of a broken documentation robots got to be the [ __ ] and studies have shown that people take pestering from a robot much less personal them from other person so who doesn't like an [ __ ] robot so now let's merge it now as I mean tainer I really think it's important to say thank you it sounds trivial but I contribute to a lot of other projects too and I've been doing this for many years and yet still to this day when I have contribute some code and it just gets merged without any word of anything I just feel shitty so just say thank you you probably are grateful for the patch so just tell people they cannot feel it so for everyone to use your contribution that I've just merged and thank you for we have to push it out it's time for the final act the release and what I hope you realize is that if you followed act 1 & 2 you can release it anytime you want because your poor request based workflow along with a CI ensured that the master branch was always green always working this is not only convenient this can be essential if you have an emergency like a nasty bug or a security problem so a project that is ready to be released anytime but is not because the release process is a drag so you procrastinate on it is worthless we and it leads to the back reports most people have already gotten who maintain any kind of software it's like oh my god the last release is so long ago is this even maintained you don't want that so you want to really fully automate if you look at it like releasing a package to pi PI it's just about replacing a bunch of strings running a bunch of commands and double-checking a bunch of outputs you just have to choose where to automate so some people like to use the CI to do the releases which I can understand why it's popular hypothesis very nice testing projects take this 211 so whenever a pull request is merged they automatically released a new version two pi PI so they have a really high really number version number right now I personally prefer a local automation to have more control and to be able to centralize my tools for all my projects so I will not be talking about CI at all but there's plenty of material about that if you're interested so centralizing tools that's quite important for me because as you've seen I'm maintaining quite a bit of project and I and projects actually do tend to multiply once you embrace the glamorous open-source lifestyle so I want to avoid duplication of code and duplication of knowledge so what I do is that I rely on conventions conventions that I can enforce because I'm in control of my project and because I can rely on conventions I only need one release script to push out all my projects that I need so let's talk about conventions so all of my projects have this block and this block is mostly about Python conventions but this one is mine like when in development my packages have the next version with a def 0 suffix attached to it and to make clear that it's not the last version anymore but it's also not the next version yet so when I release I just have to strip the suffix and the code is ready [Music] yeah we are running over time it's not my fault I was your time so when I release now so this is the canonical metadata for me for the package and I find it makes sense to make the code canonical and not some random files that are flying around and everything else just derives from it so my Sphinx documentation loads from there my set up the PI just reads it and parse it with a simple regular expression so you can come back yes okay can I go back to slide one I've lost my thread no he didn't say a time right so all right let me talk about my life no I'm gonna be really quick once I find my thread again all right so I can do the oldest magic of parsing files because I use setup tools that is one of the reasons when you use something like flit or poetry you will have to build those kind of tools yourself to avoid duplication like flit will use dunder version which is already pretty cool but the poetry issue trigger notably not Sebastian the maintainer himself told me to just ship my project amo which is their metadata file and parse it at runtime and I don't think it's great to parse files in your dunder init on every import because if you're gonna waste computing power like this you better get a Bitcoin out of it so I will I really hope that better method will merge but poetry doesn't doesn't seem to move a lot at the moment so you'll see now what else changed and changes with the release the change lock because he wants to add today's date please add the release date to your change lock change lock without dates really maddening because you have no concept of time and it is it it takes a lot of the value from unchanged lock so for me this means that I just have to replace the vert and released with the current date in a file called change log dog rst in a project directory there's like three lines of code it can be even at one line of code if you push it and technically the project is ready for release the version is correct the change log is ready the code has been ready all along so there's only one more I'm sorry there's only one more thing I do before each release at this I like to check all the links in my dogs for 404s for move content stuff like that and thanks to Sphinx this is super easy it's there's a command called make link check or if you're in Windows it's make bad link check and to build your code your documentation will go through all your links and check whether or not they work now I do not recommend to make this part of the CI because you get way too many transient failures this is how you learn how unreliable internet actually is and the last time the US government shut down we had this problem that a bunch of HTTPS certificates expires and nobody was paid to fix it so they were just broken yeah so before each release is fine though and just make sure that you're not shipping all dated links now we are ready to ship and shipping already packaged it's just a bunch of very simple steps and I've wrote a blog post about that if you feel unsure about it it's really simple you just commit the changes you just made you will get tech your version you built the package and you push it to PI pi using a twine tool that's all you have to do and congratulations your contribution is on pi pi I didn't have to do that much because everything I mentioned here and much more fully automated like I don't move a finger and everyone in this room and everyone who left the room because they thought the talks are starting can automate what I've said here it is really simple and the problem is probably it looks too trivial for people to want to automate these kind of things but automating even the trivial stuff will save you so much time and frustration and complaints of a lack of releases that it is worth it like after a year by the latest so I'm afraid this good I do there's so much more I would like to talk to you about like how to handle coverage locally and NCI how to manage change locks with tools like Tom crier which is really nice if you could get a lot of merge conflicts when on your change log file I had to kill like 20 slides just about documentation and how how to avoid duplication there and my eternal love will read the docs I had an entire rant about 79 characters being the only true line length I had an essay on how to prevent packaging mishaps like empty source distributions on pipe I news flash used an SRC directory and I had a whole TED talk about semantic versioning and how its Val intention but ultimately fundamentally flawed and should never be used but the schedule well if there's no schedule anymore but yeah it would be a cruel mistress but I hope everyone who's left could take something from this Roland and of course everything I said here and this is dick kind of gonna miss the plot twists everything I said is relevant if the project is your job you want to automate as much as possible especially things you do not do every day you want to have standardized build and release scripts you want to document the processes for our co-workers and for yourself in a month and you want to invest into short feedback loops because that will that will make you much happier they're developing and will increase your development velocity so that's all I have for you today check out the top page it's really a lot of material this time I promise it's worth it follow me on Twitter if you want to know how it is how it is to fly with a curse get your domain from viral media if you speak German I have an excellent icon LT and feel free to chat me up also I think tomorrow our EU elections in Lithuania please go and vote [Applause] yeah the EU has its loss but will it miss so much better than what we had before eternal war so thank you I'm connect thank you very much have a nice conference [Applause]