Python Bytes - #384 Force push lightly

Episode Date: May 21, 2024

Topics covered in this episode: Git: Force push safely with --force-with-lease and --force-if-includes Thoughts from PyCon 2024 Being friendly: Strategies for friendly fork management tach Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/384

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 384, recorded May 21st, 2024. I'm Michael Kennedy. And I'm Brian Ocken. This episode is sponsored by MailTrap. Better email sending APIs. Check them out at pythonbytes.fm.com. Tell you more about them later. And you can

connect with us over on Fostedon. We're all Mastodon in general, but we're all over on Fostedon. So find us there. And if you want to X, then you can connect to us over on X as well. Brian, I'm not going to call it Twitter anymore. Do you know why? Why?

When you go there, it now redirects Twitter to x instead of x to twitter oh really they've accepted they've accepted their fate they've accepted their fate so at least for the time being i said you can all i had a friend of mine like uh get mad at me for unfollowing him on twitter and i'm like i didn't it wasn't just you man i i don't follow anybody on twitter yeah don't take it personally. Yeah. So people can find us there as well. Although more conversations on Macedon and check out the live show. If you would like Pythonbytes.fm slash live, usually Tuesdays at 10 a.m. Pacific time. And if you want an

artisanal, handcrafted, specialized, personal summary of what we talked about on the show, just head on over to Pythonbytes.fm, click newsletter right in the middle of the hero section at the top and put your email address there. We won't share it. It's just so that we can talk to you about things that we're up to. So if that sounds awesome, do that. But Brian, we're not going to be forceful about that. We're not going to overdo it, are we we i'm going to start by talking about git force actually um adam johnson wrote a blog post about git this isn't specifically python related but i'm guessing a lot of you guys use git so or use i've seen a few people who do python

who use git also that's true so um one of the things that happens when you're using Git is you've got your local repo that's not quite in sync with the remote one. And if it's just you, and somehow when you push and it doesn't work right, you do a push force with a dash dash force, and it just says, no, I mean it, take it. That's not always what you want to do. So Adam Johnson wrote a post called Force Push Safely with Force with Lease and Force if Includes. Wow, these are verbose. I don't know what with lease or if includes means, but the gist of it is, is one of them will make sure that you have,

oh, let's just look at what he said. So if you try and sometimes you get an error message that said a note about fast forwards and failed push because the tip of your current branch is behind its remote counterpart. So you're the tip of your current branch is behind its remote counterpart. So you're not up to date. So and wait, before you ignore this, because you think, oh, I only use my own repos and I don't, I'm never going to be in conflict. I've finding this more and more with my own repositories and I'm the only one developing. Why is that? It's because I've got CI tools that

do things like update things for me. And if it passes, it goes through. And so therefore, my local branch is not up to date with my remote because there's stuff in CI doing things for me. That's a good thing, but it causes this problem sometimes. And what we want to do is to make sure that we pull or fetch all of the branches that we're going to be pushing to and make sure that our local changes are merged correctly. And if we don't do that, get push will fail. So this you can force it, but forcing will just overwrite your version with the one up there. It's not really what you want to do the the so one of these one of these flags will make sure that you have

at least fetched the the branching question so all and all the commits you that you fetched all of the commits that are involved so that it assumes that you've looked at them and then one of them make sure that you have actually uh you've actually checked it out so if you done you did a get checkout and actually, so that, and that would mean, that would, I guess, assume that you have looked at, actually looked at it, not just that it's on your computer,

because fetch will pull everything down, so it's on your computer, but committing or checking it out will mean that you've actually had it in there and you had at least the opportunity to look at it. So I'm definitely going to, and there was some comments to this blog post saying that I usually have a, a shortcut assigned to this. And I'm not sure what the normal shortcut is for this,

but I'm definitely going to set this up to me, see if I can get this to happen automatically or something. Yeah, this is interesting. It's new to me as well. And I'm certainly going to check it out. So anyway, some get safety concerns. So speaking of safety, how was your flight? Was your flight safe back from PyCon? My flight, my flight was great. Actually worked out pretty good. All the flights were full. So it was like rubbing shoulders with strangers. I even got the bonus of being in the middle seat one time. That was amazing.

