Transcript #269: Get Rich and replace your cat

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

00:04 This is episode 269, recorded February 2nd, 2022.

00:10 And I'm Brian Okken.

00:11 And I'm Luciana.

00:13 And?

00:14 I'm Brett Cannon.

00:16 And we have Brett.

00:17 So we invited Luciana on and we decided to have Brett on also.

00:21 So we got to have some fun.

00:23 Michael's actually gone this week, but I hope he enjoys listening.

00:29 So hi, Michael.

00:30 And we'll talk to him next week.

00:33 So before we get into the topics, though, I think people hopefully know who Brett is.

00:40 Brett Cannon, you've been on the show before.

00:42 A couple times.

00:43 Yeah.

00:44 Thank you very much for having me back spontaneously.

00:47 Spontaneously.

00:48 Like minutes ago, we said, hey, we should get Brett on.

00:52 So Luciana, welcome to the show.

00:54 Can you tell people a little bit about who you are?

00:56 Thank you.

00:57 Yes.

00:58 I am, well, Luciana.

01:00 I work with Brett on the Python extension for Visual Studio Code.

01:04 But I'm a program manager.

01:05 And, yeah, I'm very excited to be here on the show.

01:09 I was telling Brian that I used to listen to Python Bytes going to work back when we worked on offices.

01:16 Went to work.

01:19 So it's really, really cool to be here.

01:22 Yeah.

01:23 Nice.

01:24 Well, thanks.

01:25 I'm glad to have you here.

01:27 So let's jump into the topics.

01:29 We have an abbreviated list of topics, but we'll make it fun anyway.

01:34 I'm going to start with Rich CLI.

01:38 So, Will McGoogan.

01:43 It seems like we talk about him every show.

01:46 But this is cool.

01:48 So I was like, oh, I'll try it out first.

01:50 And I'm already hooked.

01:51 So Rich CLI is, it seems lame if I describe it.

01:57 So you install it.

01:59 I installed it with PipX because I just want to use it everywhere.

02:03 And then what it does is it does, like, pretty printing of stuff.

02:07 Like, you can give it a file.

02:08 And basically, that's what I use it for.

02:12 Maybe it does other stuff.

02:12 But you can give it a file, like, example.py or example.markdown or something.

02:18 And it will do the rich printing, pretty printing, right on your screen in the terminal.

02:24 That seems like not that big of a deal, right?

02:28 But it is so cool because it's all, like, nice colors.

02:30 And you can have themes.

02:32 And I used, what, you can do pretty printing of JSON.

02:37 So it will format your JSON for you without having to reformat it.

02:40 You can do a dash M flag for markdown.

02:43 I've been doing that to see my markdown.

02:45 And it does some cool stuff with markdown.

02:49 Although, supposedly, like, with Python files and C++ files and stuff, it's going to do syntax highlighting based on extension.

02:57 I'm wondering why I got to pass in a dash M for markdown.

03:01 It seems like a dash MD should work fine.

03:03 But anyway.

03:05 That's actually going to be my immediate question was, why do you have to specify the dash M just for markdown?

03:10 And then, like, and then there's some flags that's cool, like, whether or not you want to use it with pipes.

03:17 So you can, if it's pipe it to something, it'll strip out the formatting stuff, like the color codes and whatever.

03:26 But you can force that to be on.

03:28 Well, I wanted to, I tried to use it with a big file, and it just flew past me.

03:34 And then, so I tried to pipe it to more or less, and it stripped out the formatting.

03:40 And so, well, I tried to fix that, and then more and less don't handle that.

03:45 And so, and this was just yesterday.

03:46 I'm like, kind of really be cool if Rich CLI has supported paging within it.

03:53 And so today, Will said, hey, I added paging to Rich CLI.

03:58 So Rich CLI now has paging.

03:59 Of course he did.

04:00 Like, within a day.

04:04 So anyway, pretty cool projects.

04:07 Have either of you checked this out yet?

04:09 I did the exact same thing you did.

04:11 I used PipX and installed Rich CLI yesterday.

04:15 One thing is, I will say, I use a, I've actually been using a replacement.

04:22 So this is kind of like a replacement for the cat tool on Unix, right?

04:25 And I've been using an alternative called bat, B-A-T, that's implemented in Rust, and has

04:33 a lot of this as well in terms of color syntax and stuff.

04:36 But I'm willing to bet Rich is, Rich, I'm willing to bet Will's going to move a bit faster.

04:43 So I'm just going to probably switch over to using Rich CLI over bat and just see where

04:49 this goes.

04:49 But I mean, come on, Will even made the output.

04:52 It looked great.

04:53 Yeah.

