Transcript #384: Force push lightly

00:00 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.

00:06 This is episode 384, recorded May 21st, 2024.

00:14 I'm Michael Kennedy.

00:15 And I'm Brian Okken.

00:16 This episode is sponsored by Mailtrap.

00:21 Check them out at pythonbytes.fm/mailtrap.

00:23 Tell you more about them later.

00:25 And you can connect with us over on Fosstodon.

00:29 We're all Mastodon in general, but we're all over on Fosstodon.

00:32 So find us there.

00:33 And if you want to X, then you can connect to us over on X as well.

00:38 Brian, I'm not going to call it Twitter anymore.

00:40 Do you know why?

00:41 Why?

00:42 When you go there, it now redirects Twitter to X instead of X to Twitter.

00:46 Oh, really?

00:47 Seems like they've accepted their fate.

00:49 They've accepted their fate.

00:50 So at least for the time being, you can all--

00:53 I just had a friend of mine, like, get mad at me for unfollowing him on Twitter.

00:58 And I'm like, it wasn't just you, man.

01:01 I don't follow anybody on Twitter.

01:03 Don't take it personally.

01:05 Yeah, so people can find us there as well, although more conversations on Mastodon.

01:09 And check out the live show.

01:11 If you would like, pythonbytes.fm/live, usually Tuesdays at 10 a.m. Pacific time.

01:16 And if you want an artisanal, handcrafted, specialized, personal summary of what we talked about on the show,

01:23 just head on over to pythonbytes.fm, click newsletter right in the middle of the hero section at the top,

01:29 and put your email address there.

01:31 We won't share it.

01:32 It's just so that we can talk to you about things that we're up to.

01:35 So if that sounds awesome, do that.

01:37 But, Brian, we're not going to be forceful about that.

01:41 We're not going to overdo it, are we?

01:44 I'm going to start by talking about Gitforce, actually.

01:47 Adam Johnson wrote a blog post about Git.

01:51 This isn't specifically Python related, but I'm guessing a lot of you guys use Git.

01:56 I've seen a few people who do Python who use Git also.

02:00 That's true.

02:01 So one of the things that happens is when you're using Git, you've got your local repo that's not quite in sync with the remote one.

02:12 And if it's just you, and it somehow, when you push and it doesn't work right,

02:16 you do a push force with a --force.

02:19 And it just says, no, I mean it, take it.

02:23 That's not always what you want to do.

02:25 So Adam Johnson wrote a post called Force Push Safely with Force with Lease

02:32 and Force if Includes.

02:34 Wow, these are verbose.

02:35 I did not know about either of these things.

02:37 So I'm really glad that he wrote this up.

02:40 The idea is I don't know what that means.

02:44 I don't know what with lease or if includes means.

02:48 But the gist of it is, is one of them will make sure that you have --

02:53 let's just look at what he said.

02:55 So if you try and sometimes you get an error message that said, a note about fast forwards and failed push,

03:02 because the tip of your current branch is behind its remote counterpart.

03:07 So you're not up to date.

03:09 So -- and wait, before you ignore this because you think, oh, I only use my own repos and I'm never going to be in conflict.

03:17 I'm finding this more and more with my own repositories and I'm the only one developing.

03:22 Why is that?

03:23 It's because I've got CI tools that do things like update things for me.

03:28 And if it passes, it goes through.

03:32 And so therefore, my local branch is not up to date with my remote because there's stuff in CI doing things for me.

03:38 That's a good thing, but it causes this problem sometimes.

03:41 And what we want to do is to make sure that we pull or fetch all of the branches

03:46 that we were going to be pushing to and make sure that our local changes

03:49 are merged correctly.

03:50 And if we don't do that, get push will fail.

03:54 So this -- you can force it, but forcing will just overwrite your version

03:58 with the one up there.

03:59 It's not really what you want to do.

04:01 The -- so one of these flags will make sure that you have at least fetched

04:08 the branching question and all the commits, that you fetched all of the commits that are involved

04:14 so that it assumes that you've looked at them.

04:16 And then one of them makes sure that you have actually --

04:20 you've actually checked it out.

