Python Bytes - #117 Is this the end of Python virtual environments?

Episode Date: February 14, 2019

See the full show notes for this episode on the website at pythonbytes.fm/117

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 117, recorded February 12th, 2019. I'm Michael Kennedy. And I'm Brian Ocken. Hey Brian, how you doing? I'm great. Excellent. Great to hear. Great to hear. You haven't been flooded out in this torrential rain that we're having around here?

Nope. And I survived snowpocalypse. Yes, so did I. My rain jacket got me through. Yeah. This episode is brought to you by Datadog. Check them out at pythonbytes.fm slash datadog. All sorts of cool monitoring stuff. Tell you about more later. Brian, the first

thing you have queued up here is super exciting to me. Hit me. Okay, well, in 117 episodes, this is the first time we collided and both picked the same article. Because it's good, because it matters. Okay, so here is Goodbye Virtual Environments. What?

Well, I don't know about that. Is this just like pseudo pip install into like root? Is this what they're just like, forget it, it's too much, we're out of here? Well, so we have a lot of solutions to this. So this is an article by Chad Smith. And apparently this is referencing PEP 582, which is a local packages directory PEP improvement. Okay, so here's the premise. Virtual environments are awesome, but they have some problems.

The learning curve bit. So when you're trying to teach people how to use python you want them to have a safe environment so you start them off the virtual environments and you have to like teach them about all this gunk and they don't even seen any code yet so there's that problem right and if you close like your terminal yeah it'll come back and you're like oh man i forgot to reactivate it like why won't this run i mean you know once you get into it it's fine but like as a new person you're like why did this work before and now it doesn't super frustrating right so that the proposal is if you have a directory sitting around in your local say called under pi packages so it's two underscores on each end pi packages as a. It's just sitting there,

doesn't have to have anything in it. The idea is if you pip install while you're there, instead of installing it in the site packages or anywhere else, it'll just install it in this local package directory. And you don't even really have to care what it looks like in there, but it's there. And then, so there's a couple changes. It's got a pip has to change, but also Python has to change because Python has to include looking for a PyPackages directory locally to see if something's there. Some of the neat things about this is that it's not where you're calling it from. It's not your current directory when you're calling a module or something. So let's say somebody is just somebody that's writing a Python script and it has some dependencies.

They could have a PyPackages directory right next to their script. And then as long as their script is in their search path, Python will pick, run that. And then if that module has some imports, it'll try the local packages first. So that's kind of cool. I think that's it. Yeah, I think this is fantastic. And if I could take all my votes for what I'd like to see added to Python, certainly more than one would go towards this.

So I think this is great. It's basically like what Node does with Node modules and other things. There's a convention that if there's this folder in the root of your project and you run code, it will try to use the modules or packages in our case from that location. There's no more activating. There's no more deactivating. None of that. You pip install. If it sees dunderpy packages, it installs it there. You Python run. And if it sees py packages next to your file or in the working directory, it uses that from there as if it were a virtual environment, you don't have to keep activating it

and deactivate it and make sure it's the right one. And it already follows a convention that so many people already do either create a V and V or dot E and V folder at the root of your project. So many people do that. Editors like PyCharm and VS Code automatically detect and activate them. But this would just solve that problem flat. I love it. Well, it solves most of the problem. I love it. What problems does it solve? Where do you see the challenges remain? So this article also, it's kind of cool that it has this little trial thing, you can install a Python loc package to try it out. So I tried it out.

And one of the things that's missing is your entry points. So like, let's say I'm installing a command line, some utility that has a command line interface. Where do those go? They actually go in this PyPackages directory also, but they're not obvious where they are. It's not difficult to find them. There's a bin directory in there. In order to be able to use them, you'd still have to modify your environment, like your bash environment or something.

I see. So like, for example, Pyramid has a P-Serve web server that comes when you install it, and it's just in the Python path. So you'd have to do some kind of mechanism to make that that be active yeah or like pytest or talks or so many things have little extra things that go with them yeah i mean i guess you could usually do python dash m of that thing but that's pretty clumsy compared to like just typing pytest yeah okay yeah gotcha i'm all for this i want it to happen but I don't think virtual environments are going to go away unless we have, maybe they'll just be, you can have some extra thing in your path or something in your bash environment or whatever that says,

Hey, also look here. Yeah. Well, what I would like to see, I mean, maybe like this dunder pie packages is a virtual environment that you just don't have to activate,