That was the flight that was delayed for an hour and a half and waited on the tarmac instead of the terminal. So I got an extra time there with people, but yeah, no, it was great. And yeah, let's, let's talk a little bit about PyCon. So PyCon, PyCon was awesome. You know, there's a ton of people that I got to see again, and that was really special. A bunch of people I met, and that was also amazing. Just, I just spent my time going around, networking, learning what folks are up to, both through the expo floor and just from talking to others.

And, you know, I say this all the time, but to me, it's basically my geek holiday. So we missed you though, Brian. We missed you this year. I missed you guys. Yeah. A bunch of people asked about you, by the way. They're like, hey, too bad he's not here.

All right. Well, I did do a live TalkBython episode with Jody Birchall and some other data science ladies there at the JetBrains booth. So thanks to them for all the AV setup. And I'll post that in a couple of weeks. And also the talksBrains booth. So thanks to them for all the AV setup and I'll post that in a couple of weeks. And also the talks look really good. I'm not always inspired by the PyCon talks and some of the Python more regional conference talks,

but this year they looked quite good. So I'm really looking forward to the YouTube version of them coming out whenever that happens. I think last year was like three months or something. Pretty quick. No, I'm just kidding. But eventually whenever they do come out, they'll be really good. So we'll talk more about that here when they land, right? Yeah. All right. Let's wrap this up with a rant, though. I highly recommend

people go. If you've never gone and you think that you might, you should definitely go. If you're thinking that I'm not good enough at Python to go, you should definitely go. You'll make connections. You'll get better at Python. People are super welcoming. But do you know what was not welcome? The stupid mask policy, Brian. It was universally disliked. And I'm sure there's one person out of several thousand that are like, Michael, the only reason I would come because of this.

Yes, I know. But I'll tell you, I spoke to tons of people, spoke to vendors. Everyone was there complaining about the mask. We go outside and just take this thing off for a minute so we can talk? Or I lost my voice after the first day. And so I had to do the podcast because it would be like, what? You know, like it was just a loud, everybody had masks on and it was like loud din because everyone was trying to yell through them.

I don't know. It was just tremendous mistake. I had the only reason I bring this up not rant, because I've already done this rant. Hopefully, people listening for next year, people interested in going next year, speak to people in charge and say, okay, the world is not like that anymore. Can we please just have a more coherent policy? Anyway, that's what my hope is. We could do somewhere in the middle.

Like if you feel like you might have a cough or something, please try to keep your mask on. But yeah, like, yeah, a hundred percent. Well, I mean, I said this before and just for people who didn't catch it, I'm not anti-mask, not anti-science, whatever. I, I, when I went on a trip recently, long trip, I, maybe I was getting sick. I wore my mask the whole time, even though like no one around me did, like a super long flight and the airport and everything, because I wanted to be considered. And I don't care if other people, if other people want to wear a mask, that's great. But like, don't force this weird policy onto everybody who generally doesn't think that they'd rather.

It undermines the networking aspect, both for the sponsors and Expo trying to talk to people and each other. All right, rant over, but please, here's fingers crossed for next year. And if you're out there and you agree with me, please let the folks know. And you don't have to email me. I've already had this conversation a lot, but it's just closing the loop in the

past. I feel like what I said before is, you know, pretty, pretty much was how it was. You know what though is quite awesome. Brian hinted at the top of the show. Not that that's later mail trap. Let's talk about mail trap real quick. Okay. This episode is sponsored by mail trap and email delivery platform that developers love, an email sending solution with industry-best analytics, SNTP, and email API, as well as SDKs for major programming languages

and 24-7 human support. Try for free at MailTrap.io. Indeed. Thank you, MailTrap. All right, over to you, Brian. What you got? I'm going to talk about Git some more, actually. Let's get it on. So I'm thinking about forking a project because you remember how projects used to have fork me on GitHub, little things on the top corner. They don't really do that anymore. But we often think of, I mean, actually, I often think of contributing to an open source project