04:22 So if you did a get check out and actually -- so that -- and that would mean

04:26 that would, I guess, assume that you have looked at -- actually looked at it,

04:31 not just that it's on your computer.

04:33 Because fetch will pull everything down, so it's on your computer.

04:36 But committing -- or checking it out will mean that you've actually had it

04:40 in there and you had at least the opportunity to look at it.

04:44 So I'm definitely going to -- and there was some comments to this blog post

04:48 saying that I usually have a shortcut assigned to this, and I'm not sure what the normal shortcut is for this.

04:56 But I'm definitely going to set this up to see if I can get this to happen automatically or something.

05:01 Yeah, this is interesting.

05:03 It's new to me as well, and I'm certainly going to check it out.

05:06 So anyway, some get safety concerns.

05:11 So speaking of safety, how was your flight?

05:15 Was your flight safe back from PyCon?

05:17 My flight was great, actually.

05:19 It worked out pretty good.

05:21 All the flights were full, so it was like rubbing shoulders with strangers.

05:24 I even got the bonus of being in the middle seat one time.

05:28 That was amazing.

05:30 That was the flight that was delayed for an hour and a half and waited on the tarmac instead of the terminal,

05:34 so I got an extra time there with people.

05:36 But, yeah, no, it was great.

05:38 And, yeah, let's talk a little bit about PyCon.

05:40 So PyCon was awesome.

05:43 There was a ton of people that I got to see again, and that was really special.

05:47 A bunch of people I met, and that was also amazing.

05:51 I just spent my time going around, networking, learning what folks were up to, both through the expo floor

05:57 and just from talking to others.

06:00 I say this all the time, but to me it's basically my geek holiday.

06:05 We missed you, though, Brian.

06:07 We missed you this year.

06:09 I missed you guys.

06:11 Yeah, a bunch of people asked about you, by the way.

06:13 They're like, "Hey, too bad he's not here." I did do a live TalkByThon episode with Jody Burchell

06:18 and some other data science ladies there at the JetBrains booth.

06:24 So thanks to them for all the AV setup, and I'll post that in a couple weeks.

06:28 The talks look really good.

06:30 I'm not always inspired by the PyCon talks and some of the Python more regional conference talks,

06:35 but this year they looked quite good.

06:37 So I'm really looking forward to the YouTube version of them coming out whenever that happens.

06:41 I think last year was like three months or something.

06:43 Pretty quick. No, just kidding.

06:45 But eventually, whenever they do come out, they'll be really good.

06:48 So we'll talk more about that here when they land, right?

06:51 Yeah.

06:52 All right, let's wrap this up with a rant.

06:54 I highly recommend people go.

06:56 If you're at PyCon and you think that you might, you should definitely go.

06:59 If you're thinking that I'm not good enough at Python to go, you should definitely go.

07:04 You'll make connections.

07:05 You'll get better at Python.

07:06 People are super welcoming.

07:07 But do you know what was not welcome?

07:09 The stupid mask policy, right?

07:11 It was universally disliked.

07:13 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."

07:18 Yes, I know.

07:19 But I'll tell you, I spoke to tons of people, spoke to vendors.

07:23 Everyone was there complaining about the masks.

07:25 They're like, "Can we go outside and just take this thing off for a minute

07:27 so we can talk?" Or I lost my voice after the first day and still had to do the podcast

07:31 because it would be like, "What?" It was just a loud – everybody had masks on and it was like loud din

07:40 because everyone was trying to yell through them.

07:41 I don't know.

07:42 It was just a tremendous mistake.

07:44 The only reason I bring this up, not to rant because I've already done this rant.

07:48 Hopefully, people listening for next year, people interested in going next year,

07:52 speak to people in charge and say, "Okay, the world is not like that anymore.

07:57 Can we please just have a more coherent policy?" Anyway, that's what my hope is.

08:04 We could do somewhere in the middle.

08:06 If you feel like you might have a cough or something, please try to keep your mask on.

08:12 Yeah, 100%.

08:14 I said this before, and just for people who didn't catch it, I'm not anti-mask, not anti-science, whatever.