04:54 Sorry for the output for the help.

04:56 It looks phenomenal.

04:57 One of the things that I noticed was that the default theme, the coloring, didn't look quite

05:07 right on the black background that I was using.

05:09 So I just, I exactly, I was using it for cat.

05:14 So I just aliased my cat to use Rich with the Monokai format turned on.

05:21 So Luciana, would you use this for anything?

05:24 Yeah.

05:25 I was going to say I'm behind.

05:26 I haven't tried it yet.

05:28 But once I saw the amazing things they have there, it's quite a few.

05:32 So I was excited to try it out.

05:35 So we'll do it today, hopefully.

05:36 Yeah.

05:38 Cool.

05:40 Well, let's switch over to debugging.

05:44 Yeah.

05:45 So I guess most folks, I don't know, at least I, when I started learning Python, I used to debug

05:51 using print statements, which is like no shame in that.

05:54 It works very well.

05:55 I still do that when it's like for real quick things.

05:58 But I wanted to bring up this awesome tool that we have, the bug pie.

06:03 It's a debugger for Python.

06:05 And you can use it like as a CLI tool.

06:07 You can also just import it and set breakpoints normally.

06:10 I'm a big fan of UI debugging.

06:13 So I actually prefer to use it built into the Python extension for VS Code, which is the

06:19 thing that we work on every single day.

06:21 So yeah, I wanted to bring up a few features that are really, really cool and I find very

06:27 helpful and that save up, helps me save up a lot of time when I'm debugging code.

06:32 So the first one of them is kind of like conditional breakpoints.

06:37 Yeah.

06:39 Sorry.

06:39 Go ahead.

06:40 No, no, go ahead.

06:41 Neat.

06:41 Yeah, it's super neat.

06:43 And this conditional breakpoints is something that I bring up because I guess when you're

06:48 trying out debugging for the first time using the UI, you set up a breakpoint and then you

06:53 hit it there and then you always reload the window or reload the bugger, sorry, to hit that

06:57 breakpoint again.

06:58 And then you keep stepping over into a hit to condition that you want.

07:02 And in this GIF there, they have an example on TypeScript, but it works on Python files as

07:06 well once you install the Python extension.

07:08 But basically you added the breakpoint to insert a certain condition so that the bugger will

07:14 only stop when that expression is met or the condition is met.

07:18 So one example there is hit count.

07:19 So you can imagine if you have like a for loop and you really want to stop when, for example,

07:25 after 10 iterations of that loop.

07:27 So you don't want to stop on that breakpoint and hit the step over 10 times.

07:31 You just want to stop when it hits 10 times.

07:35 So you can do that with the hit point.

07:38 You can also add expressions.

07:40 So if you know like, oh, I want this debugger to stop only when this variable gets the value

07:47 of, I don't know, five, then you can also do that.

07:50 And it's pretty cool.

07:52 It saves up a lot of time.

07:54 And you can also do log points instead.

07:56 If you're not interested in breaking the execution, just want to make sure that line was executed.

08:01 So it prints out on the output that, hey, this is, we hit that point.

08:06 This is like a log point.

08:07 So it doesn't really break anything.

08:10 But it's very informative.

08:12 Cool.

08:13 So this is, this is an extension for, for VS Code.

08:18 Yes.

08:19 I believe most IDEs support that same feature.

08:22 But it's a feature that I always recommend folks to look for in their IDEs or editors because

08:29 it does save up a lot of time.

08:30 So, so to be clear about the tech stack on this.

08:34 So there's a couple of layers to this.

08:36 So at the bottom layer is PyDevD by Fabio Zdrasny.

08:40 Key, we have him on contract as a consultant to do anything we need to have get fixed and stuff

08:49 and just support the project.

08:50 Because on top of this, we have another project that we have called DebugPy, which implements

08:56 what's called the DebugAdapter Protocol or DAP.

08:59 It's a, meant to be a language agnostic protocol for debuggers to talk to editors.

09:05 It comes out of VS Code.

09:06 It's used by Visual Studio as well.

09:08 And actually, it's now used by Jupyter.

09:10 This is how Jupyter was able to launch recently with debugger support.

09:15 Because they actually run DebugPy.

09:16 And then on top of that, we have support.

09:19 Because we're a VS Code extension, we support the debug adapter.

09:23 So we ship DebugPy in box right now for supporting this.

09:27 Although we are talking about breaking the extension, breaking debugging out to its own extension so that we can actually update it at a better cadence with DebugPy.

09:36 Because we can do platform-specific V6s now, extensions for VS Code.

09:40 So we'll be able to shrink that down a bit for our users.

