Python Bytes - #187 Ready to find out if you're git famous?

Episode Date: June 26, 2020

Topics covered in this episode: LEGO Mindstorms Robot Inventor supports Python Step-by-step guide to contributing on GitHub sneklang Oh sh*t git Why I don't like SemVer anymore git fame Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/187

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 187, recorded June 17th, 2020. I'm Michael Kennedy. And I am Brian Ocken. And this episode is brought to you by us. There's a couple of things that we're offering that I think are going to be great for you. We'll talk more about that later. Right now, I want you to bring us back to our youth, Brian.

Did you ever do the LEGO Mindstorm thing? No, no. LEGO was just bricks when I was a kid. Yeah, well, yeah, okay. want you to bring us back to our youth brian did you ever do the lego mindstorm thing no no lego was just bricks when i was a kid yeah well yeah okay i love legos and actually i've got like three kits halfway done right now one of them i've been working on for a long time i should finish those anyway because there's a new one i want to buy it's not out yet but lego announced mindstorm robot inventor they've had different mindstorm kits in the past for robotics and they started It's not out yet, but LEGO announced Mindstorm Robot Inventor. They've had different Mindstorm kits in the past for robotics, and they started in 2006, or at least in the Mindstorm series.

NXT was in 2006. They did NXT 2.0 in 2009. And then the EV3 was in 2013, and I was actually kind of disappointed with the EV3 because it was weird. It was like a post-apocalyptic thing going on. It was like punk rock robots or something. I don't know. Anyway, so I think we've got an NXT somewhere in the house, but the new Mindstorm robot inventor, they finally figured out that people are using these things to try to teach in STEM education and stuff. And so the new one, this is awesome. Drumroll, it supports Scratch and Python. So that is super awesome. It has instructions for five different robots that do lots of different

kind of cool things like a car-like robot and an upright-like robot. And there's a bunch of sensors. The module that it has connects to six different input output ports for sensors and motors. There's even a six-axis gyro and accelerometer, a 5x5 LED matrix. 5x5 is not much, but we can probably figure out. We can hack more. Color sensor and distance sensor, of course, and Python. So one of the other neat things about it is the other one, I'm not sure about the older ones, but they were programmable, of course with windows or mac but this one also has uh is going to have the

ability to program it via an android or ios tablet or smartphone and even some fire os so like the amazon kindles some of them might be able to be used, which is pretty awesome because even though this robot inventor is pretty expensive, if a school's helping to support it or something and a kid has a $50 tablet at home, hopefully that'll work. So that's neat. Yeah, this is really cool. And I think being able to program with a real programming language instead of a blocky type of programming language goes a long ways. I think people underestimate how much kids can do with some simple text versus, you know, like, well, it's got to be drag and droppy, so don't ever make syntax errors. And, you know, if you look at things like CodeCombat.com, kids go through these dungeons and they solve, like, challenges to open the door, make it across the bridge or whatever

with code, but it's all typing python but the editor is so insanely aggressive in a good way aggressive with autocomplete like if you type a it'll try to autocomplete hero dot attack and suggest arguments i mean it's like ridiculous and in those sorts of scenarios, I feel like, you know, don't pull the punches, like give the kids a real experience. They'll adapt pretty quickly. I think people underestimate with the right tooling, what kids can do with a text language like Python. Yeah. And I, so I really hope, I think so too. And so it's exciting to have it. I know you can't, there were ways to put control the EV3 with Python, but it was extra hacky ways and not obvious for people.

And so hopefully having this supported. And I really hope that we get more of these sorts of robot inventor things coming out from Lego. Not every seven years. Could we update maybe every couple of years? That would be awesome. Yeah, for sure. Technology changes fast.

Yeah, and on a related note, I didn't do this as a full story, but I wanted to note, I also saw a project called Microscopy or Microscope Pi, maybe. It's an IBM open source project to build your own modular microscope using Raspberry Pis and Lego bricks and a little bit of 3D printing. And you can control it like a motorized microscope, which is pretty awesome. So that's neat, too. Yeah, that's really cool.