08:21 When I went on a trip recently, long trip, maybe I was getting sick, I wore my mask the whole time even though no one around me did,

08:30 like a super long flight and the airport and everything because I wanted to be considerate.

08:35 I don't care if other people want to wear a mask.

08:37 That's great, but don't force this weird policy onto everybody who generally doesn't think that they'd rather.

08:45 It undermines the networking aspect, both for the sponsors and Expo trying to talk to people and each other.

08:53 All right, rant over, but please, fingers crossed for next year.

08:57 If you're out there and you agree with me, please let the folks know.

09:01 You don't have to email me.

09:03 I've already had this conversation a lot, but it's just closing the loop in the past.

09:07 I feel like what I said before pretty much was how it was.

09:11 You know what, though?

09:13 It's quite awesome, Brian.

09:14 Hinted at the top of the show, not that.

09:16 That's later. Mailtrap.

09:17 Let's talk about Mailtrap real quick.

09:19 This episode is sponsored by Mailtrap, an email delivery platform that developers love,

09:23 an email sending solution with industry-best analytics, SMTP, and email API, as well as SDKs for major programming languages

09:33 and 24/7 human support.

09:35 Try for free at mailtrap.io.

09:38 Indeed. Thank you, Mailtrap.

09:40 All right, over to you, Brian. What you got?

09:42 I'm going to talk about Git some more, actually.

09:45 Let's get it on.

09:46 I'm thinking about forking a project because you remember how projects used to have like fork me on GitHub, little things on the top corner.

09:56 They don't really do that anymore.

09:58 But we often think of contributing to an open source project just in the sense of forking it just so that I can make modifications

10:08 to contribute back to the project.

10:10 That's often how we--you create a fork, you create a branch on your own fork, and then you contribute back

10:16 to the project.

10:18 That's how we do contributions.

10:20 But what if you want to have a long-running fork of a project?

10:24 And that's what I'm considering.

10:25 And I was thinking about strategies, how to do that, because I don't know.

10:30 So I ran across this--a couple blog posts from the Git folks.

10:36 It's actually from Leslie Dennington.

10:39 Cool.

10:40 There's a couple of posts called "Being Friendly." So there's "Being Friendly, Friendly Forks 101,"

10:45 and there's "Being Friendly Strategies for Friendly Fork Management." And I think these are interesting because there's a lot of stuff

10:53 going on here, but not really.

10:58 We'll go through them relatively quickly.

11:01 They picked some examples to think about, and I was thinking I would really like to know from an example project,

11:07 and Git itself is a lovely example project because Git has several forks, and they have different policies.

11:15 So there's Git/Git, which is the main--wait.

11:23 There's Git for Windows, for instance.

11:24 So there's Git/Git, the base one.

11:27 There's Git for Windows Git.

11:29 There's Microsoft Git, and there's GitHub Git.

11:31 So there's four different friendly forks off of that.

11:35 Actually, it's not like that.

11:37 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,

11:46 which is a fork of the Git for Windows, and then there's GitHub Git, which is a separate branch fork.

11:54 Anyway, three forks on it, and they have different policies, and it's interesting to look at them.

12:00 So if you look about the different needs--

12:04 so the first article talks about the different needs for the forks, and then the second article talks about merging strategy.

12:10 That's really where I wanted to understand it because here's the idea.

12:14 I'm going to fork a project, and then I want to regularly get updates from the parent project because I want to maybe--

12:22 and this happens for internal companies a lot.

12:25 If I want to add on extra features that are not there, maybe I tried to contribute them, and they got rejected,

12:33 and I still need them so I can have a friendly fork, but I want to keep up to date with all the changes.

12:37 So how do you keep up to date?

12:39 So one of the ways is from a--you take what they call a merging rebase, which is what Git for Windows does,

12:49 and I guess I'm not going to try to find all the diagrams, but there's diagrams in here too.

12:55 But there's merging rebases where you kind of do like a fake merge where you say, "I'm going to merge,

13:04 but I'm actually only going to take my changes," and then you--so that isolates just your changes,

13:11 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.

13:20 It's a way to just do that.

13:22 The second way is a new branch, and that'll allow you to just take--like the Microsoft Git one does a new branch.