09:45 So is there like a tutorial somewhere that has like all of the cool Python extensions that I need for VS Code to get VS Code with Python to work really great?

09:55 Yeah.

09:56 We have our Get Started tutorial.

09:59 It has like, it doesn't have a lot of extensions.

10:01 So there's definitely more extensions that I find to be personally cool.

10:04 Maybe we could have a blog post about this and like cool extensions for Python, specifically in VS Code.

10:09 Because there are some of them.

10:10 I think Don Giamani, he's the one who created the Python extension before it was a Microsoft thing.

10:18 And Microsoft Hirem and everything.

10:20 So he has one that I always talk about, which is the Python Environments Manager extension.

10:26 It just displays the environments that it can find on your machine and what packages are installed there.

10:31 It's kind of like an environment viewer.

10:33 And it's pretty cool.

10:34 It's one that I always tell people about.

10:36 You know, a deep dive into all the useful extensions to add would be a great testing code episode.

10:42 Just saying.

10:43 I love that idea.

10:45 I like it.

10:47 Okay.

10:48 Well, speaking of plugging stuff, I want to take a moment to thank our sponsor.

10:55 So this episode is sponsored by Datadog.

10:59 Datadog is a real-time monitoring platform that unifies metrics, traces, and logs into one tightly integrated platform.

11:06 Datadog APM empowers developer teams to identify anomalies, resolve issues, and improve application performance.

11:13 Begin collecting stack traces, visualizing them as flame graphs and organizing them into profile types such as CPU, IO, and more.

11:24 Plus Datadog APM.

11:25 Plus Datadog APM's live search.

11:26 So you can perform searches across full streams of ingested traces generated by your application over the last 15 minutes.

11:35 Try Datadog APM free for a 14-day free trial.

11:39 And Datadog will send you a free T-shirt.

11:43 And actually, I have one of these purple T-shirts, and I love it.

11:46 So visit pythonbytes.fm/datadog, or just click on the link in your podcast player show notes to get started.

11:53 Awesome.

11:57 I got to pay the bills.

11:58 So where are we at now?

12:02 We're back on me again.

12:04 Unless, Brett, you got something right out of the blue you want to talk about?

12:09 I'll put you on the spot.

12:12 That's okay.

12:14 I believe you've talked about exception groups on the podcast already.

12:18 I don't.

12:20 Oh, yeah.

12:20 I think so.

12:21 Yeah.

12:21 So just because Datadog sponsor actually cares about trace packs and stuff.

12:25 One interesting thing that's coming up in terms of a PEP, it has not been given to the steering council yet.

12:32 But there's actually a PEP coming up that's going to add a Dunder notes field potentially to exceptions.

12:41 This actually came out of the exception group work because Zach from Hypothesis was working with it over on that side and realized that it would be convenient to be able to kind of just basically, literally, the name says, add a note to extensions to kind of help explain why this came about.

12:57 And so there's a PEP coming that's going to basically just allow libraries and stuff that work with exceptions to just attach a little note saying, this is why this happened.

13:08 More than just a little thing, especially for exception groups, you can kind of get kind of big and murky by having a single note added to it to help explain why this came about.

13:19 It's hopefully going to help make it easier for users to understand a bit more why something happened.

13:25 So that's pretty neat.

13:27 I like it.

13:27 Nice.

13:30 I got some feedback recently that I'm not covering enough test stuff on Python bytes.

13:37 So I'm going to try to I'm going to try to try to solve that.

13:42 I'm not going to cover test of every week, but I've got a test thing this week that I'm pretty excited about.

13:48 So Simon Willison, great guy.

13:52 He wrote an article called documenting unit tests.

13:55 And this.

13:57 Wow, it's old.

13:59 It came out in 2018.

14:01 I just noticed it.

14:02 So, yeah, there's the Internet for you.

14:04 But it's like it's a super cool idea.

14:08 So the idea is we've got tests like pytest and other test runners.

14:13 You can do anything.

14:15 He's using pytest to test your source code.

14:18 But why not?

14:19 And Python has all these introspection things you can do.

14:21 So he's using introspection to look at the code and then introspection to look at the documents with with his test code and then make some make sure that there's some items that are definitely in the docs.

14:36 As an example, so in this, this is example in the in the doc, in the blog post is mentoring data, his project data set.

14:47 And so the test for this is right there.

14:49 So you can go take a look at what he's doing.

14:50 But he takes a look at the repo.

14:53 And for instance, for all, if he adds a config option, he's got a test to make sure that the config option gets documented.

15:00 That's cool.

15:02 So it's just tests or fail if he forgets to document a new option.

15:05 Also, plug in hooks and different views within data set.

