The Python Podcast.__init__

Share on social media:

[00:00:13] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.   When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode.   With 200 gigabit private networking, scalable shared block storage, node balancers, and a 40 gigabit public network, all controlled by a brand new API, you've got everything you need to scale up.   And for your tasks that need fast computation, such as training machine learning models, they just launched dedicated CPU instances.   And they also have a new object storage service to make storing data for your apps even easier.  

Go to python podcast.com/linode,   that's l I n o d e, today to get a $20 credit and launch a new server in under a minute. And don't forget to thank them for their continued support of this show.   And you listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis.   For even more opportunities to meet, listen, and learn from your peers, you don't want to miss out on this year's conference season.   We have partnered with organizations such as O'Reilly Media, Corinium Global Intelligence,   ODSC,   and Data Council.  

Upcoming events include the software architecture conference, the Strata Data Conference, and PyCon US.   Go to python podcast dotcom/conferences  

[00:01:33] Unknown:

to learn more about these and other events, and take advantage of our partner discounts to save money when you register today.   Your host as usual is Tobias Macy. And today, I'm interviewing Moshe Zadka about his recent book, DevOps in Python. So, Moshe, can you start by introducing yourself?  

[00:01:49] Unknown:

Sure. So my name is Moshe Zodka.   I've been using Python since, 98.   I've been using Linux since 95, and right now I'm working as senior site reliability engineer in SurveyMonkey.  

[00:02:00] Unknown:

And do you remember how you first got introduced to Python? I wanted to use a language to do, like,  

[00:02:05] Unknown:

some numerical analysis,   and   I kind of looked around to see what's kind of annoying back in 99 8. It's, yeah, it's still annoying for that. Perl didn't look like the right fit, so   I learned Python. And I remember that, like, the next day I was already productive, so I decided this is a good language.  

[00:02:23] Unknown:

And you've actually been on a previous episode talking about your experience   working on the twisted package and all of the adventures that you've had there. So a lot of link in the show notes for that 1.   But in this episode, we're talking about your experience and your book about using Python for DevOps. And so I'm wondering if you can talk a bit about your   experience   in using Python for managing different systems and some of the   jobs and projects you've been involved with that helped contribute to that overall experience.  

[00:02:53] Unknown:

Sure. A little before, like, the   concept of DevOps or SRE was a thing,   back in 2, 006, we didn't really have a word for it. So,   but often,   people with the type of infrastructure engineers would be using 1 of these things.   And I basically ran the infrastructure team at a small startup called Beehive.   We were basically   the whole company was using Python anyway. And I ran the infrastructure team, and back then that meant running the CICD,   the,   the monitoring system, and all of that. And I in 2, 006, we our tools were much weaker than what we have today. So I basically had to write a lot of stuff from scratch in Python.  

[00:03:35] Unknown:

And so as you mentioned, the term that a lot of people are using now for a sort of blanket way to encompass the entire realm of systems engineering and systems administration   and server automation is DevOps. So I'm wondering if you can talk a bit about what that term means, particularly in the context of how you're referring to it for the purposes of your book. Sure. So I guess it it's kind of interesting to look at it etymologically. Right? Originally, you had an ops team, and people would write software.  

[00:04:04] Unknown:

Those were the developers.   And they would, what we call, throw it over the wall to the ops team, hopefully, with some documentation,   and the ops team had to keep it running. And whenever it didn't work, the ops team had to figure out why they didn't work. Is it a configuration   problem, or is it a problem with the actual software?   And if it is a problem with the actual software, I had to go back to the developers, convince them that this is a problem with the software, get them to fix, get them to deploy it, get them to document how to use a fix. And this was very complicated. And especially when people started,   making software as a service,   they decided that, like, this is this is slow down slowing down the, development work, and we should unify it. So DevOps is a philosophy first and for all for most, that about   unifying the developer and ops in 1 team, not necessarily in 1 world, but in 1 team. And the DevOps engineer   is the 1 in charge of, we do things the operational complexity.  