but you could, if you want to run these types of utilities that you're talking about. Yeah. That would be a pretty good compromise, I think. Anyway, good thing. Doesn't solve everything. But I think it's a super step forward because it doesn't impose some opinionated behavior and workflow and other tooling to replace. It's like it just now works.

I run Python. It works using the packages that I meant for it to use. I run pip. It installs them into the proper place generally that I meant them to do and so on. So I like it. And the getting new people up to speed on stuff quicker, getting, being able to isolate installs,

application development. There's so many benefits here that that, yeah, it's great. Yeah, love it. So yeah, definitely vote for that over some of the other options. Super cool. So Brian, I got some bad news today. You do? Well, you know, my life's pretty good given that I'm calling this bad news.

But I learned about this thing called Google Lighthouse. Have you heard of this? I'd never heard of this. No. So Google Lighthouse is a thing that will analyze your websites basically for how well they're going to rank it based on a whole bunch of factors. People have heard of SEO. So you've got like, of course, you should have your title and your head and your H1s and all this stuff that you need.

But this is more about the behavior of your web application. So is it responsive? Are your images, do they fit on like phone screens? Does it return data the right amount of time? Are you serving like old style images that are too large and you could re-encode them in small, like a huge bunch of these types of things. Are you bundling and minifying your CSS and JavaScript?

So I sent my site through there, which I consider to be blazing fast, because if you go to like talkpython.fm or some of the other ones or pythonbytes.fm, although I've been cranking on talkpython first before I break pythonbytes, if you go to the homepage, it renders like out to the network in 15 milliseconds. And I'm like, well, that's pretty much as good as it's going to get, right? Maybe I could shave two milliseconds off it, but who cares, right? It's so fast. But when you look at all the CSS and all the JavaScript and the way it renders and the images and everything, it turns out that that could be better. And I knew that it could be better, but I didn't realize how much Google was sort of punishing my site for it. So I went looking and I found this cool Python project called Web Assets. I'd never heard of it. Yeah. So I went looking and I found this cool Python project called web assets.

I'd never heard of it. Yeah. And I found it on Python, awesome Python. So I went there and said, well, what can I find for like minifying JavaScript and bundling CSS, like five CSS files into one and whatnot. So this is a Python package you install. You basically create an environment that registers your settings like here's the static folders if you're going to generate files like if you're going to take five css files minifying them and like mush them into one giant file that can be gzipped right if you do that where do you save it all those kinds of things yeah what transformations you want to apply to it like bundling and minification or whatever you configure that you give it a list of files, and then it will just bust out a new one onto disk,

and you can just start serving that instead. You just take away the five CSS links, and you put in the one. It also has built-in Flask, Django, and Pyramid support, so it integrates in there. But to me, it looks like a whole bunch of stuff that's getting in the way of your web app working, whereas you can just ask it to save a file that gets served out of nginx and doesn't touch your python code that seems nicer so that's what i'm doing i don't want to integrate it into my app but if you wanted to go that path

you certainly could it's a really cool little thing oh neat so talk python is faster now it is much faster it now has a like a best score or whatever on Google's Lighthouse, basically, which will help it rank higher in Google search results, which is also pretty awesome. Yeah. So, yeah, there's a bunch of cool. And so anybody doing anything with the web, they should look at their website in Google Lighthouse, which I have a link to. And then one way to address some portion of that around your static files anyway has to do with web assets. So that's a pretty cool thing. Awesome.

Yeah, and it's all Python goodness. Yeah. And the next item, have we spoken about packaging? I think we might have touched on it once. Yes. This week? Have we spoken about it this week? Not yet.

Let's do it. Sort of we kind of have in a sense, but let's go. What's next? Okay. So we've got actually a three-part series of articles by, I think his name is Bernat Gabor, and he is one of the maintainers for talks and virtual environment and a bunch of other stuff. He's with the Python Packaging Authority, and he's right in the thick of all of this

changes in packaging and everything. He wrote kind of a three-part series. The first part is the state of Python packaging, which is just kind of a nice overview of what are we trying to do and what is the issue and all that stuff. We've got a bunch of like a directory full of a source directory, and you want to share it with other people. And how does that all happen?

And how did it happen in the past using setup tools and all that? And where are we at now? And then some of the problems, you talked about some of the problems with, I guess it's kind of hard to hand wave this, but it isn't just source files that you just copy from one computer to another. Sometimes there's C parts to it that need compiled for different machines. Even Fortran in the data science world, you got to compile like crazy stuff, right? Yeah. And so there's that part of it. And that's included in all of this packaging mess. And then on the other side, when you're trying to install it, if you just grab the source distribution, then you have to compile it on your side. But you have to make sure that all the compilers are available and all that stuff. And it's kind of a mystery black box with a lot of scary guts inside because it's a scary problem.