All right. Well, I have a theme that will become clear as I go through my items this week. I first somehow somehow just landed lined up with all the items I picked in the same general area. So I want to start off by talking about this article from kevin markham from data school.io and he put together he's been putting together lots of cool steps and guides to help people get into stuff his area is mostly data science but obviously on the python side so he created this thing called a step-by-step guide to contributing to github nice yeah so if you're new and you haven't actually yet contributed to an open source project,

it's like, here are the 17 steps in order. And some of them are obvious, like you have to have a GitHub account. You have to fork the project. Others are not as obvious. Like I always, whenever I fork something and I'm like, oh, you know, I really want to get the changes from the thing I forked merged, you know, sort of synchronized my fork with the remote fork. I'm always like, what is that command again about like remote origins and for upstream, I got to set, you know, and I'm like, so having that stuff all laid out in a nice little,

do this, then this, then this guide is helpful even just for a couple of those steps if you've done it before. So I'll just run you through the steps really quick. People can go and see the pictures and the graphics and the explanation. So I want to contribute to something. I think he contributed something back to Scikit-learn, but it could be any project, right? So you start by figuring out what project you want to contribute to. You fork it to your GitHub account, and then you check it out.

You clone it locally and load it up, make some changes, and then you make sure you have your origin remote pointed back to the thing on github and then the part i was just talking about you can add an upstream remote which allows you to say give me the changes from the source repository to my forked version you always want to get those like maybe you forked it a while ago but now you want to make a change so you want to grab the changes from the upstream the original repository repository and bring it over, create a new branch, a feature branch for your changes, because you're going to use that for a PR, make changes, commit your changes, push it to your fork, create a PR by clicking the green create PR button, review the PR, have conversations around it, maybe make some more commits to your pull request. So it talks about like, if you submit a

PR and they're like, that's great, but you you need unit tests how could you forget the unit test please add those as well how to do that right it's common story i'm sure discuss it and then once it's merged or i guess closed even you could delete the branch but especially if it's merged you don't need it anymore so delete your branch synchronize again your fork with the original project repository through the upstream link. Because once they've accepted your changes, your main branch will be out of sync with theirs. So you want to do that. And then also as a nice little tips for contributing code section as well with just some advice on how it goes. So the pictures and like here, type this for the step. I think this is pretty handy for a lot of folks yeah people just need to do it it seems overwhelming when you start because it seems like

oh my gosh this seems like so over the top and actually so at work when we switched from a different version control system to to get we started out with this sort of a model this is not an uncommon model even within not just open source, but other projects. Originally, I thought this is a lot of overkill. We don't really need forks and branches, but there's a lot of benefits to doing both. And you just kind of get used to it. And it's not, it ends up being not that big of a deal. Yeah. One of the advantages for what you're talking about, like inside your company, obviously it's important for open source, probably mostly because you don't have commit rights. So you make changes to your thing and

you say, accept my changes. Right. But inside a company, everyone has commit rights for the most part to their project they're working on. But it bundles it up in documents. Like these are the changes to add this feature. These are the conversations around it. And here's how it got accepted. Right. It's like a nice way to go beyond just like, here's a commit or a series of commits I did this week. I think some of them have to do with this scrum thing I said I would do. Yeah. Then one of the main reasons we kept the fork model in place is so that we can, if somebody accidentally pushes up a large executable or something that they shouldn't have committed in the first place, it's easier to kill a fork off than a branch of a project.

I see. It's like a layer of insulation of mistakes. Yep. Yep. Definitely. Yeah. Cool. Well, before we get on to a new language, Python inspired language, I just wanted to talk about a couple of things you can do to support the show. Obviously, Brian and I are both doing things outside the podcast that we think contribute back to the community that if you want to support what we're doing, it would be great if you could check them out and consider them as you're learning Python things. So I have courses over at TalkPython training. We have, I think, 170 hours of Python courses and probably a couple hundred hours of exercises for people to do over there. So if you're looking for courses or to learn stuff with Python in general, check out Hawk Python Training.