13:31 So for each upstream new version, you just create a new branch for that,

13:36 like completely do a new branch, and then you copy over your changes from past changes onto the new changes.

13:46 So you start the branch over again every time, almost.

13:49 And then the third one is just a traditional merge, like Git uses a traditional merge,

13:55 but there's a lot of noise in that, and so they say that that works okay.

13:59 It takes a lot of people and a lot of testing, though, and they often delay.

14:02 So let's say I picked, I don't know, any project, and for a major release, I'd maybe wait till like--

14:11 wait a couple months or something or wait whatever the dot releases to make sure

14:15 a couple of the bug fixes releases after the new features came out and then merge them.

14:20 And then at the end, which is great--

14:24 I know this is a lot of detail, but great articles.

14:27 Oh, there's a cool picture of the creating a new branch, completing a new branch, and then merging your changes over.

14:34 So there are some great pictures in here.

14:37 And then they also talked about like proactive versus cautious, like how frequently you're going to merge.

14:43 And this is just a really good discussion of--

14:46 this is a lot of work, guys.

14:48 If you're really going to maintain a fork of a project, you just take it slow.

14:53 Make sure you know what you're doing and know how many people you are there.

14:56 So it talks about the different scenarios and when you might or might not want

15:01 to use different versions.

15:03 And I think the final one says, if you're new to the fork game and want to keep it simple, just do merges

15:11 and be considerate.

15:13 Maybe that might be the easiest.

15:15 And I think I might go with this one to start with.

15:18 But I am intrigued by the whole merging rebase thing.

15:22 That sounds neat, too.

15:23 Actually, they all sound cool.

15:25 I might try all of them just to see how it goes.

15:27 But it's just me, so I might be crazy.

15:30 But I bring this up because I'm--

15:33 one, because other people might be considering like forking something for their own company use

15:38 or just wanting to possibly start a sister project for something, have it be slightly different.

15:44 How do you go about that?

15:46 So these are great articles.

15:47 But also, if I'm missing something, if this is not a great reference for this

15:51 and other people have other tools around, let me know.

15:55 By the way, the whole forking rebase thing, there was a script involved here.

16:00 So they shared the script that they used for doing this and then talked about some cool merging like diffs.

16:09 And there's a diff merge tool that they used for code reviews and stuff.

16:13 So anyway.

16:15 Yeah, very cool.

16:16 This is some advanced Git stuff right here.

16:20 You can easily get yourself in trouble if you fork a repo.

16:24 And even if you intend to make changes back and you change the branch that is being updated

16:29 on the remote or the original repository, you can end up with merge conflicts.

16:34 It almost always seems like a good idea to have a separate branch where you work

16:39 and something that syncs with the project.

16:42 And so that's kind of like that.

16:44 Plus, then what do you do to keep it in sync?

16:48 You definitely could end up with conflicts if your intention is not to keep it in sync

16:52 by pushing your changes back to it, right?

16:54 Yeah.

16:55 The other thing that I want to point out that wasn't in this article is tags are completely separate.

17:01 I know that tags are part of the Git repository, but they don't come automatically.

17:06 So, and that's often, I don't know the reason, it's convenient that they don't come.

17:12 It's both convenient and painful because the new project will have its own versioning scheme,

17:17 but if you want the same versioning scheme, you have to do that separately.

17:21 You need to make sure that you're pulling the tags as well.

17:23 So, yeah.

17:24 A lot to consider.

17:25 Yeah.

17:26 All right, let's talk about Tack.

17:28 Not a super popular project yet, but pretty awesome.

17:32 Let's see, it's about a month old, I would say.

17:36 No, four months old is how old it is.

17:38 So, this is a project that lets you understand the architecture and actually not just understand,

17:44 let you specify the architecture of your application and enforce it through a linting sort of thing, okay?

17:52 So, let's see what they say here.

17:54 Python tool to enforce modular design.

17:57 So, maybe the best way, Brian, would be to like look at this little thing

18:01 as people are watching.

18:02 You can see there's a little video demo, which is great.

18:05 So, what it will do is it will show you, you set up some config files and you say,