It's a hard problem. Now, moving towards things like wheels are pre-compiled. So you build everything before you push it up. And then clients just can just sort of download it and unpack it. But in order for this all to work right, there's a lot of moving parts and it's all being done by people in there volunteering their time. And that's why I love this set of articles. It's from the inside talking about some of the hard problems, why they did what they did, some of the breaks that happened and why they happened and moving forward. And I want to read one article. It's actually the conclusion,

one bit of it. It's the conclusion to the third article. It says, packaging is hard. Improving a packaging system without any breakage where users can write and run arbitrary code during the packaging in your free time is probably impossible. Yeah, that sounds about right. Yeah. They said, granted, as we go through this change, some packages might break and we might disallow Yeah, that sounds about right. error report with what went wrong, how you tried to use it, and what is your use case. And I guess I have to speak from experience when we just, when I started trying to, even when some of the same involved people were working on some of the transition to the new PIP server, IPI, it's a similar sort of situation, I think is when when we change the way we do things some people get upset and just expect it to all just work for free but please keep your head and

read this article it's a great series of articles on where we are and i'm it's going to be hard yeah i'm not even going to try to summarize it but it's good yeah it sounds like a great write-up did you know if they he mentioned the pep the one you just mentioned there, what was it, 582? No, he didn't reference that. But there's, of course, reference to 517 and 518 that dealt with the PyProject.toml and stuff like that. Yeah, cool. All right, well, you know what? All this means to me, the way I perceive it is, like, people are trying to solve this problem.

They know it is a problem. And I think if we get it dealt with as a community, I think it'll be a massive, massive benefit. I mean, I was just talking to someone the other day at a conference here in town. And he was like, oh, well, Go is so awesome. I'm like, okay, tell me why Go. Sell me on it. Why is Go so awesome? He's like, I press a button.

I compile it. I get a single binary I can give to anyone. And they can run it as long as they're on that platform i'm like yeah that's a benefit that would be nice wouldn't it if there was a like python space build option so very very cool but there's a lot of stuff coming and a lot of work being done on it like we talked about pi oxidizer recently as well yeah quite cool yeah one more thing thing before we move on. One of the things he brought up is Flit. Flit uses the new Toml style. The implementation of Flit is built on top of distutils and all that stuff also.

And that's one of the things moving forward is some of the stuff and some of the changes, we'll be able to kind of simplify the maintenance of a lot of these extra things. Right, because they do a lot of work to piece it together and paper over the challenges, right? And if the underlying bits changed, it got easier, well, maybe they just used the easier foundation, right? Yep. Nice.

All right, let me tell you about Datadog before we get to the next one. So Dat has been a long time sponsor of the show super thanks big thanks to them and they're a cloud monitoring platform built by engineers for engineers they're tracing client auto instruments popular frameworks like django flash tornado and so on so you can quickly visualize the flow of data across your application architecture not just how's my django app doing but how is all my infrastructure and moving parts doing they also integrate with over 250 technologies like hadoop and redis allowing you to pivot seamlessly between distributed request traces metrics and logs so check them out and get a

free trial as well as a cool datadog t-shirt over at pythonbytes.fm slash Datadog. Really helps support the show. Cool. Yeah. Brian, I picked this one to be custom picked for you. Like you should, this was the one you could have chosen, but I got it today. I beat you to it. Okay. All right. So this one is a cheat sheet for mocking in Python. So mocking, not the insult, but the ability to change the behavior of some deep internal parts of your application without rewriting them. Super powerful testing feature, right? If I want to test how my data access layer works, but I don't want it to actually touch the database, or I want to test how my credit card system works, but I don't really want it to talk to Stripe or whatever, I can mock out different parts of that and basically inject behavior into my app, right?

Yes. So mocks are built into Python, right? That's great. You can just import mock and start doing stuff with it. However, there's a lot of different ways in which you can do that. And there's also a lot of features. You could use mocks the way I described them there, which I think is sort of making your test decoupled from your dependencies. But you can also

say, I would like to kind of look inside the behavior and make sure certain parts of my app are using functions that I want. Like, for example, I could say, I'm going to call the login function, or the access, let's say admin part of my app, and I'm going to call the login function or the access, let's say, admin part of my app. And I'm going to make sure that it's checking is admin on the user. If it talks to the admin section and it doesn't test whether or not I have the permissions, something's badly wrong. So you can even verify that things were called with an assert called ones and so on. So this is a nice write-up that takes you through all the different things you can do