And Brian, you have some kind of book, I think. Yeah, so I think that anybody that wants to learn how to test better should pick up a copy of Python Testing with PyTest. So the book that I wrote about PyTest, it's not just, it kind of walks through all the different sorts of things you can do with PyTest, but also around testing a packaged project. And I think a lot of these carry over, even like switching databases and stuff, these things carry over for all sorts of types of projects. And I've got a lot of great feedback, and I think it's a good thing for people to read. Yeah, awesome. It's a great book.

And both of those things are linked at the top of the show notes. So you all can just check it out in your podcast players. So I'm always fascinated with embedded Python and things like MicroPython and CircuitPython. And you've got something along these lines, right? Yes, I ran across this, a language called SNEK, or SNEK, I think, S-N-E-K.

So it's at sneklang.org, and it's a Python-inspired language for embedded devices. But my first reaction is probably going to be yours is also, don't we already have that? Don't we already have MicroPython? We already have two. I'm confused why we have two. Yes, and CircuitPython.

Well, actually, yeah, we've got lots. MicroPython and CircuitPython are the ones that we think about a lot. CircuitPython, of course, is focused around Adafruit, but also runs on lots of different other boards as well. But what about really small things? Even those, they run on these small chips, but there's smaller chips that you might want also. So if you only have a few kilobytes of flash and RAM and you still want to run something, can you run Python? And that's where SNK comes in. So it's, I mean, it really runs on small processors. Even one of the things that supports is the Lego EV3. So if you don't want to wait for the new robot inventor, you can run SNCC on your current EV3.

So that's neat. But the smallness, its goal is it's not Python. So most SNCC programs will run in Python, but not the other way around. You can't run most Python in it. So it's got a limited language, but part of that is an educational purpose. So a smaller language footprint, as Python's adding more and more new features,

it may be overwhelming for some people when they're just starting out. So having a smaller language is kind of a neat thing. But all of that learning can go towards your, if you're learning SNEC, you can transfer that to Python projects later. Right, it's easy to level up to Python because it's like going from C to C++. There's stuff to learn, but it'll kind of work. Yep, there's even a dedicated new board called the SNEC board that is available. It was through a crowdfunding process, but it runs both CircuitPython and SNEC.

So yeah, one more thing to be able to run little small chips with Python-like language. So this is neat. Yeah, it's really cool. And the very, very small devices, I think it's going to mean, you know, Python can appear in more places, right? On incredibly small IoT things and whatnot. Like even if you have larger though, I like the idea of people saying Python's just kind of a great syntax. If we strip some of the things out that full Python has, it's still a usable language with a lot of it stripped out. So I think it's a good thing. Well, that whole idea, we could go on and on about that.

But the whole idea is pretty interesting because as we see things like Python moving to web assembly and running on the front end and talking about maybe having a Python on mobile, as well as the traditional CPython that we know and Python on chips, like having this concept of a smaller focused subset of Python that is universal. That's pretty interesting anyway. And it sounds like that's a little bit of the philosophy here. Yeah. It is interesting. What other things we see like this coming up in the future? That's right. So we spoke about Git before and forks and using forks as insulation. But have you ever made a mistake with Git? Like every day?

Yeah. Yeah. You're like, why did that thing get checked in? I told it to ignore it and now it's in there, right? Stuff like that so andrew simon sent over a link and recommended a zine a little small book a zine yeah zine by julia evans she has a bunch in uh the programming and devops space and she created one called oh shit get and it's like i'm learning get and oh my gosh something's gone wrong what have i done it's cool right this is great yeah so i want to be clear