15:10 They all have to make sure that he has special the views like he wants special pages for each view.

15:16 So it makes sure that there's a page there.

15:18 So I just there's a couple neat things here.

15:21 Just the concept of using tests to make sure that there's things documented.

15:26 It doesn't tell he makes a comment that it's not telling like a lot of tests.

15:31 It's not telling you that the documents are good or documented well, but that they're documented at all, which is which is good.

15:38 And same with our code tests don't necessarily tell you that your code is perfect.

15:43 It's just that they're tested.

15:45 The other thing that I wanted to point out about this is there's some nice use of features of of py tests.

15:51 So there's a nice use of fixtures and parameterization.

15:54 So he's got like the views, for instance.

15:57 He goes out and looks at generate like goes and gets a list of views from the code and then use that list to have a generated test to make sure that each of those views is tested or is documented.

16:10 It's a nice idea.

16:12 I've been trying to do that sort of generated generated parameter lists.

16:17 I'm trying to do that more in my code because it it's just kind of a cool idea to generate your own test cases.

16:23 So anyway, good job, Simon.

16:26 Yeah, as someone who spends more time reading code and writing code, I definitely appreciate this initiative.

16:33 It's very much better to have documented code out there.

16:38 Well, a combination of like making sure that the test, the documents are tested or things are covered.

16:45 And then also, I think a few episodes ago, we talked about a project projects using generating documents themselves.

16:57 So like, for instance, instead, if you're going to plop your help text in your document, don't copy and paste it.

17:04 Use code to generate that.

17:06 And then it's always going to be correct if you got it in your build system.

17:10 So nice ideas.

17:13 And it was about using cog, right?

17:15 Yeah, that was it.

17:17 Cog, I forgot.

17:17 Yeah.

17:19 And what I really love about that is when I came across cog a long time ago, I thought, I got to have a use for this, but I can't think of it.

17:30 But this is the perfect use because we often do that within our little readme or something is just to plop a little example of code using your tool, whatever library you have.

17:43 So having cog generate that for you is great.

17:45 So I think I need to go back and do it.

17:48 So I've got a little toy project called cards that I use for teaching testing.

17:53 And I changed the interface for it for layout reasons.

17:58 The tables that I was using didn't show up in e-books very well.

18:03 So I switched the table format, but then I forgot to change the readme.

18:08 But if I had cog in place, I would already be doing it.

18:12 So it's neat.

18:14 My first thought was to write tests to make sure that the output in my readme was the same as the code.

18:20 But I think a better idea is to just have the readme generated.

18:24 So, I mean, either one works, but both are good ideas.

18:27 Yeah.

18:29 And to tie this back to this point, Simon's the one that actually started the trend on Twitter of everyone using cog to use this on their readme.

18:37 At least that's how I first came across it.

18:38 And then I subsequently saw multiple people do it.

18:40 And then I finally had the same reaction you had.

18:42 Brian's like, oh, yeah, I've been looking for a reason to use cog for ages.

18:45 I never quite had one.

18:46 I was like, this is a great one.

18:47 So I went and updated the readme for the Python launcher to use this to generate all the URLs for downloading the built binaries for it.

18:55 So it's great.

18:56 Gulf binaries?

18:58 Built.

18:59 Built binaries.

19:01 Okay.

19:01 Yes.

19:01 Because I tried to build the launcher for like a bazillion different platforms.

19:08 And I'm grateful for that because I'm using the launcher like almost every day now.

19:12 Oh, fantastic.

19:13 We are.

19:15 Thank you, Brett.

19:15 Well, so let's pop over to talking about ourselves.

19:23 Oh, that was such a good.

19:26 Wow.

19:27 I'm impressed.

19:28 Yes.

19:30 So this is a 7373 self type.

19:31 I heard from, well, Brett Cannon there that it has been recently accepted.

19:36 And it's interesting for me because I'm now learning more about types in Python.

19:41 I'm very new to it, admittedly.

19:43 And I thought it was interesting because, well, adds this way to another thing methods that return an instance of their class.

19:52 And they give a very cool example there of a class or shape and then we have circle.

19:57 Then here it's for shape.

19:58 And then shape has this method called set scale.

20:02 And then the type that returns is shape.

20:05 And because it returns self.

20:07 And for circle, it returns self as well.

20:11 So it's a type circle.

20:12 And then it shows like there are some, for example, editors that may throw in error when you call circle set scale, which is a method from shape and then set radius, which is something from circle.

20:26 But once you call them, it will say error because shape doesn't have this method that is specific to circle.

20:37 So to kind of like have this better way to frame that would be to return self.

20:43 And it was accepted.

20:45 And it's very interesting.

