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 Okken.
This episode is sponsored by Mailtrap.
Better email sending APIs.
Check them out at pythonbytes.fm/mailtrap.
Tell you more about them later.
And you can connect with us over on Fostadon.
We're all Mastodon in general, but we're all over on Fostadon.
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 their fate.
So at least for the time being.
I just had a friend of mine get mad at me for unfollowing him on Twitter.
It wasn't just you, man.
I don't follow anybody on Twitter.
Don't take it personally.
Yeah.
So people can find us there as well, although more conversations on Mastodon.
And check out the live show.
If you would like pythonbytes.fm flash 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?
I'm going to start by talking about Git force, actually.
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 I've seen a few people who do Python who use Git also.
That's true.
So one of the things that happens is when you're using Git and you've got your local repo that's not quite in sync with the remote one.
And if it's just you and it's somehow when you push and it doesn't work right, you do a push force with a --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 did not know about either of these things.
So I'm really glad that he wrote this up.
The idea is I don't know what I don't know what that means.
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 you're the tip of your current branch is behind its remote counterpart.
So you're not up to date.
So 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'm 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 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.
So the so one of these one of these flags will make sure that you have at least fetched the branching question.
So all in all the commits that you've that you've fetched all of the commits that are involved so that it assumes that you've looked at them.
And then one of them makes sure that you have actually 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.
This 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 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, yes, speaking of safety, how was your flight?
Oh, yeah.
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 is 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 Talk Python 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 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, 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.
They're 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.
They're like, can 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 a tremendous mistake.
The only reason I bring this up, not to 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.
I mean, that's what my hope is.
We can 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.
Yeah.
100%.
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.
When I went on a trip recently, long trip, 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 considerate.
And I don't care 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.
Right.
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 much was how it was.
But you know what, though?
It's quite awesome, Brian.
I hinted at the top of the show.
Not that.
That's later.
Mailtrap.
Let's talk about Mailtrap real quick.
Okay.
This episode is sponsored by Mailtrap, an email delivery platform that developers love.
An email sending solution with industry-best analytics, SMTP, 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 like
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 you create a fork.
You 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 blog posts from the Git folks.
It's actually from Leslie Dennington.
Cool.
There's a couple of posts called being friendly.
So there's being friendly, friendly forks 101.
And there's being friendly strategies for friendly fork management.
And I think these are interesting because 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 a Git slash Git, which is the main weight.
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 not.
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 completely, it's 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 regularly get updates from the parent project.
Because I want to like maybe, and this happens like for internal companies a lot.
If I want to add on extra features that are not there, they like, maybe I tried to contribute
to them and they got rejected.
But 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 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, the new space on the, 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, and that, that'll allow you to just take like the, the, the Microsoft Git one does a
new branch.
So for each upstream new version, you just create a new branch for that.
Like complete, completely do a new branch.
And then, then you copy over your changes from, from past changes onto the new changes.
So you like start the branch over again every time, almost.
And then the other, the third one is just a traditional merge.
Like Git, Git uses a traditional merge, but there's, 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 of 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.
Oh, there's a, there's a cool picture of the, the creating a new branch, completely new branch
and then merging your changes over.
So there are some great pictures in here.
So the, and then the, they also talked about like proactive versus cautious, like how frequently
you're going to merge.
And this was just a really good discussion of, this is a lot of work guys.
If you're really going to 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 like the, the final one says, if you're new to the fork game and want to
keep it simple, just do just do merges and do it, 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 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 a, I might be crazy, but I, I bring this up because I'm a, 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.
Have it be a slightly different.
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 have, they like shared the script that they use for doing this and then talked about
some cool merging like diffs.
And there's a diff merge tool that they used for code reviews and stuff.
Yeah.
Very cool.
This is some advanced get 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, the branch that is
being updated on the remote or the original repository, you can end up with merge conflicts.
It's almost always seems like a good idea to have kind of a separate branch where you work
and something that syncs with, with the project.
Right.
And so that's kind of like that.
Plus like, then what do you do to like kind of keep it in sync?
Cause 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.
I know that tags are part of the get repository, but they don't come automatically.
So, and that's often be, 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 auto, you have to do that separately.
You need to make sure that you're pulling the tags as well.
So yeah.
Yeah.
A lot to consider.
Yeah.
All right.
Let's talk about tack.
Not a super popular project yet, but 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 are 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,
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 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 still, that's kind of the idea.
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 tack.yaml 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 against 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 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 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 bring some new people onto a team or it might, it might help people get
used to a project 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, is it?
Oh, it just, it just prints a warning.
It just prints a warning.
It's like a linter would, the linter would fail.
So it's like a linter error, but I mean, it doesn't actually, there's no runtime checks.
So no, no runtime checks.
Okay.
Yeah.
All right.
Cool.
Yeah.
But you can set it up 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.
Like 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?
I got, I guess one extra.
I noticed that the pedantic guys.
Pedantic people, I should say, have something they're trying to sell now.
So being a company, you have to make some money somehow, which is good.
But they came up with a tool called Logfire and it just looks fun.
So it's advertised as uncomplicated observability from the team behind Pedantic.
They have an observability platform to look at like logging and other things.
And it's actually, I haven't dug into it too much, but 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, you know how much they're
going to charge you if you had some of that like cool, fake, futuristic image capabilities.
Zoom, enhance, zoom, enhance, because they have the blurry, blurry pricing.
Yeah.
Well, the website's just beautiful.
Oh, it's $9.99.
I don't know.
I don't know what it is, but yeah.
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.instrumentPsychoPG or logfire.instrumentPsychoPG, and it gets like
really deep understanding of what that thing is doing.
And it gives you reports around it rather than just, oh, I saw a web request or I saw you talk
to a file or an API or something, you know?
Yeah.
I do have a couple of extras.
Let's see.
The Getting Started with NLP and Spacey course by Vincent Vomerdam.
He is, he and I decided we're going to do 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 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 have 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.
So, so do my joke next?
Yeah.
All right.
So I was actually, listening to a book, called Company of One from, 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, somebody
that runs, actually Tom Fishbourne runs a company called Marketunist.
And here's a, cartoon from Marketunist 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.
Well, I'm usually got to tell it to us.
Most people listen anyway.
Okay.
Uh, evolution of smart products.
If I were to buy a toaster, first there's the toaster.
It makes toasts.
I mean, you've got wifi enabled makes toast after making you wait for a firmware update.
Data driven toaster makes toast by, by watching how you like toast.
So it watches you toast as a service makes toast for 599 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'm afraid I can't do that.
Dave.
Afraid I can't do that.
Dave.
Ooh, you do it.
Good.
How?
Let me in.
Goodbye, Dave.
I love it.
Yeah.
That's a really good one.
Anyway.
Um, the, market is, I'm not really, it's, he's got a great company.
There's a couple, a couple other ones.
The one I really, one of them I really related to.
Um, anyway, there's a lot of thoughts I related to and, enjoyed his stuff.
So.
Awesome.
Yeah.
Very funny one.
Uh, good stuff over there.
So nice find.
All right.
Well, I think that is it for the week.
Brian.
Thank you.
Yeah.
Thanks everyone for listening.
See y'all later.