this is a paid thing it costs ten dollars we have no affiliation with it but i just like the idea of it so i thought i would feature it so basically it's this really short little zine book thing that explains get fundamentals, like what's a Shaw and why don't you call it an SHA? I don't know. Stuff like that. Right. And then it goes into a bunch of how do I fix common mistakes? Like I committed to the wrong branch and other fundamental problems, or I have a merge conflict. Or I committed the wrong file. Or I ignored a file. And going back in time, we wrote the wrong code. The server is down.

Everyone is yelling at me. I know it worked yesterday. How do I get the server or something to go back and say, just go back to the way it was and we'll deal with it in a minute when things calm down. So all those kinds of stuff. So I thought this was kind of a cool one. And people who are like getting started with Git, but they're, you know, they run into these things and it's a big deal.

It's like, oh no, it's a merge conflict. Now what? I'm stuck, right? Or like I said, committed the wrong file or to the wrong branch or whatnot. I think this would be pretty helpful for folks. I love that the titles of the different sections are the thing that went wrong. Like, I committed to the wrong branch. Exactly. Yeah, I tried to run a diff and nothing happened. I've emerged conflict.

I want to split my commit into two commits. I want to undo something five commits ago, and so on. I got to make sure that this isn't a violation of my human resources things to buy this for all of my employees, because I think everybody needs this. These things are great. Yeah, just put a little bit of black electrical tape on top of that middle word, and then you can hand it out. It's a PDF. Maybe I, you know, get, buy five licenses and print it five times. Yeah, no, it's pretty good. It's like, I did something terribly wrong. Does Git have a time machine? Yeah, so it five times. Yeah, no, it's pretty good. It's like, I did something terribly wrong.

Does Git have a time machine? Yeah, so it sounds interesting. Thanks, Andrew, for recommending it. And Julia, cool work on the creative way to address Git issues. Yeah, definitely. So what's the story with versioning? You guys got a beef with it?

Well, you know, I've kind of always had a beef with it, but I didn't really think about it so brett cannon actually asked a question on uh uh it was interesting he wrote an article that i read recently called uh why i don't like semver anymore semver being semantic versioning that's the 2.1.0 style yeah And like, as opposed to calendar versioning or what we were, we talked about this earlier of zero-ver. Zero-ver is like an even more negative version

of semi-ver, sim-ver. Yeah. So the interesting question is, it's not straightforward as to what, so there's often it's like the first digit, like if we say x.y.z, x is some major thing. So like some crazy new feature, it's either the first digit, like if we say x.y.z, x is some major thing.

So like some crazy new feature. It's either a crazy new feature or it's an incompatibility with the old one. Like we're going to change the interface. Right. When Django went from 1.something to 2.0, they dropped support for Python 2, for example. And that was indicated partly there. Yeah, exactly. So what constitutes an interface break?

And that's what a lot of people think about. Well, what about if you add a deprecation warning to something that you're planning on taking out in the next version? Is that adding an extra warning? Is that a major thing or a bug fix or a minor thing and that's part of the discussion of most of us i think would think that maybe that's a either that's just a bug fix or a minor thing that's not a major thing right and to me it makes it makes like no different there's no new functionality nothing stopped working that seems like a super minor like it should change the very last number because it doesn't even add or change a functionality but it is adding a warning so if i have come if i'm i'm running python with with the flag that turns all warnings into errors or if i'm running my tests such that and that's like normal with running tests as you turn all your warnings into failures so that you find them now Now you've, you really did change the interface because I, to get rid of that warning, I have to go and either I need to change to not, I need to not

look at that warning or I need to change my use of that thing. So it is kind of an interface break. Yeah, for sure. So that's part of his discussion is that it's not really straightforward to say that what is a major, minor or micro change, what that really is. It's not really straightforward to say that what is a major, minor, or micro change, what that really is. It's a gray area. There's discussion. And then also really what the observation that the three digits kind of makes sense

if you are maintaining three or more branches. So if you're maintaining a current branch plus the features you're working on the next one, that's another branch, plus you're doing bug fixes to the current production one. So you've got development going on in one branch and fixes in the other one, and then minor things going on. You might have even more branches that you're maintaining at once. For a large project with lots of people on it, that totally makes sense. For small projects and side projects and things where you're really, you're not maintaining a bunch of stuff,