just in the sense of forking it just so that I can make modifications to contribute back to the project. That's often how we create a fork, create a branch on your own fork, and then you contribute back to the project. That's how we do contributions. But what if you want to have a long running fork of a project? And that's what I'm considering. And I was thinking about strategies, how to do that, because I don't know. And so I ran across this a couple of blog posts from the get folks. It's actually from Leslie Dennington.

Cool. There's a couple of posts called being friendly. So there's being friendly, friendly forks one on one. And there's being friendly strategies for friendly fork management. And I think these are interesting because there's, there's a lot of stuff going on here and there's, but not really. We'll go through them relatively quickly. They picked some examples to think about.

And I was thinking I would really like to know, like, from an example project. And Git itself is a lovely example project because Git has several forks and they have different policies. So there's Git slash Git, which is the main. Wait, there's Git for Windows, for instance. So there's Git, Git, the base one. There's Git for Windows, for instance. So there's Git-Git, the base one. There's Git for Windows-Git. There's Microsoft-Git. And there's GitHub-Git.

So there's four different friendly forks off of that. Actually, it's actually not like that. There's the main Git-Git. And then there's Git for Windows that's based off of that. And then there's Microsoft-Git, which is a fork of the Git for Windows. And then there's GitHub Git, which is a separate branch fork. Anyway, three forks on it, and they have different policies. And it's interesting to look at them.

And then so if you talk about, look about the different needs. So the first article talks about the different needs for the forks. And then the second article talks about merging strategy. That's really where I wanted to understand it because here's the idea. I'm going to fork a project and then I want to, um, I want to regularly get updates from the, the parent project because I want to like, maybe, and this happens like for internal companies a lot. If I'm, if I want to add on, add on extra features that are not there, they like, maybe I tried to contribute them and they got rejected, but I, I still need them so I can have a friendly fork,

but I want to keep up to date with all the changes. So how do you keep up to date? So one of the ways is, is from a, you take a, what they call a merging rebase, which is what Git for Windows does. And the, I guess I'm not going to try to find all the diagrams, but there's diagrams in here too. But there's a merging rebase is where you take, you kind of do like a fake merge, where you say I'm going to merge,

but I'm actually only going to take my changes. And then you, so that isolates just your changes. And then you rebase so that you can just take the new space on the upstream one and then just apply all of your changes to it. It's a way to just do that. The second way is a new branch and uh and that that'll allow you to just take um like the the microsoft get one does a new branch so for each upstream new version you just uh create a new branch for that like go complete completely do a new branch and then uh then you copy over your changes from from past changes onto the new changes.

So you start the branch over again every time, almost. And then the third one is just a traditional merge. Like Git get uses a traditional merge. But there's a lot of noise in that. And so they say that that works okay. Takes a lot of people and a lot of testing, though. And they often delay. So let's say I picked, I don't know,

any, any project and for a major release, I'd maybe wait till like, wait a couple months or something or wait, whatever the dot releases to make sure the, the, a couple of the bug fixes releases after the new features came out and then merge then. So, and then at the end, which is great. I know this is a lot of detail but the great articles um oh there's a there's a cool picture of the um the uh creating a new branch completely new branch and then merging your changes over so there are some great pictures in here so the um and then the they also talked about like proactive versus cautious like how frequently you're going to merge and this is just a really good discussion of this is a lot of work how frequently you're going to merge. And this is just a really

good discussion of this is a lot of work, guys, if you're really gonna like maintain a fork of a project, you just just take it slow, make sure you know what you're doing and know how many people you are there. So it talks about the different scenarios, and when when you might or might want not want to use different versions. and i think uh like the the final one says if you're new to the fork game and want to keep it simple um just do uh just do merges and do it uh be considerate maybe that's that might be the easiest and i think i think i might go with this one to start with because but i i am intrigued by the whole like the the merging rebase thing that sounds neat too actually they all sound cool i might try all

of them just to see how it goes but it's just me so that's uh i might be crazy but i i breathe bring this up because i'm uh one because other people might be considering like forking something for their own company use or or just wanting to possibly start a sister project for something um have it be slightly different um How do you go about that? So these are great articles. But also, if I'm missing something, if this is not a great reference for this and the other people have other tools around, let me know.