18:11 "I have these parts of my application, right?

18:15 These modules or these packages, and I want to control how they interact with each other."

18:21 So, if I say, "This stuff makes up a data layer here, and this stuff makes up an API layer,"

18:26 you might say that the API layer and the data layer are not allowed to talk to each other.

18:30 Only stuff that consumes either of them can coordinate across them, right?

18:34 So, for example, in the API section, shouldn't import something from the data section

18:39 and vice versa.

18:40 You want them to be independent so that potentially they're easier to test, they're easier to change.

18:46 You know if I change this part, it's only going to affect the thing itself

18:50 and the stuff that I explicitly understand to be using it.

18:54 It doesn't become a spider web of everything's connected to everything as much as it can in Python,

19:00 because circular dependencies are an issue.

19:02 But still, that's the idea, okay?

19:05 So, you just install it, and you have to add a package, and it'll let you take through and specify that,

19:12 or you can just come up with a YAML file, a package.yaml, and then you give it a tag,

19:18 like this one is a core, and this one is a DB, and this one is utils.

19:21 And then at the root, you come up with a tag.yaml that says the core depends upon DB and utils.

19:28 So, the core can import from DB and utils, but not vice versa.

19:31 The DB depends on utils, and utils shouldn't be importing from other places

19:35 in your application.

19:36 And then you can run it, a CLI tool against your app, like tag check, and it tells you that

19:41 there's some import that's breaking the rules that you've laid out.

19:44 So, the other thing, yeah, go ahead.

19:46 The other thing that's interesting is it allows you to define a public API.

19:50 You can say, "These things I would like you to be able "to use when you use my package,

19:54 "but this other stuff is internal stuff, "and I make zero promises about it,

19:58 "so please don't use it.

20:00 "I know you could because of Python, but don't." And it'll enforce that as well.

20:04 It'll say, like, "You're trying to use something "that I'm explicitly trying to say don't use."

20:09 So, I don't think this is useful for every app, but if you've got different people working on it

20:14 and you want to be real careful about your architecture, you know, it's worth checking out.

20:17 - I think this is, I am going to check this out.

20:20 It's not just, like, you know, bad architecture or something.

20:24 You might bring some new people onto a team, or it might help people get used to a project

20:31 and the rules around it easier if you aren't allowed to do stuff.

20:36 - Yeah, that's a pretty good point.

20:37 - So, how does it stop it?

20:38 Does it, is it a post-testing?

20:41 - It just prints a warning.

20:42 It just prints a warning.

20:43 - Stop it at runtime?

20:44 - It's like the linter would fail.

20:46 So, it's like a linter error, but I mean, it doesn't actually, there's no runtime checks.

20:51 So, no runtime checks.

20:52 - Okay.

20:53 - Yeah.

20:54 - All right, cool.

20:55 - Yeah, but you can set it up as a pre-commit hook, in which case, I guess you couldn't commit

20:59 if you wanted, but yeah.

21:01 I kind of like the idea of the public API.

21:03 Like, I know it looks like you should use that, but there's actually this other thing

21:06 that does more checks and brings in some other stuff and adds versioning,

21:09 and you should use that function to make this change.

21:11 Don't, like, directly, I don't know, whatever, interact with something, right?

21:13 - Yeah.

21:14 - Cool.

21:15 All right, extra time.

21:16 What do you got?

21:17 - I got, I guess, one extra.

21:20 I noticed that the pedantic guys, or pedantic people, I should say, have something they're trying to sell now.

21:30 So, being a company, you have to make some money somehow, which is good.

21:34 But they came up with a tool called LogFire, and it just looks fun.

21:40 So, it's advertised as uncomplicated observability from the team behind pedantic.

21:45 They have an observability platform to look at, like, logging and other things,

21:51 and it's actually, I haven't dug into it too much, but it looks pretty slick.

21:57 Anyway, right now, the pricing model is free for everybody, but they're going to eventually charge people.

22:06 - You could know how much they're gonna charge you if you had--

22:09 - That's it.

22:10 - Yeah, you'd know how much they're gonna charge you if you had some of that, like, cool,