it's one branch and you fix bugs, you're not planning on adding new features, or if you are, you know, I don't know, it's so infrequent that it doesn't matter, maybe two digits is enough, just x.y, or maybe just one digit, because there's a whole, one of the reasons why a whole bunch of people are at zerofer is they're trying to not be backwards

incompatible and they're not going to add any major new features. It's a simple tool or something. The other thing Brett brings up is basically you shouldn't depend on this stuff because it's nebulous and wishy-washy. You shouldn't depend on the numbering semantic versioning to see whether or not what versions of a new of a dependent project you're using. You should rely on continuous integration and testing. So do a minimum version for the project you're using, but don't do a max and use your testing to find out if there's any problems. Always do the latest one in the diversion. Doesn't really matter. You're going to keep ahead. And if your CI breaks,

then you might have to pin your dependency to earlier one, but also you should always pin your dependencies to specific versions and just use your CI and testing system to see if you can move forward. Yeah, absolutely. And if you use something like depend aabot or PyUp or something like that, it'll automatically look at your repository, increment those versions, run some CI if you have it set up, and you'll know if it's acceptable or not.

So you can get the system to tell you, hey, you should update this pinned version and click here to allow it. Yeah, I love systems like that. And it totally makes it so you can review it and go, yeah, that's good. Often those just show up as a merge request that you just accept, right? That's right. Yeah, very nice.

Yeah, so good discussion about thinking about whether semantic versioning really is appropriate for your project. Yeah, so do you remember what the recommendation was? I scanned it and I didn't see like a super clear, like do instead. No, the end there's a kind of a summary that I kind of like cribbed and put in our show notes. Essentially it's the try to pin the lowest version or pin your versions of course but have a low end but don't have an upper end and just test. As for using dependencies for your own version

it really was it should match your branching strategy really so if you're really not supporting three branches three digit semantic versioning doesn't make sense you can do two digit or one digit versioning yeah yeah pretty cool all right carrying on with my theme, you want to talk about Git? Oh, we haven't covered Git for a while, so that'd be good. Yeah, for sure. So there's famous, like, you know, rock star famous, Julia Roberts, movie star famous. There's like maybe a step down, but still pretty cool. There's geek famous, right? Like on the regular street, nobody would recognize you, but at a conference, you're kind of cool. I think probablyido van rossum definitely fits geek famous right yeah and then apparently there's a get famous oh is that is that when you have like your pixelated

face as your get history it's really complicated but if you time it just right you can yeah no so there's this project bjorn olsen sent this over so hey you should check this out it's it's quick and fun and kind of useful. If you want to go to a project and answer the question, who kind of created this or who mostly worked on this? And I have this all the time when I go look at these projects that we're researching and covering. Maybe I want to talk to the person about a question or something.

I'm like, all right, well, if I can go to the contribution thing in GitHub, maybe it'll show me. But that's more of an over time and who's recently worked on it and stuff. So it's not super good. And if you're not on GitHub, then obviously it doesn't help. So there's this thing called get fame, which is a Python library. And the idea is you pip install get fame and then associate it with get, you have a new command, you say get space fame, and it will go through and it'll like look at all the commits and all the people and how many lines of code were changes changed and files and

whatnot by everyone and then it'll give you a ranking of these are all the people who contributed and here's how many files they've changed how many lines of code they've changed and so on it's pretty cool and it sorts them by most popular, most largest contribution downward. That's cool. Yeah, and it's super easy. It's super easy. Like, pip install, git fame, git config, and set an alias to fame to run the Python command, and then you just type git fame,

and it just goes, and it uses the tqdm, I think that might be the right order, progress bar, you know, to show you its progress. I ran it on a somewhat large project, small to medium project, I guess, in terms of regular software. And it found 596 commits and it took seven seconds to do that. It processed 76 files a second. That's pretty good.