By the way, the whole forking rebase thing, there was a script involved here. So they shared the script that they used for doing this and then talked about some cool merging uh like uh diffs and there's a diff merge tool that they used for code reviews and stuff so anyway yeah very cool this is uh some advanced git stuff right here but you can easily get yourself in trouble if you fork a repo and even if you intend to make changes back and you change the branch that is being updated

on the remote or the original repository, you can end up with merge conflicts. It almost always seems like a good idea to have kind of a separate branch where you work and something that syncs with the project, right? And so that's kind of like that. Plus, then what do you do to like kind of keep it in sync because you're definitely going to end up with conflicts if your intention is not

to keep it in sync by pushing your changes back to it right yeah the other thing that i want to point out that wasn't in this article is tags are completely separate um i know that tags are part of the git repository but they don't come automatically. So, and that's often, I don't know the reason. It's convenient that they don't come. It's both convenient and painful because the new project will have its own versioning scheme possibly.

But if you want the same versioning scheme, you have to do that separately. You need to make sure that you're pulling the tags as well. So, yeah. A lot to consider. Yeah. All right. let's talk about tack not a super popular project yet but um pretty awesome let's see it's about a month old i would say no four months old is how old it is so this is a project that lets you understand the architecture and actually not just understand, let you specify the architecture of your application and enforce it through a linting sort of thing. Okay.

So let's see what they say here. Python tool to enforce modular design. So maybe the best way Brian would be to like, look at this little thing as people are watching, you can see there's a little video demo, which is great. So what it will do is it will show you, you set up some config files and you say, I have these parts of my application, right?

These modules or these packages. And I want to control how they interact with each other. So if I say this stuff makes up a data layer here and this stuff makes up an API layer here, and this stuff makes up an API layer, you might say that the API layer and the data layer are not allowed to talk to each other. Only stuff that consumes either of them can coordinate across them, right? So for example, something in the API section shouldn't import something from the data section and vice versa. You want them to be independent so that potentially, you know, they're easier to test,

they're easier to change. You know, if I i change this part it's only going to affect you know the thing itself and the stuff that i explicitly understand to be using it and it doesn't like become sort of a spider web of everything's connected to everything as much as it can in python because you know circular dependencies are an issue right but, that's kind of the idea, okay? Okay. So you just install it and you have to like add a package and it'll let you like take through and specify that or you can just come up with a YAML file, a package.yaml, and then you give it a tag like this one is a core and this one is a DB and this one is utils.

And then at the root, you come up with a tag.yaml that says the core depends upon DB is utils. And then at the root, you come up with a tack.eml that says the core depends upon DB and utils. So the core can import from DB and utils, but not vice versa. The DB depends on utils and utils shouldn't be importing from other places in your application. And then you can run it,

a CLI tool against your app, like tack check. And it tells you that there's some import that's breaking the rules that you've laid out. So the other thing, yeah, go go ahead the other thing that's interesting is it allows you to define a public api you can say these things i would like you to be able to use when you use my package but this other stuff is internal stuff and i make zero promises about it so please don't use it i know you could because of python but don't and it'll uh it'll enforce that as well it'll say like you're trying to use something that i'm explicitly trying to say don't use it. I know you could because of Python, but don't. And it'll enforce that as well. It'll say like you're trying to use something

that I'm explicitly trying to say don't use. So I don't think this is useful for every app, but if you've got different people working on it and you want to be real careful about your architecture, you know, it's worth checking out. I think this is, I am going to check this out. It's not just like, you know, bad architecture or something. Just you might uh

bring some new people onto a team or it might it might help um uh people get used to a project uh and the rules around it easier if you weren't if you aren't allowed to do stuff yeah that's a pretty good point so how does it stop it does it does it oh it just it just prints a warning it just prints a warning it's like a like. It's like a linter would fail. So it's like a linter error. But I mean, it doesn't actually, there's no runtime checks. So no runtime checks.