with mock and like quickly gives you examples for those various things, like how to use a mock as a decorator, how to use it as a context manager and on and on and on. Great. Yeah. Nice. Yeah. So all those folks out there who are testing or want to start testing, or even if you don't test because testing is too hard, you're like, well, all this stuff happens when i call this function how am i supposed to test it mock here you go yeah one of the things that's nice about having it not just completely tied with testing although that's definitely where it's used a lot is uh we can like some applications that have like a i don't know a debug mode or a some other mode that they operating in. You can even build it into your application to flip a bit or something, and it turns some of the system off.

Yeah. And you can use mock for that if you don't want to build it other ways. Yeah, I guess you could, right? You could fire off the mock if you want the login to do nothing, right? I'm going to create a mock that replaces this file behavior or whatever, right? Yeah, or if you wanted to switch out for diagnosing software issues or debugging, you can switch out your database interface with some other database entry or something or whatever. Yeah.

I don't know if very many people do use it for that, but you could, definitely. Yeah, very cool. All right. Yeah, mocking is super powerful. What do you got next? I have just an article about conference speaking. So Saron, and I'm not going to try to pronounce her last name. Do you know how to pronounce it? Yitbarek. Sure. I'm going to go with Yitbarek. Okay. I know her from the Coder Newbie or Code Newbie or something. She does a podcast and she's been doing quite a bit in software to try to get more people involved with software. And she's been doing a great job. But one of the things that she wrote recently was just talking about if you're giving a technical talk, just

improving it. And I love this because it's just a zero in on one little bit to try to make presentations better. The article's called Transitions, the Easiest Way to Improve Your Tech Talk. Improving how you speak, public speaking, is part of one of the things I work on personally. So I'm going to, before we get started, I'm going to grab a quote that I got read recently from Jeff Atwood from Coding Horror. He said, the people who can write and communicate effectively are all too often the only people who get heard. They get to set the terms of the debate. And I think that definitely applies to public speaking as well. So that's one of the reasons why I picked this up. But one of the things that, so Saron mentioned is the typical way people will default to presenting something is

they get, they put their stuff that they want to talk about on slides. And then they talk about whatever's on the first slide. And then when they get to the end, and then they pause, click to the next slide, and then talk about the new topic. This is where the focus is of this article is to try to work on those transitions. And it's a simple thing. I think it would take practice. It's definitely something I'm going to practice. But as an example, she talks about transitioning from one slide to another.

Instead of pausing, you can have a sentence transition as well. So you can, for instance, say, and that's why documentation is important as we see on this slide and span that sentence over transitioning from one slide to another and you can even time you're clicking from one slide to the next and how you transition a sentence from one to the next this totally makes sense and and we've been doing it in writing all the time transition sentences in in, and we've been dinged on it throughout school, but somehow we forget to do it while talking. So I just wanted to bring this up and highlight

this article. I think this is great. It's such a good recommendation. And when I first started doing in-person training, you know, standing in front of, you know, 20 people giving technical training is highly nerve wracking, especially when you're new to it. And it's easy to get derailed or try to like, you'll kind of fall back to reading your slides, which is like really not very engaging for anybody. So the thing that I found was super helpful is if I could have one sentence that's engaging, like this is how I'm going to start this slide. Everything is just downhill and like smooth from there. And this really seems to kind of capture that same idea. Like every part of your presentation, if you can start it well, and you feel good, like, yeah, this is going great. Like you just, you have that natural

momentum that just keeps going. But if you start it clumsily, it distracts you and it just goes downhill in the wrong way. Right? So this is actually a huge benefit, I think. But it's so easy. Like, can you have one sentence for each major concept in your presentation? I might be 10. Like, how hard is that? advantage of the end of the slide to take a little micro break. And it's nice for me, but it's kind of annoying for the viewer to sit there and watch nothing as the person transitions from one slide to another. But now she brings up that there's definitely times where you really are transitioning ideas, that it's perfectly fine to take that little break. It gives everybody a rest a little bit and you're moving on to a new topic. That's a great time to not talk while transitioning. Yeah. Silence is important too, right? Like people too often think I have to be absolutely continuously making noise, right? But like a few seconds of silence as a point sinks in or you are transition ideas, it's also really valuable.

Yeah. Anyway, so cool. Cool. Great pick. So it's so cool that PEP 582 is presented as an idea, but there's this problem. Like since Guido has stepped down, there really hasn't been any way to even address these PEPs. Right. Because how the decision-making happens, it's just been on hold, right? Yeah. So maybe that PyPackages thing is just going to be in limbo forever?