Yeah, I totally like the idea. Especially, Rhonda, very useful for us when we want to talk to one of the people that's really involved with it yeah exactly yeah and like you said often some of the most recent ones are valued of course but not major changes to the library or something right exactly so it's a little bit hard to know so this kind of gives you the historical view of who's really contributed to this project and how many lines of code have they changed and so on which is not always a great measure, but it's still interesting.

Yeah, I totally missed my guess. My guess was it was an alias to rewrite get blame because blame is so... I don't know why they named it that. I know. Credit? Maybe get credit. It should be called credit.

There's positive and negative credit, right? Yeah. Yeah, so it basically runs get blame over and over and over on each file and then analyzes the file, the result of get blame, and then builds out this history based on that. That's pretty cool. Neat. Yeah, pretty cool.

Super easy to use if you're into it. And that wraps up all of our items, Brian. Got any extras you want to share with folks? I wanted to thank everybody that's supporting the show through Patreon because I went and took a peek today and we have 26 supporters and if you want to, we have links in the show notes

and also links on our site if you want to help out the show through Patreon, but you can also go to patreon.com slash pythonbytes and many people donate a dollar a month and that is awesome. Thank you. And a few go above and beyond and contribute a little bit more.

So I wanted to do a special shout out to those that are contributing more than a buck. So thank you, Brent Kintzer, Brian Cochran, Bert Raymakers, Richard Stonehouse, and Jeff Kiefer, all donating more than a dollar. So thank you very much. Awesome. Yeah. Thank you guys. That really does help support cover things like editing and transcripts and all that kind of stuff.

Now, I have a quick follow up for last time we spoke about DunderPy packages and things like that to where you could set up, I think it was PyFlow we were speaking of, where if you interact with Python through PyFlow, has a little Python example, just a single Python file that you can use to basically implement this. And it says this would probably be really great for like trainers and students and teachers and stuff like that to kind of sidestep the whole virtual environment story. Okay, that's cool. I got to try this out. Yeah, so a quick little link to a working version that's not just a whole overhaul like PyFlow, but a simpler thing. All right, now this last one, Brian, this joke here,

I'm going to wrap it up with a joke as always. You've got to open it up because it's an animated GIF. Okay. First, let me ask you, what shell do you use on your Mac? Bash, okay. So I'm an oh my Z shell kind of guy because I love like the history and it keeps a really good track of all the stuff I've done.

And sometimes I'll type like one or two letters and I'll try to go back and I'll be like, no, no, that's not. Instead of just typing out the stupid thing, I'll just go back and back. And so here's like this clear, like super bearded guy who's some kind of sysadmin Linux exaggerated person,

I guess you would say. And it's an animated GIF, right? The guy's just clicking his finger, clicking his finger, up, up, up, up, up, up, up. Shows him doing that, doing it some more. Now he's got a drink. He's clicking on, he's drinking his drink, clicking up. And then finally, he's so excited.

He's like, oh, finally. What does he say? I knew I had that LS somewhere in my history. And eventually he just says, yeah, LS, right? He's up arrowed until like forever to just, so he didn't have to type LS. Oh, man. Have you ever been there? No, because I, what kind of key binding?

Do you use VI key bindings? No. Okay. Do you like a backward search or something like that? Yeah, you can just search through your history to find him. But then you have to press more than just the up arrow anyway people this has got a cool uh a cool little animation cartoon thing so i just linked over to comicstrip.com where where the title is definitely not lazy yeah definitely you know i was thinking about it i

don't even remember the key sequence to do the searching i would have to do it i just it's one of those built-in muscle memory things now so that's the searching i would have to do it i just it's one of those built-in muscle memory things now so that's right yeah i was trying to remember it today and i couldn't remember it i'm like oh whatever up arrow up arrow up arrow so yeah pretty funny all right well thanks for bringing all these items and sharing with everyone great to chat with you as always thank you yeah 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.