And this is a little bit subtle because the ops engineer is the 1 responsible for shouldering   the operational complexity.   In the DevOps team, you don't have an ops engineer. You have a DevOps engineer who is responsible for reducing that. They do that partially by shouldering it, by partially by talking to the developers, figuring out how to make the software easier to operate, and partially by automating stuff.   And often the automation stuff comes with a little bit of an afterthought and like you want to get it fast and running.  

[00:05:29] Unknown:

And Python is a glue language that has interfaces to everything and is very easy to teach and is very fast to use, became a natural fit for DevOps. And this is kind of, I guess, some of the context for my book. And so for people who have been using Python for developing web applications or writing simple scripts or for doing data science, there are a lot of different ways that they use the language. So I'm curious in terms of your experience, what you have seen as being the unique aspects of how DevOps engineers and systems administrators   use software and the aspects of the language that they find particularly useful.  



[00:06:07] Unknown:

So there's a few things here. I guess 1 interesting historical note is, in some sense, Python was invented   to be what we now call DevOps language. It was invented to manage the, Amoeba operating system. The Amoeba operating system is of course long gone, but it was invented with a thought that it would be used to manage systems. So   this is important historically because we had the operating system model and, like, a lot of modules that are needed for   managing the underlying unique stuff very early on integrated into the standard library. And this is part of, like, why historically people were like, oh, I guess I already have all this interface to OISTAT, which is very useful if you want to analyze the status of a file or something like that, which languages like Java tried to obstruct the operating system away and didn't have a lot of these tools. So,   of course, this is different nowadays. A lot of managing systems now is done with, like, Web API and Python having great, Web API libraries such as Requests makes it also, like, a very good fit for, like, modern DevOps stuff. And in terms of the  

[00:07:14] Unknown:

particular aspects of using Python for managing systems, what are some of the general categories of the types of operations that Python would be used for in the context of systems administration   and systems automation?  

[00:07:25] Unknown:

First of all, the easy integration with the operating system means that often people will write scripts that run that use Python on servers that collect   information like metrics and logs and send them to some central place to be analyzed. So for example, the script that will run every few seconds and and grab the numbers from uptime and send it to a collection thing so that it could be analyzed later. Those things, of course, are really nice to use in Python because it's you you either get it from the from a web interface or you get it by running a command, or you get it by using an operating system interface, and all these things are good in Python. The other thing that often people use Python is automated common tasks.   Like, say, if you want to deploy something, often this is a multistep process. So for example, deploying you're gonna canary first,   then getting the data from the monitoring system to compare the canary to the   default system to check that everything is okay, and then doing the rest of the thing, and maybe there's a few steps, and maybe you want to integrate it with the staging system. So often these steps are very complicated,   and often, they're the result of a lot of postmortems.  

So there was a postmortem that said, oh, we should have first   checked it on this specific thing, or we should make sure that the canary is 1 on inside of all the data centers before launching it. And often these things get more and more complicated, and it's pretty nice to be able to fold all these things into some automated thing instead of making the script that a human has to follow more complicated and more error prone. And for people who are just getting started, particularly in Linux and Unix based environments,  

[00:09:03] Unknown:

the first experience that they'll usually have is using something like bash or c shell or z shell for doing some of these automation routines. And usually,   as you continue along that path, there gets to be a point where trying to use that as the automation language just becomes very difficult and clunky. And I'm wondering what your   experience and perspective is on sort of when the right time is  

[00:09:29] Unknown:

to stop trying to use some of the built in terminal languages or terminal environments and move to Python instead. I I I guess it's it's curious the way you phrase it because that it's almost my answer, which is as soon as you type vi,   it is time to write Python. And what I mean by that is I'll often write, like, pretty long things right on the command line, write a for loop with a couple of pipes, and that's all fine. Right? As long as I'm doing it on the command line, I feel like bash or z shell is a great thing. As soon as I type vi, I'll maybe even start with, like, you know, copying and pasting the bash thing to to have something to start with. But I feel like this is a a good heuristic. As soon as I actually feel like this is stable enough to be in a file, I'm gonna use Python. And partly because as soon as you put it in a file, this is also the about the time that people will want to send in arguments.   And using arguments in bash is very subtle, especially if you want to allow spaces or allow other special characters, and you have to start quoting hell. So as long as you do it on the command line, if you misquote, then you can immediately see the thing and and kind of ad hoc fix that. So as you put it in a file with someone else who want to use it with an argument that you didn't plan for. So I feel like that's that's kind of about the right heuristic. And in terms of your experience over the past several years, as you said, you've been using for Python for a while and working in the systems management space. I'm curious what you have seen as some of the most notable changes in the ways that Python is being used and some of the types of tools that are available for server administration over that time. So a little bit like I said, originally when I started out using Python for,   this kind of administration,   you didn't have cloud services. And basically, you ran your own servers, and you knew what was running on them, and you used Python to manage those servers. And that was very useful, of course. But now I feel like most people are running on something like AWS   or, maybe Google Cloud, or even if they run their own cloud, they're using Kubernetes. So the tool often what we use with Python   is a tool that are 1 level up from that. So for example,   AWS has a Botox 3 library, which is a really, really nice library for managing AWS. And I've often used Python with,   with BotoSuite to automate all kind of all kind of AWS tasks like pinning a cluster up or making cluster bigger or smaller. And then   often, nowadays, people use things like GitHub or GitLab, which also have great Python APIs. So often will people will use Python APIs to, for example,   spinning up a new repository or you'll make changes across several repositories automatically. So the focus has shifted a lot to a lot of web APIs  

[00:12:05] Unknown:

rather than direct operating system APIs. Yeah. And as you said, the sort of breadth of responsibility has shifted a lot to   from when it was just entirely server based, everything ran on a physical box, and you had to make sure that that box stayed up and running for a long time, and uptime was your primary concern. Now we're, as you said, dealing with these different cloud services and third party SaaS platforms. And so a lot of the context of where the Python is being executed is different, where it might just be something that you're running from your local machine and orchestrating all of these different operations versus   in terms of how you're using Python, where if you're running it on a server, you're likely going to be trying to minimize dependencies because you don't wanna have to maintain it across a number of different instances. Whereas if running it locally, you're more likely to reach out for different libraries because you are not as constrained in terms of the way that that will impact the system and the the versions of Python that you're trying to run on. So I'm wondering what you have seen as far as   the   sort of shift in how willing systems operators will be to reaching to libraries versus trying to write everything from scratch for themselves. So  

[00:13:22] Unknown:

I I feel like nowadays,   your ability to not use any library, to do anything really interesting with Python is very minimal. Like, for several reasons, right? When Python was starting out, we didn't have this great ecosystem. So the best way to do a baby PI was use Urolib or Urolib 2. When nowadays, everybody says just use requests.   So I feel like the the the minimum point at which you wanna start using a real virtual environment   via some setup, be it by a docker or DH virtualenv or just manually setting it up is a lot lower. Usually, I guess, if I said that you use Python once you have a file, you start using dependencies once you have a module or a library. And another aspect of the  

[00:14:06] Unknown:

Python runtime is that it comes as default on a lot of different Unix based systems, but it's not necessarily going to be the most recent version. So that might influence the way that you approach writing the Python that you're using for managing these systems. And then there's also the difference of if you're actually using Python as the   runtime for the application that you're trying to deploy onto these systems, it might be trying to target a more recent version than what's available in the operating system repositories. And so I'm curious what you have seen as far as some of the challenges that people face in managing the versions of Python   on their servers, and the likelihood that the   system runtime, the way that then the scripts that they're using to automate that system are going to be just using the built in version?  



[00:14:49] Unknown:

So I guess more and more of the common wisdom   is never use the operating system Python. It's it's it's for a lot of reasons. Right? On on Debian systems, for example, the operating system Python will be sometimes really surprising. For example,   you can have Python,   but not a lot of standard library modules that are in Debian package separately. So for the Debian use case, it makes sense. In tweeting, I think the operating system Python, especially on Linux system, is something that is for the operating system. Right? The user been Python that is packaged on say Debian or Ubuntu or CentOS is a very good Python   for the libraries that you get via Debian or Ubuntu CentOS. But for writing your own scripts, you usually wanna bring your own Python. This will make sure that you can control the version of it. And especially   now that, like, people will often use CentOS versions that, are very slow moving,   and Python is much more fast moving that is much nicer. And, also, that lets you control a lot of how it's deployed and make sure that you have all the bits and pieces that you need in Python. So I guess this is kind of like   the first chapter of my book is how to get the right Python in your system. And I think on Linux systems, usually, what I would recommend to people is using PYAN. Yeah. That's what I end up using for managing my systems. My work is just using PYAN for the  

[00:16:11] Unknown:

operating system repositories and   when it's actually   in the operating system repositories and when it's actually going to be updated because you either could be trying to run a version that's older than what you were initially targeting, or it might just surprise you in terms of when it updates and the types of updates that it brings along. So surprises are never a good thing in the operating system space. And then another thing too that you talk about in your book is packaging. And as you said, the packaging ecosystem   a number of years ago was a large part nonexistent, but at least very nascent. And, in recent years, it has accelerated quite a bit, and now it's getting to the point where we've got an embarrassment of riches where we sort of have the paradox of choice of which packaging system we want to use and sort of how we want to bundle up our scripts for deploying to these systems. So I'm wondering what your personal preferences are and maybe talk a little bit about how the ecosystem has evolved in recent years. Sure.  



[00:17:09] Unknown:

So, I guess, there there are couple of tools that I wanna think is built on top of PIP. And for for it's 5 times, I'm concerned like this kind of 3 popular   ones, plus 1 operating system specific 1. So the 3 generic ones are Portree, PIPEN, and PIP tools. And the operating system specific 1 is DHVOTROLINIS.   I guess PIP and   I'm I'm I'm I'm never sure exactly. Like, I've tried to run it a couple of times and never got the hang of it. Portree, I felt like it was much more built to help you develop Python than than to help you deploy Python.   So I really like Pip tools. So mostly what people Pip Tools does is doesn't really manage the installation, which I think is great because peep people take care of that. What it does is it it helps you lock down dependencies. And I guess, as you said, surprise is never a good thing when you deal with operating system management   or in general in programming. So you wanna know in in advance exactly which dependencies you're using. Pip tools is a thing that will let you go from abstract dependencies,   like this version greater or equal to this, to a complete requirement to TXT file that has exact dependencies plus hashes. So it's kind of nice. It will it also gives you a sense of security. And then when you actually come to deploy it, you you wanna use something like virtualenv,   and you can use virtualenv directly.  

You can use DH virtualenv if you're on top of a Debian system.   You can use,   Docker, if Docker is a good fit for your use case. And then we will still usually put a virtual end inside the Docker because it makes some aspects of, building the Docker image easier. I guess if if you want the reference for that, Hinek   gave a really nice talk about how to build Docker,  

[00:18:51] Unknown:

Python based Docker images a few years ago in Python, and he covered specifically why you should always use virtual AM for that. And in terms of the book itself, what was your initial motivation for writing a book about Python that was focused specifically on DevOps and server automation,  

[00:19:06] Unknown:

particularly at this point in time? So I I guess it it felt like there was, like, an an a need in the market. Right? There's, like, a lot of introduction to Python books. But then because they treat themselves with introductions, they won't cover even, like, the aspects I'll   write things I'll write things that don't even have a class in them. They're just a couple of function that tie together a couple of standard library modules. But mostly, what I need to think about is how do I get Python into the system? And   inheritance,   which   are   less   important   to   the   system manager, and and inheritance, which are less important to the system manager   than actually getting Python and the packages to work reliably, which the intro book doesn't think is a very important thing. So the focus is very different. And and I guess the other thing is that, like, it feels like a lot of people were using Python for DevOps, and they felt like I have a lot of interesting things to say about that. And maybe that could help people get better at it. Yeah. And for a little while, it was interesting because Ruby was starting to take over some of the use cases that Python had in terms of the systems management space, particularly because because of the popularity  

[00:20:20] Unknown:

of Puppet and Chef, which have recently been declining.   And SaltStack and Ansible have been becoming more prevalent and taking over a lot of that same popularity. So I'm wondering what you have seen as far as how those tool sets have influenced the direction   of Python in the systems automation space and the ways that people are engaging with Python in that context. So I I guess my my funny anecdote on that is that I recently met,  

[00:20:46] Unknown:

a very nice developer from the, Ansible team. And we we talked a little bit about how people use Ansible. And when people start using Ansible, it's mostly by writing a lot of YAML files. And as soon as they need something interesting, they'll start going into like Ansible channels or Ansible Stack Overflow and asking how do I do it in the Jinja thing that, Ansible does it. And the answer is always the same. As soon as you have to ask these kind of questions,   stop doing it in, like, the the ginger thing that generates the YAML thing that Ansible consumes and start writing Ansible modules. So the nice thing about Ansible and SaltStack is they don't hide the fact that they're in Python. They expose it as a feature, Meaning, you can write extension modules for SoulStack and Ansible that will do other things.   And if you have a custom environment that syncs in its own way, you can write higher level obstructions and implement them in Python. And part of it is that this feels, to a lot of people, like a big jump. Right? I was just kind of writing a little follow-up in Jinja, and now you're telling me to start writing Python code and and using a real operating system. And this is kind of a good point where, like, you know, maybe a nice introduction to Python for for, system administration is useful. Yeah. And 1 of the nice things as you said about the Python and Ansible ecosystems is that if you do if you are familiar with Python, you can take them quite a bit farther than if you chose to only use the facade that they provide. And also SaltStack, I know, has the option of actually using Python as the syntax that you use for actually building your configuration management and issuing the YAML and Jinja combination  

[00:22:20] Unknown:

for people who don't want to go down that road. So if you like to, you actually can go entirely native Python using the DSL that they expose. Yep. Yep. And that that's a really cool feature that,  

[00:22:30] Unknown:

I feel like it's really underrated to use Python because YAML is just a way to specify a dictionary and, like, it's really nice to build dictionaries in Python. It has strong literals   plus strong programming. So, yes, the the fact that SaltStack,   exposed it is pretty cool. I like that. And another interesting  

[00:22:48] Unknown:

development in recent years in this context of systems administration   is the introduction of Python 3, which has been around for quite a while, but it has become increasingly the default for different   interaction between Unicode and strings and bytes objects, and that those are particularly prevalent   in the systems domain because of all the networking that happens and dealing with file objects and things like that. And so I'm curious how you have seen the Python 3 transition impacting the lives of systems operators.  

[00:23:23] Unknown:

So it's it's funny that you use strings and bytes and file objects as, like, the biggest thing to change because superficially, yes, this is the biggest difference between Python 2 and Python 3. But I feel like for a lot of people who have waited,   a long time, I guess, longer than it would be ideal,   what happened is that a lot of libraries started dropping support for Python 2. And when you try to upgrade to Python 3, sure, you can deal with, like, the few strings and bytes you had in your code to upgrade them, but you also have to jump versions of library. And I guess in my experience, this this has always been the the bigger hurdle, the jumping   versions of libraries. The biggest library, like, requests or twisted, were pretty careful, but other libraries started doing it quite a bit earlier, especially, like, they would not support Python 3 in the old version. So if you need even support for Python 3, you have to jump a new version. And this is this is this is the biggest pain in my experience. I mean, in managing that, of course, is very subtle. You often want to jump the libraries before you jump the version, and just coordinating that, it's been a huge hassle. And I guess, people who manage systems tend to be the most conservative people.  