20:46 I feel like it seems very clean to me and a very good solution.

20:50 So I'm personally excited that it was accepted.

20:53 It was very well explained as well.

20:55 And that was real.

20:58 For people on the podcast who can't see what Brian's scrolling through, basically, think of capital S self as the return type for all those class methods you write that construct an instance of your object.

21:13 This is what this is built for, right?

21:16 It's fantastic.

21:17 If you have the from whatever method, class method on your class to construct that class from something else, you'd now have a return self with a capital S versus specifying the exact class that would have returned.

21:30 So you don't have to worry about what that's going to look like and having to worry about the spelling or any of that forward declaration problems you can have if you don't do from Dunder future import annotations, right?

21:43 Where it's like, oh, I'm referring to a name that doesn't exist yet.

21:45 And Python throws a fit because that object doesn't exist yet by that name.

21:49 So it solves a couple problems like that.

21:52 But it's it's really basically if you write class methods that construct instances of that class.

21:57 It's great.

21:58 Well, I don't, but I probably will now when this comes out.

22:03 So is this is this part of 3.11?

22:07 Do we know?

22:07 3.11, right?

22:08 Yes.

22:08 Nice.

22:09 Yeah.

22:10 So you can probably get that probably today, if not in the near future from the typing extensions package, which kind of tries to do a back port and forward port of anything in the typing world.

22:22 That's experimental or has been landed, but not in a release yet.

22:25 And I believe the type checkers.

22:28 I don't know if they all support it yet, but I'm sure very shortly they will support this.

22:32 So you can you can get to it today.

22:35 And then we get we keep people that are writing tools like flake and black on their toes, catching up with all these changes.

22:44 Well, luckily, it won't hit them because it's all typing.

22:46 So just strings to black.

22:50 And I don't think flakey don't care.

22:51 But but like my pi, pi right slash pilance, pi type, pyre, all those type checkers are the ones that have to get updated for this.

23:01 But they were all in on the discussion of even proposing this.

23:05 Nice.

23:07 But is that we repeat that?

23:10 So the all these these people writing these tools were involved with this, these sorts of type processes.

23:17 Yeah.

23:17 So the way typically decisions around typing happen, especially from a static typing perspective, not I don't want to make statements on pydantics part in the dynamic typing world, because there's kind of two parts to typing.

23:30 Right.

23:30 There's the general typing as in.

23:32 Oh, there's the concept of typing now in Python.

23:34 But there's the people who do static typing.

23:36 Right.

23:37 And that's the kind of thing where you add your type annotations, your type hints, and you run a tool later that somehow reads them offline, as it were.

23:44 Right.

23:45 Like my pi or pi right or whatever.

23:47 And then there's the dynamic typing folks.

23:49 That's like pydantic where during runtime, they actually look at the annotations.

23:52 From the static typing perspective, there is something called the typing sig.

23:58 It's a mailing list.

23:58 And all the major static type checkers all work there together to try to figure out where they want to take things and kind of what gaps there are in terms of typing.

24:10 Basically, how can they move typing forward in Python?

24:13 It's also a place people can go to ask for help if they have a generic typing question that isn't too tool specific.

24:18 But to answer your direct question, Brian, the tools that are involved there, which are basically all the type checkers, static type checkers that I know of.

24:28 So there's py write, which underlines py lance, which is what we use for our completions in VS Code.

24:35 There's my pi.

24:37 There is pi type that comes from Google.

24:40 And then there's py that comes from meta.

24:43 Okay.

24:46 Wow.

24:48 Dizzying.

24:49 Yeah.

24:50 Although, I mean, one of the nice things about all the peps, right, is this is all backed by specs.

24:55 So there's not a lot of crazy deviation, as it were, from the semantics.

24:59 It's more of a bug if someone disagrees.

25:01 So they're all pretty consistent.

25:04 But some of them do a bit more like inferencing.

25:06 Like py type does more like runtime inferencing and other inferencing to try to kind of fill in the gaps.

25:11 That's actually why Google wrote it, I think, to help them move over to Python 3, start introducing types to their code base.

25:17 Yeah.

25:18 So they all have slightly different strengths and weaknesses.

25:21 But they should at least typewise, more or less, once they've all implemented the same specs, lead to the same type outcomes, as it were.

25:29 Yeah.

25:30 Okay.

25:31 Cool.

25:31 See, I learned so much about typing just by listening right now.

25:36 Yeah.

25:37 Yeah.

25:38 Well, we're to the end of our normal topics.

25:44 But Luciana, do you have any extras for us?

25:48 Yeah.

25:49 So it was announced in my team that Black is no longer in beta version.

25:56 So version 2020.1.0 has come out.