No. Finally, we have good news. The final governance model for Python was chosen to be the steering council model. And the people who populate that council, the first steering counselors, I don't know if you call them that, but I'm calling them that,

the first steering counselors have been elected. And so our new technical leaders are Barry Warsaw, Brett Cannon, Carol Willing, Guido van Rossum, and Nick Coghlan, all great folks. And congratulations to them. And this is a news sent to me from Joe Carey. So thanks, Joe, for sending that in. Yeah, that's awesome. I think very good pick. So of course, there's tons of great people we could

have, that would have been fine, but these are good, good set. Yeah, I think it's a great set as well. I think one of the things that's really cool here is we have Gita Van Rossum is not gone. He didn't just go like, you know what, I'm going to go do Go or whatever right he's still on he's still on the steering council he's still part of python he just doesn't have to bear the brunt of all the friction of moving it forward on him himself alone right so he's he's still part of this which i think is great yeah also have ac carol willing on there that's really good so very very good news all right so it looks like maybe stuff will start happening around Python, which is long overdue, actually.

Yeah. They still have a lot to figure out, but we will report it when we hear more. There's a bunch of good things happening in the community, a bunch of good ideas being proposed, like this pep we talked about at the opening. And until this stuff gets finalized, it just literally cannot be addressed or any action can be taken. So it's really good to see this taking place. Yeah. All right. Well, Brian, that's it for our six main items.

What else you got for us? Well, I got interviewed recently. So I got interviewed for the IT Energizer podcast. Right, with Phil Burgess. Yeah. Yeah. And you've been on there too. So we're going to drop a link to both of ours interviews in the show notes.

But mine's better. So listen to mine. No, they're both good. That's great. So we're going to drop a link to both of ours interviews in the show notes, but mine's better. So listen to mine. No, they're both. That's great. I hadn't listened to yours yet. I knew you were, had been interviewed,

but it hadn't been out yet. So I'm looking forward to listening. Yeah. And then also I, I'm sorry, I can't remember who sent this to us, but somebody mentioned to us that a PyCon Latin America is coming up in Puerto Vallarta,

Mexico on August 29th. And the call for proposals is open until May 31st. That sounds super. It would be great to go down there and spend some time while it's warm. And it's in the summer, right? A lot of people have maybe a little more flexibility. Yeah, so call for proposals. Get them out there.

Plus, it's in Puerto Vallarta. We should go. Exactly. We have to go do a live podcast recording because work. Yeah, but so if somebody wants to sponsor us to go down there, that would be awesome. Yeah, that would be great. So, there's something wrong with this episode. We haven't really fulfilled our

duty. I don't think we've even mentioned Anthony Shaw yet on this show, have we? I'm not sure how Anthony is part of this. He's so prolific. He seems to always have something on the ground. Okay. So we've got our joke section,

and you put a list on our database of show ideas as this list coming from Anthony, but it's not his list, is it? Or did he just tell you about it? No, he just said, hey, Michael, you should check out, or hey, Python Bytes, you should check out these jokes. So they're not his jokes. They're just transferred to us via him.

Okay, I couldn't pick one, so I've got a few. All right, hit me. Okay. What's the second movie about a database engineer called? The Migration. Oh, that would be good. No, the sequel, of course. Of course, the SQL sequel. I love it. Perfect. All right. These are like programming dad jokes. I love them. What. All right. These are like programming dad jokes. I love them. What's the next one? Yeah, programming dad jokes. Okay. This one is not false.

It's funny because it's true. Okay. These are bad. And this last one, I actually laughed out loud at this. So, a programmer's spouse tells them, would you run to the store and pick up a loaf of bread? If they have eggs, get a dozen. The programmer comes home with 12 loaves of bread. That's right. They must have had eggs. All right. These are great. These are great. Thanks for putting these in here. So awesome. Very cool.

Just for everybody that's annoyed with these jokes, we keep getting feedback from people that they like them. So they're going to stay in there. Yeah. People seem to love them, even if they're bad. Thanks. These were funny. Yeah, thanks for doing the episode. Talk to you next time. Talk to you next week.

Bye. Thank you for listening to Python Bytes. Follow the show on Twitter via at Python Bytes. That's Python Bytes as in B-Y-T-E-S. And get the full show notes at PythonBytes.fm. If you have a news item you want featured,

just visit pythonbytes.fm and send it our way. We're always on the lookout for sharing something cool. On behalf of myself and Brian Ocken, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.