So they waited the longest and and kind of have seen the the most pain from that. So   mostly, it's I I kind of think of it as a bad episode that I'm very happy has  

[00:24:39] Unknown:

mostly reached its inclusion. And we've we've we've kind of suffered, but now the suffering is done. We don't ever have to think about it again. And 1 of the other aspects of the transition to Python 3 is that there are new built in modules in the standard library, including things for managing IP addresses. And so I'm curious if there are any of those new,   standard library modules that you found particularly useful.  

[00:25:04] Unknown:

I I guess not because even towards kind of like, you know, Python 2.6,   already there were such,   such good modules in the in the ecosystem that sure it's it's kind of nice maybe that it's standardized in Python,   but that didn't make like a big difference in my life, like all these,   the IO module and string IO. It's it's kind of a bit nicer, but that's definitely not where the biggest difference is. And going back to the book,  

[00:25:30] Unknown:

I'm wondering what your process was in terms of determining what were the particular topics that you wanted to cover and how to lay them out and what level of depth to go into and sort of what you had in mind as  

[00:25:43] Unknown:

the level of experience for the target audience. Sure. So I guess with the book, I kind of I I had kind of, like, I guess, 4 things that I kind of wanted to cover. So the first big chunk was, you know, like the book is called DevOps in Python.   But the first big chunk is actually the opposite.   It's Python for DevOps engineers. And this means covering the like, if you want to learn the language, you read the tutorial, you can literally learn the the entire language tutorial in in 1 day. But if you want to get the aspects of Python that are useful for DevOps engineer, which means, how do you deploy Python? How do you, use packages? How do you ship packages? How do you configure it? All of that, there's no good resources. So the first and I remember when I when I was talking with my publisher about it, they were like, isn't there usually someone in the company who does that? And I said, yes. That's DevOps engineer, and this is the person I'm trying to reach you as a book. So the first chunk is, like, we need Python for DevOps engineer. The next 2 chunks are what I feel like is, like, the the the the most common tasks in, when managing unique style systems, which are the most popular system to manage. And that's the first direct operating system interfaces. So So how do you manage processes,   and files, and stuff like that? And then, UNIX, historically, has always been a very text oriented   some of the common kind of text manipulation things. Not at the level that's, like like, big books about text manipulation in Python, but at least the common bread and butter things that you have to do with,   Unix system administrator.  

Like, you know, getting CSV files, parsing the spaces out, stuff like that. I felt like we should cover that. And then the 4th big chunk was kind of managing systems as a distance, I guess, you can call it. So I covered,   stuff like Ansible, stuff like Solstack,   how to manage AWS, how to manage Docker,   which are kind of like the most what what we would call kind of a modern DevOps  

[00:27:43] Unknown:

job. And were there any aspects  

[00:27:46] Unknown:

of writing the book where you ended up being surprised as you started to dig into the subject matter? Or any particular challenges in terms of how to represent the material in a way that was accessible to the target audience? So I I guess 1 1 of the interesting things was, my publisher and I kind of really talked about, like, covering Ansible and SaltStack. Because the the publisher had kind of not a great experience with covering those because they said that those systems kind of move really fast.   Right? So if you try to document Ansible, you find it, you could documentation it out to date with the next version because a lot of the modules are different. And so instead of focusing on the modules, which I feel like the online documentation is good and also they move fast, so book wouldn't be useful.  

I focus on the underlying concepts which can't change this fast. So I covered,   how to do extension modules for Ansible and how to do extension modules for full stack,   which not a lot of resources do cover, but they feel like that was something important and also something that they have to keep stable because they wanna make sure that modules are useful,   between versions.  