26:01 So it's their first table for these, I believe.

26:04 So that's very exciting.

26:06 I really like the highlights that they have there that Python 2 is no longer supported.

26:12 Nice.

26:16 So that's a cool announcement for the week.

26:20 And the other one that I have is to remind folks about PyCascades 2022.

26:25 It's happening this weekend.

26:27 It's remote.

26:28 Tickets are on sale.

26:31 So if you're interested in joining the event, it's really awesome.

26:34 It was my first Python conference.

26:35 And the community there is just really amazing.

26:39 So again, remote, join us this weekend.

26:42 PyCascades was your first conference?

26:44 It was.

26:46 Wow.

26:47 Which one?

26:48 It was back in 2019.

26:49 Pretty recent.

26:51 Was that the Portland one?

26:52 It was in Seattle.

26:55 Seattle.

26:56 Okay.

26:58 Yeah, I guess it was the 2021 that was in Portland.

27:00 Right before everything shut down.

27:02 Yes, 2020.

27:03 It was right before it.

27:04 Yeah.

27:05 Yeah.

27:05 Because that was the one I had to miss because I was out of the country on vacation when it happened.

27:10 Yeah.

27:10 Not in China, I hope.

27:14 No, I was in Thailand for a friend's wedding.

27:17 Interesting.

27:18 Nice.

27:18 That was back in the day when we kept track of what countries do have COVID cases, not how many cases in every country.

27:26 So it was a different time.

27:28 Yeah.

27:29 So long ago.

27:30 So I only have like, I guess, one.

27:33 I don't have anything to show for this, but I did a couple extra things.

27:38 I wasn't going to talk about it too much, but I did notice that pip is now at 22, version 22 dot something.

27:46 It's what we're at 22.02 now.

27:49 But one of the neat things about it is there's some cool stuff around having pip vendor.

27:57 There's a couple neat things.

27:59 There's one of their vendor and some of rich.

28:02 So some of the, especially the error output.

28:05 If everything goes great, you probably won't notice much of a difference, except for maybe the progress bar if things are slow.

28:12 But the error report, if something goes wrong, like if it's building something, that's where things apparently show up really neat.

28:21 Some better error outputs.

28:23 And better error outputs are always great.

28:25 Also, interesting that they replaced Tox in their development workflow with Nox.

28:32 And I don't know if that's worth noting or not, but it's interesting nonetheless.

28:37 Yeah, I know Predun, one of the core developers of Pip, is a big Nox fan.

28:43 I'm also a Nox fan.

28:44 So I think part of that's just kind of the difference.

28:48 For those of you who don't know the difference between Tox and Nox other than the letter, Nox is a bit more of a, I would say, general task runner.

28:58 So because you can write just, it's writing just straight Python code.

29:01 So I think for projects that like to use it for like release process stuff, like on the packaging project,

29:08 Predun wrote a Nox file that has like literally a release command that will do everything you need from within Nox.

29:16 So you don't have to have a separate shell script or something else.

29:19 So it can all be in the same file that you also specify how to run your linter and how to run your tests and stuff.

29:24 That's pretty neat.

29:25 One of the things that I've, and I don't remember if there's a way to get around it or not, Tox operates in a virtual environment.

29:34 So it creates, so one of the things, the default behavior at least, creates a virtual environment and then runs whatever you're going to have it do within that virtual environment.

29:46 So like the idea being, you're going to have multiple Python versions.

29:49 So it creates a virtual environment for each Python version that you're running.

29:53 There's some stuff like this extra stuff.

29:56 Like I just want to publish now.

29:57 I'm already like, I'm already in a virtual environment because I'm always in a virtual environment.

30:02 I don't really need Tox to generate another one just to run a command.

30:08 Do you know if that sort of thing is easier in Nox or does Nox also create a virtual environment before it does stuff?

30:15 So Nox can create a virtual environment.

30:20 I can't remember if it does automatically for every command.

30:25 Putting you on the spot.

30:26 Yeah.

30:27 But it's something I'll look up then.

30:29 Ask Thea.

30:30 She can tell you.

30:31 Yeah.

30:31 Yeah, definitely.

30:33 So go ahead.

30:35 Sorry.

30:36 I was going to say that.

30:36 Speaking of pip being updated, I was trying to use it with pip-tools today.

30:41 And it seems that pip-tools is not working with the latest version of pip.

30:45 Just FYI, there's an open issue.

30:46 I'm sure the team's investigating.

30:48 But for all pip-tools users there, you're not alone.

30:52 Yeah, so the problem.

30:54 Yeah, so what so I can.

30:56 Yeah.

30:56 So what happened was is pip-tools is using the private API of pip.