Okay. Yeah. All right, cool. Yeah, but you can set it as a pre-commit hook, in which case I guess you couldn't commit if you wanted. But yeah, I kind of like the idea of the public API. I know it looks like you should use that,

but there's actually this other thing that does more checks and brings in some other stuff and adds versioning and you should use that function to make this change don't like directly i don't know whatever interact with something right yeah cool all right extra time what do you got uh i got i guess one extra um i noticed that the uh the pedantic guys or pedantic people, I should say have, um, have something, something they're trying to sell now. Um, so, uh, being a company, you have to make some money somehow, which is good, but, uh, they, they came up with a tool called log fire and, uh, it just looks fun. Um, so it's on advertised as uncomplicated observability from the team behind Pedantic.

They have an observability platform to look at logging and other things. And actually, I haven't dug into it too much, but it looks pretty slick. Anyway, right now, the pricing model is free for everybody, but they're going to eventually charge people. You could know how much they're going to charge you if you had... That's it. Yeah, you'd know how much they're going to charge you

if you had some of that cool, fake, futuristic image capabilities. Zoom, enhance. Zoom, enhance. Because they have the blurry pricing. Yeah. Well, the website's beautiful, too. Oh, it's $9.99.

I don't know what it is. Yeah, it does look good. Do you have any extras? Well, just a quick comment on this. What I think is interesting about LogFire, and again, congrats to Samuel and team over there. I saw those folks at PyCon as well. There's a lot of observability platforms

that you can add to different Python stacks and other stacks as well. But what's kind of interesting about this is it's super focused on specific frameworks to add more observability than normal to them, I guess. So for example, you'd say logfire.instrument psychopg or logfire.instrument fast API, and it gets like really deep understanding of what that thing is doing and gives you reports around it rather than just I saw a web request or I saw you talk to a file or an API or something you know yeah yeah I do have a couple of extras let's see the getting started with an LP and spaCy course by Vincent vommer Dom he is he and I decided we're going to do a 10% on the course for the month of May,

10% off. So if you would like to take this course and save a little bit, you've got nine, 10 days to do so. If you listen to this right away, right? Basically during May, 2024, you can save 10%. So, uh, put the link in the show notes, check out getting started with NLP and Spacey. Super cool. Super cool one. And I feel like I might've had another, I'm going to go with no, that's my only,

only my, my only extra. Okay. And I saw we both put a joke in, but let's, let's do your joke next week. I'll do this joke this week. Okay.

Okay. So, uh, so do my joke next. Yeah. All right. So I was actually, um, listening to a book, uh, called company of one from, uh, Paul Jarvis. Excellent book.

I'm actually listening to it the second time now. I'm really enjoying it. Um, anyway, he talked about one of the, one of the people he talked about was, uh, somebody that runs, uh, actually Tom Fishburne runs a company called market tunist. And here's a, uh, cartoon from, runs a company called Marketoonist. And here's a cartoon from Marketoonist that I actually really love. It's the evolution... One sec.

I don't see your screen anymore. You don't see it? No. Okay. You just have to tell it to us. Most people listen anyway. Okay. Evolution of smart products.

If I were to buy a toaster, first there's the toaster. It makes toasts. Then you've got wifi enabled, makes toast after making you wait for a firmware update. Data-driven toaster makes toast by watching how you like toast. So it watches you. Toast as a service makes toast for $5.99 a month. Ad-supported toaster makes toast and lets you know that Smuckers is on sale. And then there's the AI toaster toast. I lets you know that smuckers is on sale and then there's the ai toaster toast i'm afraid i can't do that dave i'm afraid i can't do that dave oh you do it

good how let me in goodbye dave goodbye dave i love it i love it yeah that's a really good one anyway um the uh market is uh i'm not really it's uh he's got a great company there's a really good one. Anyway, the market is, I'm not really, he's got a great company. There's a couple other ones. One of them I really related to. Anyway, there's a lot of thoughts I related to and enjoyed his stuff. Awesome. Yeah, very funny one.

Good stuff over there. So nice find. All right. Well, I think that is it for the week brian thank you thank you thank you yeah thanks everyone for listening see y'all later bye