[00:28:49] Unknown:

And so for people who are coming to the book, who are trying to figure out the best ways to use Python for managing different systems, what's the sort of next step after they've read the book and gone through the material? Are there any useful resources or references   that you can suggest? Or sort of what's the   level of familiarity   and capability that you expect them to be at by the time they finish?  

[00:29:13] Unknown:

So I guess, by by the time you finish the book, you should at least be able to   automate, say, simple AWS tasks or automate simple GitHub tasks. I guess, AWS is cheap enough that,   if you just, you know, kind of   get, like, a $20   gift card and and put start an AWS account, you can play around with that and see   how how did it work, how you set up a service, how you would even, like, build the Docker system using the tricks I teach in the book, and kind of,   like, make a whole thing from, like, from source to deployment   with, with 1 check-in,   which is always a great exercise for DevOps because I feel like this is often where people are trying to go. Right? Like, the whole continuous deployment.  

And I feel like it's a good exercise for, people who want to do Dev ops because this will teach you where the hard things are.  

[00:30:03] Unknown:

And are there any other aspects of DevOps   or the ways that Python is being used in that context or your experience writing the book or anything along those lines that we didn't discuss yet that you'd like to cover before we close out the show?  

[00:30:15] Unknown:

I guess 1 more thing, which is we we talked a lot about the technical aspect of DevOps, but DevOps is is a very human oriented   discipline. Right? Like, a lot of the skill of DevOps is to know how to talk with developers and to talk with people who are more operationally focused and figure out what they need, what pains them, and how you can help them. And often, if you can't help them, try to communicate what is the problem in in in doing what they want and that you're still feeling that they are in pain, but you can't solve this problem for them. So in general, I feel like empathy is a very important,   skill in DevOps.  

This this is not their actual issue for my book, which do not teach that skill. But if you do want to be successful in the discipline,   this is no less important than understanding Python, understanding Unix.  

[00:31:01] Unknown:

Alright. Well, for anybody who wants to follow along with you and get in touch, I'll have you add your preferred contact information to the show notes. And   with that, I'll move us into the picks. And this week, I'm going to choose the salt stack package because I've been using it for a number of years. I may have picked it before, but it's definitely a tool worth checking out, particularly if you're working in the DevOps space because it has everything you need as far as being able to manage systems, including   handling, deploying new instances,   configuration management, software delivery. So it's a pretty powerful framework, very flexible. So   there's definitely plenty of room for hanging yourself, but there's plenty of ways that you can use it productively. So definitely worth taking a look. And so with that, I'll pass it to you, Moshe. Do you have any picks this week? So, yes, my pick is the automat  

[00:31:47] Unknown:

package.   Automat is a framework for, doing finite state machines in Python.   I've written a little bit a little bit of a blog post about it once. But the idea is that often you have things that have state. You can't do that while you do this, and you can't do that while you do that. And often you find yourselves   in a mess of booleans and enums that document which state you're in, and having a lot of if statements and automat,   is a is a great framework for making sure that you can write this with a lot less bugs while still keeping the outside interface of a plain old Python object, which is something that some other finite state machine packages don't give you, which is why I like automat specifically.  

[00:32:25] Unknown:

Yeah. And I'll point people in the show notes to a link to the episode that I did with Glyph talking about that. So definitely an interesting package and worth checking out. So I'll second your choice there. Awesome. Thanks. And so with that, I'd like to thank you for taking the time today to join me and discuss your experience   of using Python for managing systems and writing a book about that to help other people learn how to do it. So I appreciate all of your efforts on that front, and I hope you enjoy the rest of your day.  

[00:32:53] Unknown:

Thank you. Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at at dataengineeringpodcast.com   for the latest on modern data management.   And visit the site at pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes.   And if you've learned something or tried out a project from the show, then tell us about it. Email host@podcastinit.com   with your story.   To help other people find the show, please leave a review on iTunes and tell your friends and coworkers.