31:01 And it changed.

31:03 And so pip-tools broke.

31:04 So pip-tools, if you use it, you will need to pin to a version pip 2021 or older to work with pip-tools until they figure out what they need to do to use the API.

31:20 The changes that pip made to their internal API.

31:22 And to be fair to the pip-tools team, pip 22 just came out like a handful of days ago.

31:29 So it's really new.

31:31 Yeah.

31:31 I'm a huge fan of pip-tools.

31:33 Definitely love it.

31:35 Well, one other thing actually.

31:40 Yeah, just one other thing on the new pip release for people to be aware of.

31:44 So one thing that happened here is to try to cut down on the vendoring.

31:48 pip stopped vendoring HTML5 lib.

31:52 And now use the HTML parser in the standard library.

31:58 And that actually broke a bunch of simple repo API indexes.

32:06 For those of you who don't know the simple repo API, if you go to any URL in PyPI for a project and replace the project part of the URL with simple, you'll see what I'm talking about.

32:16 But basically, there's a spec that just says there's a PEP that says, hey, write this HTML.

32:23 And then packaging installers can read it and figure out where to find all the files and the projects for something.

32:30 It turns out a lot of people weren't following the spec.

32:33 And so a lot of these indexes broke because pip wasn't able to read them anymore because it couldn't be parsed as pure HTML.

32:45 They were doing funky things that broke.

32:49 So they, I believe, either have or are planning to roll it back with a flag to let you alternatively use HTML5 lib for now with the goal of getting all these projects that have broken output.

33:02 They don't follow the spec to fix themselves so that they can go back to not having HTML5 lib in the box.

33:08 So just a heads up, if you use an alternative package index and it suddenly broke, that's why they're working on a fix.

33:16 But I would talk to the project that creates that index for you and have them work on making sure that that project creates valid HTML5 that can be parsed by the HTML parser in the standard library.

33:28 So that going, because that'll probably go away in pip 23.

33:33 But it's not broken now, right?

33:37 It's just, it's flagged.

33:38 It was broken.

33:40 They didn't realize how much of the world was doing invalid HTML for these indexes.

33:44 So I don't know if it's in 22.0.2 or if it's going to be in the next release.

33:49 But there is an open issue where they're, where I at least was looking at where they were fixing it.

33:54 Because I got looped in because I have one of my side projects, Mouse Bender, that actually wrote some code around this originally.

34:02 There's talk about moving up to packaging.

34:04 A lot of behind the scenes stuff that people don't need to care about.

34:08 I hope that, yeah.

34:10 No, go ahead.

34:11 Well, I was just going to say, so the plan is, I think, is to add a flag to say, use old HTML parser or something along those lines for now.

34:18 So you can say, hey, use the HTML5 lib version of parsing HTML.

34:23 But it's just, just to be clear here, there will be a fix, but it's a temporary fix.

34:28 Because people should be getting after their projects that create these indexes to do the right thing and actually follow the standard.

34:33 Okay.

34:34 So as someone that got bit by this, because we have an internal PyPI caching server that also we store our own stuff on.

34:44 And we don't own it.

34:46 We like, it's a third party thing that we're licensed.

34:49 So I don't know how long it's going to be.

34:52 So hopefully that, hopefully they move quickly.

34:54 But at the same time, hopefully this extra use the old one flag or whatever will work for a while.

35:01 I was a little surprised when I saw the warning pop up of like, oh, you're not using a good, you know, it's invalid HTML.

35:07 And I'm like, what am I supposed to do about it?

35:09 Well, and I don't think the bit developers were expecting it to be so widely broken either.

35:17 Right.

35:17 It's like, what are these projects doing that are creating invalid HTML?

35:22 But apparently.

35:23 I did it all the time though.

35:25 Like, okay.

35:26 But it's fair.

35:27 It works.

35:28 If it works, it works.

35:29 It's HTML.

35:29 Yeah.

35:30 Well, and that was the problem, right?

35:31 Is the spec very, the PEP that defines it very specifically says it must be valid HTML5.

35:38 And I think it was specifically so that it could be parsed by the standard library.

35:41 So it also means none of these pages could even have been parsed by the standard library.

35:44 So I think that's what happened, right?

35:46 Is people, because people, because pip had been using HTML5 lib, which is obviously way

35:51 more lax in terms of what it can parse.

35:54 Everyone just like, oh, okay, it's good enough.

35:56 And didn't realize that the spec specifically mandated valid HTML5.

36:00 And so hopefully all these projects that got caught up can get a fix out over the next year.

36:05 Because as I said, I suspect this will be in until pip 20, pip 23, which will come out