22:13 fake, futuristic image capabilities.

22:16 Zoom, enhance, zoom, enhance, 'cause they have the blurry pricing.

22:20 - Yeah, well, the website's just beautiful.

22:22 - Enhancing, enhancing.

22:23 Oh, it's $9.99, I don't know what it is.

22:25 - It's cool. - Yeah.

22:26 Yeah, it does look good.

22:27 - Do you have any extras?

22:28 - Well, just a quick comment on this.

22:30 What I think is interesting about LogFire, and again, congrats to Samuel and team over there.

22:36 I saw those folks at PyCon as well.

22:38 There's a lot of observability platforms that you can add to different Python stacks

22:44 and other stacks as well.

22:45 But what's kind of interesting about this is it's super focused on specific frameworks

22:51 to add more observability than normal to them, I guess.

22:55 So, for example, you'd say, LogFire.instrument.psychopg or LogFire.instrument.fastapi,

23:02 and it gets, like, really deep understanding of what that thing is doing.

23:05 It gives you reports around it, rather than just, oh, I saw a web request,

23:08 or I saw you talk to a file or an API or something, you know?

23:12 - Yeah. - Yeah.

23:13 I do have a couple of extras.

23:14 Let's see.

23:15 The Getting Started with NLP and spaCy course by Vincent Vommerdam.

23:20 He and I decided we're going to do 10% on the course for the month of May, 10% off.

23:28 So if you would like to take this course and save a little bit, you've got nine, 10 days to do so,

23:35 if you listen to this right away, right?

23:37 Basically, during May 2024, you can save 10%.

23:41 So put the link in the show notes.

23:43 Check out Getting Started with NLP and spaCy.

23:45 Super cool, super cool one.

23:47 And I feel like I might have had another...

23:50 I'm going with no.

23:51 That's my only extra.

23:53 - Okay. - And I saw we both put a joke in, but let's do your joke next week,

23:59 and I'll do this joke this week, okay?

24:00 - Okay. So do my joke next?

24:03 - Yeah. - All right.

24:04 So I was actually listening to a book called Company of One from Paul Jarvis.

24:11 Excellent book.

24:12 I'm actually listening to it the second time now.

24:14 I'm really enjoying it.

24:16 Anyway, he talked about one of the people he talked about was somebody that runs, actually, Tom Fishbourne

24:23 runs a company called Markitunist.

24:25 And here's a cartoon from Markitunist that I actually really love.

24:30 It's the evolution-- - Hold on, let me see your screen.

24:31 One sec. I don't see your screen anymore.

24:33 - You don't see it? - No.

24:34 - Okay. - That's right.

24:35 You just have to tell it to us.

24:36 Most people listen anyway.

24:37 - Okay. Evolution of Smart Products.

24:41 If I were to buy a toaster, first there's the toaster. It makes toasts.

24:45 Then you've got Wi-Fi enabled.

24:47 Makes toast after making you wait for a firmware update.

24:51 Data-driven toaster.

24:52 Makes toast by watching how you like toast.

24:57 So it watches you.

24:58 Toast as a service. Makes toast for $5.99 a month.

25:01 Ad-supported toaster.

25:02 Makes toast and lets you know that Smuckers is on sale.

25:05 And then there's the AI toaster.

25:07 Toast? I'm afraid I can't do that, Dave.

25:10 - Ooh, you do it good. - How?

25:13 Let me in. Goodbye, Dave.

25:16 - Goodbye, Dave. - I love it.

25:18 I love it. Yeah, that's a really good one.

25:20 - Anyway, the Mark Tooth, I'm not really--

25:24 He's got a great company.

25:26 There's a couple other ones.

25:27 One of them I really related to.

25:30 Anyway, there's lots I related to and enjoyed his stuff.

25:34 - Awesome. Yeah, very funny one.

25:36 Good stuff over there. So nice finding you.

25:38 All right. Well, I think that is it for the week.

25:43 Brian, thank you.

25:44 - Thank you. - Yeah, thanks, everyone, for listening.

25:47 See you all later. - Bye.

25:48 Thanks, everyone, for listening.

25:49 See you all later.