36:10 in 2023.

36:11 So it's not like it's going to disappear in a month, this flag.

36:14 So I'll let the fix out, but hopefully everyone can kind of get caught up so that they can

36:18 get back to not vendoring HTML5.

36:21 Okay.

36:22 Before we go jump to a joke, I want one last extra is for the first time in like 18, 20 months,

36:31 I'm not writing a book.

36:36 I'm no longer writing this book.

36:37 The writing is done.

36:39 The editing is done.

36:40 So it's off to all the rest of the cogs that have to go through the process to get it.

36:46 But the ebook right now is really solid.

36:48 So anybody that grabs the ebook now, if you've grabbed it before, it's all the updates are there.

36:53 But this has got all the copy edit changes and the final edits, the rest of its layout and

36:58 stuff to try to get the physical book form.

37:00 So that's coming out sometime this month, maybe, hopefully.

37:04 So that's my hope is by the end of February, I'll have a physical copy in my hands.

37:09 Well, congratulations.

37:11 Everyone who listens to this podcast and testing code and anywhere else for you have known you

37:17 put a lot of blood, sweat, tears and love into that book.

37:20 So congratulations for reaching this book.

37:21 I just was realizing that my youngest daughter is 12.

37:25 I spent a year and a half on this book, a year and a half on the first edition.

37:28 So I've been writing about pytest in book form for a quarter of her life.

37:33 It's pretty weird.

37:36 Are you ready for a joke?

37:39 Thank you for your work, Brian.

37:40 I'm going to be ready to physical copy, hopefully.

37:43 So one of the goals of the second edition was to try to put it in a format that would be easy

37:48 to teach, easier to teach and learn.

37:51 So I'm the next step is I'm going to work on trying to teach people in person, teach people

37:56 in person and through video courses and stuff like that.

37:59 Turn this into because I know a lot of people don't read.

38:01 But you're coders.

38:03 Why don't you read?

38:04 You have to read your code.

38:05 But still, some people don't read books.

38:07 How about something funny?

38:09 Yes.

38:10 Today's joke brought to you by Luciana.

38:13 Thank you for finding something funny.

38:14 And we'll add this to the thing.

38:19 So I love this.

38:20 So for people listening, there's a picture of an ocean and you've got a really big ship.

38:28 It's called.

38:29 I don't know what's on the ship.

38:30 It's a big ship.

38:31 I don't know.

38:33 I don't know.

38:34 But it says, but it looks all official like and everything.

38:37 It says proper software design.

38:39 And then there's a guy on a surfboard standing up.

38:44 So it's like a wakeboard thing.

38:46 And he's holding an umbrella, getting pulled by an umbrella on a surfboard and says, whatever

38:50 I'm doing.

38:51 So it's funny.

38:55 That's how I feel whenever I'm coding.

38:57 And sometimes it feels like this going from the old days of like these huge design documents

39:06 to now.

39:08 Oh, we're doing agile.

39:08 So let's just write some ideas on some post-it notes and stick them on board and run from

39:13 it with there.

39:14 So anyway.

39:16 If it works, it works, right?

39:17 Yeah.

39:19 It's got tests, right?

39:20 Well, I think so.

39:23 It's unit tested.

39:24 It's 100% coverage.

39:25 It's good.

39:25 Let's ship it.

39:26 Perfect.

39:27 Perfect.

39:29 Nice.

39:30 Well, first of all, thank you, Luciana, for joining the show.

39:34 I think it's your first time, right?

39:35 Yes, it was.

39:37 My first podcast.

39:38 Awesome.

39:39 Participation.

39:39 Thank you for having me.

39:41 And thanks, Brett, for joining last minute.

39:45 Yeah, thanks, Brett.

39:46 It's always good to see you.

39:47 I'm happy to play the fake Michael for this episode.

39:49 Thanks, everybody, on the stream for showing up.

39:53 And we'll see you all next week.

39:56 Thanks for listening to Python Bytes.

39:58 Follow the show on Twitter via at Python Bytes.

40:01 That's Python Bytes as in B-Y-T-E-S.

40:04 Get the full show notes over at pythonbytes.fm.

40:07 If you have a news item we should cover, just visit pythonbytes.fm and click Submit in the

40:14 nav bar.

40:14 We're always on the lookout for sharing something cool.

40:16 If you want to join us for the live recording, just visit the website and click Livestream

40:21 to get notified of when our next episode goes live.

40:24 That's usually happening at noon Pacific on Wednesdays on YouTube.

40:27 This is Brian Okken.

40:29 On behalf of myself and Michael Kennedy, thank you for listening and sharing this podcast

40:33 with your friends and colleagues.