#406: Reimagining Python's Packaging Workflows Transcript

00:00 The great power of Python is it's over 400,000 packages on PyPI to serve as building blocks for your app.

00:06 How do you get those needed packages on your dev machine and manage them within your project?

00:11 What about production and QA servers?

00:13 I don't even know where to start if you're shipping built software to non-developer end users.

00:19 There are many variations on how this works today, and where we should go from here has been a hot topic of discussion.

00:25 So today, that's the topic of Talk Python.

00:27 I have a great panel of guests, Steve Dower, Pradyun Gedam, Ofek Lev, and Paul Moore.

00:34 This is Talk Python to Me, episode 406, recorded February 21st, 2023.

00:39 Welcome to Talk Python to Me, a weekly podcast on Python.

00:55 This is your host, Michael Kennedy.

00:57 Follow me on Mastodon, where I'm @mkennedy, and follow the podcast using @talkpython, both on fosstodon.org.

01:04 Be careful with impersonating accounts on other instances, there are many.

01:08 Keep up with the show and listen to over seven years of past episodes at talkpython.fm.

01:14 We've started streaming most of our episodes live on YouTube.

01:17 Subscribe to our YouTube channel over at talkpython.fm/youtube to get notified about upcoming shows and be part of that episode.

01:24 - This episode is brought to you by Cox Automotive.

01:28 Use your technical skills to transform the way the world buys, sells, and owns cars at talkpython.fm/cox and by Sentry.

01:36 Don't let those errors go unnoticed.

01:38 Use Sentry.

01:39 Get started at talkpython.fm/sentry.

01:42 Steve, Paul, Ofek, and Pradyan, welcome all to Talk Python to Me.

01:47 Happy to have you here.

01:48 - Thanks for having us.

01:49 - Yeah, you bet.

01:50 New for some of you, welcome back for some others.

01:52 So either way, it's still great.

01:54 Let's just go around the video square here and have you all just do a quick introduction.

02:00 I know, like I said, some of you have been here before, but it may have been a while.

02:02 So Steve, you wanna kick us off?

02:04 - My name's Steve Dower, Zooba on Twitter and GitHub in various places, and CPython core developer, and I actually got involved in Python in the first place to help with packaging.

02:13 And while I'm not kind of officially closely involved with packaging as much now, I still help contribute.

02:19 - Yeah, awesome.

02:20 And you're also pretty notable for helping step up Python's game on Windows.

02:25 Yeah.

02:25 Along with some of the others in this panel, actually, we've got a few, few of the Windows contributors here, but yeah, that's, that's kind of my focus area.

02:33 Yeah.

02:33 Awesome.

02:33 Paul, welcome.

02:34 Happy to have you here.

02:35 Hi, nice to be here.

02:37 I'd say I'm Paul.

02:38 I'm a core Python developer and a pip maintainer.

02:41 Two things I'm most involved in.

02:44 I'm also for my sins, the PEP delegate for packaging standards, if you like.

02:51 So basically anything that's a pip around interoperability between packaging tools comes to me ultimately for the decision on how it's going.

03:03 I've been around in packaging for years now, so got quite a lot of the history behind me, which is also useful in this type of discussion.

03:10 Yeah, absolutely. Very much involved with pip.

03:13 And that's at the heart of this, right? That's probably the earliest tool there.

03:18 - The vunerable one. - Ofek

03:20 - Yeah, welcome. - Hey, yeah.

03:21 I'm the primary maintainer of Hatch, which has been around for a few years, but more recently I rewrote it from scratch to better satisfy kind of what I wanted and what more users wanted the UX to look like.

03:36 It comes with a build backend Hatchling too, that is also a bit new.

03:41 So yeah, my primary focus is the user experience, making things as easy and less prone to errors as possible with perspective and shape and stuff like that.

03:52 Excellent. Yeah, so Hatch is in the general category of these higher level tools that work on top of the lower level Python ones to provide more consistent workflows for doing things.

04:03 And that's kind of the heart of this discussion, honestly, is like, what should those workflows be?

04:08 What tools should be responsible for it? And so on.

04:11 We're not quite there yet, because Pradyun still has to introduce himself.

04:14 - Indeed. Hi, I'm Pradyun.

04:16 I am a maintainer on Pip, Flit, and a few more Python packaging stuff.

04:22 I'm also the maintainer of Domo, as well as, well, I guess I'm the new CPython co-developer, as of, so yeah, that's me.

04:31 - Yeah, welcome. You're doing a lot of cool stuff.

04:33 So we're all here together because, let me pull this up my screen really quick, Because of this discussion over on discuss.python.org, it's multi-part, which is notable for how long just a part of it is, Python packaging strategy discussion.

04:52 And part one, if you scroll down just a little bit, it says that there are 272 replies and 150 minutes of reading time.

04:59 And that's before we get to the related blogs, the GitHub issues, part two, the survey results, all of these things.

05:07 So this is quite a discussion and a lot of people seem to care a lot about it.

05:12 I don't think you've brought your screen up that for us, Michael.

05:13 Oh, I have not.

05:14 Have I?

05:14 There we go.

05:15 Thank you.

05:15 Yeah.

05:16 So let's start the discussion with maybe a summary of what's going on here.

05:21 This was posted by Shemika who unfortunately couldn't be here today, was going to be here, but can't make it.

05:26 So I'm going to have to let whoever feels most qualified to jump in on this.

05:30 Who wants to sort of set the stage for what this discussion was about?

05:34 Paul, you look like you might be willing to fight.

05:35 Paul looked like everybody else was backing off.

05:40 Yeah, one of the things that we've wanted to do for some time now is sort of get a better feel for how the user community views packaging.

05:53 Shameka joined the packaging community as the project manager for the packaging effort as a whole.

06:00 And one of the things she initiated in that was getting a survey done to effectively try and answer those questions.

06:09 What do the users think of the packaging ecosystem?

06:13 What do they think of how things are going?

06:15 What do they want from Python packaging?

06:17 There was a fair bit, there was a, I don't honestly know how big the response was, but it was quite, we got quite a decent response from it, which basically got summarized up in a couple of feedback documents.

06:30 Yeah, I think here we go. There's a PDF that I'll link to that has the actual survey responses.

06:37 Yeah, and it turns out that putting a banner on PyPI.org seems to be the winner in terms of reaching out to people who care.

06:44 We have almost 8.7k responses and 7.9k out of those are from PyPI. So that's more than 90%.

06:53 Yeah, absolutely.

06:54 Basically from that, the discussions on Python discourse are following on from that, taking a number of the messages that came out of the survey and essentially getting everybody in the packaging community together to talk about, you know, what does this mean? What do we expect we can do about this?

07:16 How do we address the comments that have been made? Where do we take it?

07:21 There are a number of discussions planned. I don't know how many.

07:27 The first one, Pradyum's either waving at me or suggesting it's five.

07:32 The first one is the one that we've had already, the sort of main strategy.

07:39 There are a number of follow-ups to that, one of which has just started, but most of which haven't taken place yet.

07:45 So where we're at now, the initial discussion, which was the thread that you showed previously, that went on for about a month on discourse, generated quite a lot of discussion, and we now need to sort of digest that and understand where that leaves us and what actions we can take from it, what conclusions we can draw, how we pull that together into something that we can actually do something with, I guess.

08:13 Yeah, and I think it's worth adding that this is not kind of an unusual thing for our packaging participants. We have quite a significant history of a few comments kicking off a huge discussion that flows and fragments and drags on for hundreds of posts. And this one actually feels a bit different. This one feels like there's a real sort of commitment from certainly some of the main players who are involved in it. If you look at the regular posters in that other thread, then you'll see a lot of us up near the top, but there's also a a number of other people involved who are, it feels more serious this time. It feels like we really not just feeling or recognizing pain that we've always kind of seen and known is out there for a lot of people using it, but it feels like we're kind of at a place where something has to give. And I feel like we're getting closer and closer to being able to change whatever it is that needs to change to make that give. So I think it's an exciting set of discussions, Though it is long and meandering and drawn out and occasionally a little frustrating.

09:14 I've taken a few breaks during it just to cool off and I suspect some of the others in here have as well. But a lot of it's nothing new. It's nothing that we haven't heard or come across before. Having it laid out the way the survey did gave us a real kind of strong starting point.

09:31 And there's just a lot of, honestly, discussion, a lot of things that have to be talked through because we're all different people with different backgrounds, different areas, and trying to get aligned well enough to then align the random group of volunteers who make up this group. It's like we jokingly call it a packaging authority, but that's the biggest joke in the world. And so to actually align the volunteers working on independent projects takes a huge, you know, we've got to build up that momentum and that alignment before we can can even start changing projects.

10:04 Yeah, there it is.

10:05 - There's a couple of levels of this, right?

10:07 I mean, as a broad Python community, we gotta get enough alignment that people will back it.

10:12 But there's a bunch of people who would have to build whatever variant of this you all might pick, and you gotta agree on that as well.

10:20 And many of them are working on different tools.

10:23 Pradyun mentioned Flit and Pip, Ofec is Hatch and Hatchling, Paul is Pip.

10:28 Like, in some sense, the discussion might be, well, should pip take on the responsibilities of Flit or should it do less and Hatch takes on, you know, there's this give and take, which I think is gonna be an interesting thing to see play out.

10:43 We've had a thousand flowers bloom sort of moment, I think, with the packaging, we've seen a bunch of different tools come along, but that's also led to, I think, confusion with people are like, well, one blog post said use poetry, now this one says use Hatch.

10:57 This other one said, don't use any of them.

10:59 What do I do?

10:59 I'm new, I'm confused.

11:00 - Yeah, well, before we move on, just sort of summarizing your thoughts of this overall discussion, just kicking it off, you know, Ofec and Pradyun, you haven't got a chance to weigh in.

11:09 Ofec, what do you think?

11:10 - Yeah, I will say, although the main sentiment about the takeaway from the survey was that people wanted more unification and sort of guidance, I think the threat itself was not as much about that, but just like a myriad of issues.

11:26 So only one of the issues was actually about tools like user experience, other people brought up other long standing issues, like we want more integration with conda. That's a large topic there. Some other people want better support for extension modules and detection of like GPU, stuff like that. So there's lots of needs from various communities that also have to be worked out. It's not all just about the user experience and things like that. Sure. That makes sense.

11:59 Regan, you wrote a huge, great long blog post on this, which we're going to get to a little bit, but you know, higher level first.

12:05 It's been productive.

12:06 There, one of the things that Steve gave me the word for is level setting.

12:12 There's a lot of sort of bringing everyone to context on or bringing up to the same amount of information and sort of understanding other use cases that you don't have yourself, even though you're right, that supports that and things like that.

12:27 Having all of this discussion happen has helped bring everyone up to the same page on these things.

12:33 One thing I want to push back on, like Steve just said, which is that if the Python packaging authority does not have authority, is probably not true.

12:42 We do have Will here, who gets the authority to decide on things directly delegated from the steering council.

12:49 I heard the cats. That's about as far as it goes.

12:52 There is a level of authority involved, but it's limited because we'll get on to the structure of the PYPA, I guess.

13:02 But there's a lot of independent projects, a lot of independent people, and one of the things that this discussion did was bring everybody together and get us interacting maybe more than we had done.

13:15 I think historically, it's probably worth also saying that historically, packaging started off very much one or two tools that did everything, things like disk utils and setup tools.

13:26 They were it.

13:27 And there were all sorts of issues at that time, which meant that we consciously tried to take a view that we were going to enable diversity, allow other tools to get into the mix.

13:42 We started by looking at how we could make alternatives to set up tools work, how we could give people choice there. And from there, it's grown. And we've now got choice in a lot of areas that we never used to have choice in.

13:54 That wasn't an accident. That was a conscious decision that we made to try to give some level of competition, some level of innovation that hadn't been there beforehand.

14:05 One of the things that this discussion has done, well one of the things the survey did, has brought home to us the downside of that is that everybody's confused as heck.

14:15 That nobody knows what to do now because we've just given them a hundred million choices.

14:19 And that's a very fair comment.

14:21 It wasn't the intention, but it was an obvious consequence of that diversity that we promoted.

14:28 Now what we need to do and what we're trying to do on the back of the discussion on the back of what we've learned is trying to pull that back together again we've got all these tools now we want to try and if not exactly unified them what's the league give a clear picture of this is how you do things story I'm part of the problem with that one of the things that getting everybody talking has done it's made it clear that we do need to work together we can't keep competing because the users of the tools i just lost knowing what to do so we need to bring things together but nobody is Certainly i don't think this point anybody is saying that we're gonna shut down all the other tools all the people working on them wasted the time that's not the idea at all but we still need to navigate how we get more unified approach within the context of we got which is a lot of people working on their own vision of how they are serving a subset of the overall group of users like steve said i think it's been really useful getting everybody together and everybody getting each other's perspectives we now need to work out what to do with that.

15:39 This portion of talk python me is brought to you by Cox automotive.

15:45 Cox Automotive isn't a car company.

15:47 It's a technology company that's transforming the automotive industry.

15:52 The team at Cox Automotive understands the future of car buying and ownership, and they're looking for software developers, data engineers, scrum masters, and other experts to help make that happen.

16:03 If you're interested in innovating with brands like Kelly Blue Book, Auto Traders, and others, then you should check out Cox Automotive.

16:11 Just visit talkpython.fm/cox to find out more.

16:15 Thank you to Cox Automotive for sponsoring the show.

16:19 One thing that stood out to me from reading the survey, and we can poke through some of the interesting questions and responses there.

16:27 I feel like there's two users that almost need two approaches.

16:31 There are people who are creating libraries and shipping them to PyPI, and they're core Python developer folks, not core developers, but you know, they live in breathe Python and they build Python things and, you know, stuff like Pydantic or FastAPI and so on, they might need the flexibility and the diversity.

16:52 Sarah, the new grad student in the biology department that needs to get pandas to work and she knows that Python is her path forward.

17:00 She shouldn't have to decide whether to use flit or hatch or straight pip plus maybe pip tools.

17:06 And right.

17:06 These are two very different use cases.

17:09 and almost like bringing them together to, well, what's the best of those two solutions together seems almost maybe the wrong, you might make both groups unhappy going down that path.

17:18 - And I think if we bring together the current 8,000 tools, it's gonna make 7,999 groups unhappy.

17:25 I mean, this is part of the challenge.

17:27 Though I think an interesting thing there, and probably about halfway through this mega thread, it kind of clicked, at least for me, I think some people had mentioned it earlier, that there's really two big categories of tools.

17:39 Kind of, as you say, there's the tools for packaging and the tools for using packages, which includes what seems to be the biggest issue is the environment managers.

17:48 It's the virtual environment creation, which is kind of half of poetry, it's, but not the other half, a big part of Hatch, but not the other half.

17:58 It's none of Flit.

17:59 It's none of setup tools.

18:01 It's like, those are purely about building packages.

18:03 And it's on this side, the building packages, where we've invested in kind of creating and driving that diversity.

18:10 And I think that's worked really well.

18:12 We've got a range of standards that make them interoperable at the right places so that pip can take kind of any of these backends and trigger them correctly.

18:22 Source code written to provide metadata for any of these backends can be easily transferred between a lot of them.

18:29 That seems to mostly work.

18:31 And it's a situation where, again, as you say, that the deep in Python maintainers have a choice in what backend they want to use.

18:37 And what kind of clicked is people were saying, you know, we want less diversity. And a lot of us were going, well, the diversity is in the backend. So if you want less than we have to combine the backends. But I think what clicked is that no, that's not what they're wanting, because it is the new newcomer to Python who just wants it to work, who's trying to choose between all of these environment managers. And especially when you throw condor in there as well, which is just so fundamentally different in how it behaves from the ones that kind of rely on PyPI directly, that we already have that divide.

19:09 And the diversity has shown up on this side uncontrolled.

19:13 We didn't set out to see Poetry created or see Pipenv created or any of these, but it's there.

19:20 And how do we rein in something that has grown up all by itself, completely outside of anything that we've ever tried to control?

19:26 One thing that struck me in that discussion was I'm really quite happy with a lot of the, like Steve says, the backend tools, all that sort of stuff.

19:36 But it occurred to me that when I'm just writing little hobby programs and things like that for myself, I'm with everybody else.

19:44 Packaging is horrible.

19:45 I just want to say, "Start a project, start up a notebook, do something." And it's really hard.

19:53 It hadn't occurred to me until we had this discussion that that's very much the two sides of the user equation.

20:01 We've really not put as much effort into the "just wants to use Python to do their job" side of the user base than we should, and tools like Hatch and PDM is another one, Poetry is another one, they are addressing that.

20:17 And I actually went off and started exploring them.

20:20 I thought, "Hey, there's cool stuff going on here that I really wasn't as conscious of as I could have been.

20:25 So, yeah, absolutely.

20:27 We need to look at that side as well now, I think.

20:30 I agree.

20:30 They told me you we're talking about is like libraries versus applications.

20:35 So as people have mentioned, it is very easy now to build the library and test it.

20:40 And that's due in large part to the standards that we made to allow diversity for the build back end.

20:46 So that's very good.

20:48 But yeah, it's where the applications are.

20:50 That's like the hard part now.

20:52 And I think at least one of the missing features that I think we should devote resources to, and I know Brett isn't here, but lock files is something that we desperately need.

21:04 And Poetry has their own implementation of lock files and dependency resolution, so does PDM, but there's nothing like standard for that.

21:14 And that should be the next step, I think, for applications.

21:18 While we're talking about the future and sort of where we are, I will point out, part of the reason we're seeing a bunch of this is because we've solved some of the harder problems already.

21:27 We are at a point where, "Oh, I'm having difficulties installing Pandas and figuring out what to work for for that." And not, "I can't install Pandas." That's a good point.

21:36 Or, "I can't publish Pandas," or whatever.

21:39 So we have been solving the problems as we go.

21:42 It's just, we're going to keep seeing more and more problems, especially in a user base this large.

21:46 there's always going to be more interesting and really difficult problems to solve.

21:50 I think a lot of the people who are now just trying to get on with using Python for their day job, probably when we were starting the process of moving away from setup tools, they didn't even exist. Python wasn't that popular in those days.

22:06 There's a new set of users who are coming along with a new set of problems.

22:11 And if we don't keep our eye on what people are trying to do with Python, we'll get left behind, I guess. We won't be relevant. They won't have any solutions for what they're trying to do.

22:23 And a lot of them came in because they believed Python was easy, because we've got a reputation for being easy. They wouldn't be frustrated if they thought it was going to be impossible and then found out that it's impossible. They wouldn't be frustrated. They wouldn't be happy, but they'd be satisfied. It's because they've come in expecting this great experience that everyone's talking about, and we're just not able to deliver it in enough cases that the and frustration comes in.

22:46 And we get that.

22:47 We all get hit by it as well.

22:49 I am quite optimistic about it, though.

22:52 I think one person brought up a good point in one of the recent discourse threads that despite the hardships with packaging and everything we are discussing here, Python has gained massively in popularity and usage despite all these obstacles.

23:08 So, yeah, I'm pretty optimistic that we can satisfy people's needs.

23:12 Yeah, I'm too. I think there's, I think Pradyum didn't really hit on it. I remember long ago that certain things wouldn't install, sorry, you couldn't get this to compile or this other thing wouldn't work right.

23:23 It hadn't really occurred to me explicitly, but I haven't seen those errors for a real long time.

23:27 Yeah, and there's a lot of work that's gone into build backends to make that possible.

23:32 Certainly for Linux users, the huge amount of effort that went into defining the mini Linux standard, where which is kind of the base layout of system libraries and where they're expected to be on a system so that people can build a binary package for Linux that can assume that those libraries are there and distribute those has meant that yeah, a lot of the time when you go to install something you'll get already built, already compiled packages that are just ready to go.

23:59 And kind of the problem that that's raised up is we've taken the really obvious problem of you don't have a compiled package yet, up to the point where you have a compiled package that is subtly incompatible with some other compiled package, which can be really subtle because it can be one of those 99% of the times it works fine, and then the other time it just segfaults and everything dies. Or it may be subtle data corruption, like there's a million little things that can subtly go wrong there, and we're starting to see some of those come up. Certainly, the people in the data science side of things saw them come up quicker because they use a lot more of these these complex packages and they do interact with each other and they do check things like numerical stability.

24:40 A lot of the rest of us don't worry about that kind of stuff most of the time.

24:43 And so like, yeah, this works.

24:45 This works, put it out there.

24:46 Maybe if wheel existed before conda, people would have just pushed harder on wheel potentially and conda might not exist.

24:53 Not saying it shouldn't exist, but that might, it might not have been a bad enough problem to make it exist.

24:57 I agree, like conda came into existence because the solutions that were there weren't able to satisfy it.

25:03 And it was so far, like just the distance from where we were at that point, because at that point, it was like eggs.

25:09 Probably no one watching even remembers eggs.

25:11 I'm sure Paul does.

25:12 At that point, it was effect.

25:14 May as well.

25:15 I'm not sure how long you've been involved, mate.

25:17 But yeah, it was like it was a very different world.

25:19 And the distance to get there just looks so impossible.

25:21 But yeah, if we'd been at wheels, then they may have said, well, this little tweak to wheels will make it work for us.

25:27 And who knows where we might have been then?

25:29 It's quite possible.

25:30 I can't judge honestly, but it's quite possible that Conda is where wheels will be in a number of years.

25:38 I think there are fundamental reasons why that might not be the case, and we may have to find different ways of dealing with the problems.

25:46 But yeah, these sort of really difficult, really basically not solved technical problems.

25:53 It's not that Python is struggling with something that's easy.

25:57 there are no languages or environments anywhere that have really solved these problems.

26:04 So we're trying to find solutions as we go along.

26:07 And I think in spite of what Steve is saying, I think having an 80-90% solution often is plenty good enough.

26:16 I don't want to say that we should abandon the users who really need that, because they are on the forefront of things like AI research and data science, and they're doing incredible work, which they can't do if Python falls apart on them.

26:30 But at the same time, I think we're now in a position where we have to balance the general solution with the specialist solution and try and understand that.

26:38 And for a lot of us, certainly for me, that's quite new.

26:41 I'm not entirely comfortable yet with the idea of saying, "We need a different solution for this than we have for that." It's something we're all getting to grips with, I think.

26:50 One aspect of this is also sort of kind of related to the Conda and Python success aspects of this is Python is a famously glue language. So when you're trying to package or use Python, you're not just using Python, you're using a whole stack of other languages and text stacks along with it. Photography uses rocks under the hood. And there's Fortran code in NumPy.

27:17 there's all sorts of diverse tooling underneath what just looks like a Python package.

27:24 And that works. And you are able to use things. And it also introduces all the challenges that come with all of those themselves. So, it's... we're in a good spot. There's also a long way ahead. But we're also quite a ways from where we were. And I think one of the things to bring it around that the strategy discussion is doing is helping us understand where the gaps are right now and what the most painful points are right now, which is where the user survey was really helpful in telling us these are the things that at least the users that we follow and who did fill the survey think the problem and the end point are.

28:07 I would say, just quick estimate looking at the source of the respondents from the survey that even this, these results lean more towards the highly committed software developer side and data science side of Python and not the super casual user because there's a huge bias.

28:26 Yeah.

28:26 My, my example of Sarah in the biology department, she's not going to PyPI and going through surveys.

28:32 She might see the banner, which is, ah, whatever I got, I care about biology or I care about economics.

28:36 Right.

28:37 So I think even this should be taken with a bit of a, a bit of a bias.

28:41 I think one of the useful pieces of data that we did collect was user experience, like experience level.

28:47 One of the things I've wanted to do but not done is sort of split this survey data that we have across various axes and see if we see other pieces of this currency here.

28:57 I don't think any of the people who have acted in this space have had the time to enter the data.

29:05 I for one don't have the expertise or skills to do so.

29:09 So like one of the things that's really useful is having people look through the statement and come up with new insights and flag things, which is one of the trigger moments.

29:19 That's very much a common problem we have is so many people use Python who we just have no way of getting in touch with.

29:28 We have no way of knowing what their experience is because why would they talk to us?

29:34 It's like you don't go and talk to the engineers who design your car. You just drive the flipping thing and There's an awful lot of people who treat Python like that and we can ask we can put surveys up But at the end of the day like you say the sort of people who would really really like to get feedback from Simply don't look at these sort of things. They they aren't involved in going on to pypi you know, they type pip install something that the guy across the desk from them told them would work, and they never see PyPI. In my workplace, I was very conscious that we had some people who were dabbling in Python who didn't interact at all with the community, never even contemplated doing so.

30:19 And that's with me sitting next to them and saying, "Hey, Python's cool." And that's the norm. That's the actual Python user.

30:26 Anyone who's looking at a survey and responding to it is already in the top 5%.

30:32 This portion of Talk Python to Me is brought to you by Sentry.

30:38 How would you like to remove a little stress from your life?

30:41 Do you worry that users may be encountering errors, slowdowns, or crashes with your app right now?

30:47 Would you even know it until they sent you that support email?

30:50 How much better would it be to have the error or performance details immediately sent to you, including the call stack and values of local variables and the active user recorded in the report? With Sentry, this is not only possible, it's simple. In fact, we use Sentry on all the Talk Python web properties. We've actually fixed a bug triggered by a user and had the upgrade ready to roll out as we got the support email. That was a great email to write back. Hey, we We already saw your error and have already rolled out the fix.

31:19 Imagine their surprise.

31:21 Surprise and delight your users.

31:23 Create your Sentry account at talkpython.fm/sentry and if you sign up with the code talkpython, all one word, it's good for two free months of Sentry's business plan, which will give you up to 20 times as many monthly events as well as other features.

31:39 Create better software, delight your users, and support the podcast.

31:43 at talkpython.fm/sentry and use the coupon code talkpython.

31:48 There's a really interesting term that Scott Hanselman came up with called the dark matter developer. The unseen 99%.

31:59 And it's exactly what you're describing here, Paul, is you can't reach them because they don't come to the meetups, they don't come to the conferences, they don't subscribe to the blog.

32:08 They just use it as a tool and go home.

32:10 And they shouldn't. They don't, you know, it's not what they're doing.

32:13 Some of the best feedback that we do get in these discussions comes from, as well as kind of people who get actual issues reported to them.

32:21 So every time the pip maintainers are like, people are reporting this problem all the time.

32:25 Okay, we know that's a problem because it's getting to the developers.

32:28 But we also get feedback from people who do training and tutorials and people who kind of manage Python's presence in a workplace and in an organization, because in that position, and that's kind of the position that I do as well at my work, we get more of that feedback.

32:42 We get people complaining about things that they'd never think to take out in public, but they'll happily put on an internal list somewhere saying, "Hey, how come Python can't do this?" Right?

32:51 Or they'll ask for help because they actually have a job to do and they need to get it done.

32:55 And, you know, we're all getting paid to be there.

32:58 So there's no kind of fear or shame in saying, "Hey, can someone just tell me how to do this?" And so by being kind of that central point in that place, just the same as when you're teaching a class, students are going to say, "This didn't work." And now you see a problem. And when you start seeing the same things over and over again, that becomes kind of useful additional feedback to factor into these kind of surveys. And I don't think we've put a lot of weight in kind of the quantitative response here. Like it's quotes, it's stuff that people have put in the open spaces that, you know, the ones that have really resonated or been repeated a lot are the ones that we've pulled out into the discussion and have been working from. And kind of the actual numbers, it's like, yeah, they could mean anything Realistically. And we can slice them to make them mean whatever we want.

33:41 Exactly. So there's a careful balance there of drawing the right insights from this, knowing the limitations of what we've done, as is probably the case with every single way.

33:52 Let me read out some of the, oh, sorry, go ahead, Nofeq, and then I'll read off some of the comments that actually some of the respondents actually made. But go ahead.

33:59 Oh, yeah, no, I was going to say, I agree with Steve that I think since we have no access to to these 99% of actual developers.

34:08 I think what maps closest to them would be users and industry.

34:12 I got companies building applications.

34:15 Because if you're a user of Python, like kind of by definition, you're writing an app and not really building a library.

34:21 So I think that if we hear feedback from people at companies trying to build apps, facing hardships, I think that would reflect the main chunk of users.

34:33 - That is a good point.

34:34 I made the distinction that was almost like beginner versus expert, but really, I guess how I should have phrased it is close to what you said, Oveck, is people building applications and presentation type things that they never will share with anybody through PyPI or something.

34:50 They just want to get it to run.

34:51 Maybe they'll deploy it, but they won't publish it.

34:54 Versus people building Flask and Pydantic and SQLAlchemy.

34:58 And so these are really different use cases.

35:01 So the person building that may be extremely talented and experienced, but they also have different constraints and different goals.

35:07 So that's a really good point.

35:08 All right.

35:08 So I'm quick respondent thoughts here, just from this discussion thread.

35:13 So one person says unify multiple tools.

35:16 It's good to have new ideas and new implementation, but it has to converge after a while.

35:20 That's pretty interesting.

35:21 Number two, there should be one and preferably only one obvious way to do it.

35:26 Get rid of the fragmentation straight out of a Zen and Python there.

35:30 Number three, I definitely want Python to introduce the one true packaging tool, ideally both as easy as Rust's cargo and as an extensible package installing as easy package building as the wild west.

35:43 So that kind of speaks to the, potentially the other side of creating in the libraries and then person four, it said, blow it all away.

35:49 Just everything goes away.

35:51 Start over from scratch.

35:53 Paul, you, you had actually a comment here in this discussion about the historical perspective.

35:59 I think I even potentially pulled it up here, saying, you know, this, having pip be exactly this tool might be really hard because pip has been built to do certain things and people now rely on it, right?

36:11 pip is in a very odd position here. It is, it's shipped with Python, and it's shipped with Python for a very specific reason. You've got to have something to start the whole process off. You've got to be able to bootstrap.

36:25 And if you use Hatch, how do you get Hatch on your PC?

36:28 You need something. And pip was incorporated into the Python.

36:32 It's not technically part of the standard library. It's installed with the standard library.

36:37 But let's not go there. But it was incorporated to give us that bootstrapping capability.

36:43 At the time, that's really all pip was, was an installer.

36:48 It had build capabilities because you needed to build things from source, because that's how you installed a lot of things.

36:55 All right, predated wheels and all that, yeah.

36:56 Yeah, wheels were nowhere near as common at the time.

37:00 Since then, things have changed, but pip is still the one thing that, it's where people get into the whole packaging ecosystem.

37:08 They have to start by saying pip install.

37:11 And there's a very good point which was made, I mean, this is January, my opinions change every 15 minutes, so that was a long time ago now.

37:20 But there was a good point made, which is that pip is in the position to be that unified tool, but it's not what it is now. Other tools like Hatch or PDM or Poetry are better at being the workflow tool that people talk about when they make analogies with Rust and Cargo, for example.

37:41 But they don't come with Python. And to balance that problem out and come up with a solution there, we can't just look at packaging in isolation.

37:53 One of the things Conda does, which is what allows them to solve certain problems that they solve, but at the same time is one of the reasons some people don't find Conda appropriate, is that it bundles Python.

38:07 You install Conda and then use that to install Python.

38:11 And that's a fundamentally different way of getting Python.

38:16 Rust has a similar thing you get rust not give you rust cargo the model is the model is using all the places but i change like that is not something that the packaging community can agree on by themselves that would involve the code of the steering council it's a very very significant change to the whole model and i think one of the things that we struggle with one of the things i was sort of trying to get out at this point in the discussion was that we're not in a position to do that at the moment maybe we should be more not one of the things coming out of this discussion is a broader look at what can we achieve what can we achieve what we need to work out how to how to take that forward if we want to so yeah i think pip is in an odd position because a lot of people say, "Why can't we add this to Pip?" Because pip should be the thing to do.

39:12 But speaking as a pip maintainer, I'm not even sure if that's what pip should be doing.

39:18 Because we've got a lot of history, we've got a lot of legacy code in Pip, it will be a big disruptive change to use as a pip to our workflow, whereas Hatch is doing a great job of it.

39:29 PDM is doing fine.

39:30 Do we want to get into that area?

39:34 And that's where, in all honesty, that's where a lot of the discussion started to veer towards big-round philosophy questions.

39:44 And I think a lot of people got quite frustrated because they're hard questions and nobody's got an answer.

39:50 People wanted action.

39:51 I think one of the things that came out of the survey was a real sense of urgency.

39:55 People said, "Burn it all down and create something new now.

39:58 We want a unified solution now." And that put everybody under a sense of pressure to, we ought to be doing better.

40:05 But the reality is, some of these things will take a long time.

40:09 And thinking about them is the first step, which is what we're doing here.

40:13 The analogies that people make, I find very interesting, because some people do come in saying make it more like Conda, which as Paul said, kind of sits outside of Python.

40:21 But then other people say make it more like Cargo, make it more like NPM, which kind of have the virtual environment thing built into the packaging tool.

40:29 So rather, but it still lives inside it.

40:32 And we get people coming, always coming in with these assumptions that because pip is part of the standard distributions of Python, I'm choosing those words carefully as a core developer, because it comes with the stand with the Python.org distributions, they assume that because it's included, it's going to be like the ones that are included in other languages.

40:52 And that's simply not the case.

40:53 I mean, we, for starters, we existed well before those did.

40:56 that we couldn't have copied what Rust does or what Node does, but it's just not.

41:01 But having all those requests come in kind of just show that if we did burn it down, we don't even know what people actually want built back in its place.

41:08 'Cause they're all asking for different things.

41:10 - I think part of the challenge, people are asking for you all to decide.

41:14 I got that sense from a lot of this conversation from some of the feedback, the survey results, was nobody is deciding in the core developer space.

41:25 tell us how to do it.

41:26 We'll go with that.

41:27 A lot of them would say, obviously not everyone.

41:29 - The CPython co-developers, well, this isn't the most polite way of saying this, but they sort of don't care about packaging.

41:36 The Python stream effectively delegated all of this and say, you figure it out.

41:42 And while there's a bunch of people here who are co-developers, they're wearing two hats.

41:47 It's not a single hat.

41:49 And to jump back in the conversation, I'm sorry, I've done that a few times already.

41:53 - Please do.

41:54 Python very redistributor-driven distribution model, whereas with RustUp, for example, everyone's getting Rust as the Rust team built it and as the Rust team packaged it, and it ships to them. Many people are getting their Python from Homebrew or from PyEnv and compiling it or from ASDF and doing the same thing, or from Debian, who have patched it in a bazillion ways. And a lot of the Python packaging problems that people keep hitting are actually these problems in the trench code. These are Python distribution problems that are showing up when we use the packaging tooling. And that causes a lot of friction there as well. And solving that is probably hinted at is the last problem. And it's also tricky because Problems mirror your organization.

42:45 And as we're organized, we aren't set to solve this.

42:49 Not easily.

42:50 - To be fair to the distributors, we like distributing Python as source code.

42:53 Like the official release of CPython is a pile of source code that someone else should build and give to you.

43:00 'Cause that's model, the Linux model, whichever model it is from 30 years back, is you got your operating system with the software built for it by someone who picked up all those source bundles and built it for you.

43:13 if you didn't do it yourself. And so it's never really been built around the core team, build the binaries and distribute those. And it certainly does confuse people because we do do that for Windows and we do do that for macOS because we've been able to, because we never had distributors pick those up. I think with... In the same way that the Linux distributors did. With more Windows users nowadays than we used to have, I think that confusion is much more visible. The people coming from a Windows background think, "Well, I get Python from python.org." People coming from a Linux background think, "Python.org has nothing. I get it from Ubuntu," or "It's just there. I don't even know where I get it from." That's something that is changing. I don't know if we will ever...

43:59 I think languages like Rust with things like Rustop, that's a new model, and it comes from much more recent how people expect things to be delivered to them.

44:09 And Python's got a heck of a lot of history here that isn't as easy to change as people might like to think it is.

44:17 I'm not saying we don't. I'm not saying this isn't a challenge.

44:20 I guess to draw an analogy, it's similar to the source distribution versus wheel problem that we solved in some sense, wherein you can still build your own NumPy, but the NumPy developers ship a single NumPy, and that has certain choices made that you can make differently.

44:39 I guess I wasn't trying to be combative here.

44:41 [laughter]

44:43 This is how packaging discussions always go.

44:45 This is how packaging discussions, we always get combative.

44:47 It sounds like we're arguing, we were actually agreeing with each other.

44:50 [laughter]

44:52 - We're still just all together. - Absolutely.

44:53 But a big difference... Oh, sorry.

44:54 In the future, I would imagine, what would be best for users would be not to download a Python executable that installs, but rather you would download the workflow tool.

45:05 So whatever our version of Cargo ends up being, that's what you would actually download and install on Windows or Mac.

45:13 And that would manage your Python.

45:15 In that case, then that would be easier to install for users, and you wouldn't have the conflict of, you know, like, should pip do everything?

45:25 Because then it wouldn't be pip we're talking about.

45:28 Because right now, if you were to add workflow features to pip, that's a bit awkward because pip is in every Python.

45:34 So you have multiple workflow tools on your path, which is a bit odd.

45:39 Yeah, then you're tied to figure out how do I get to the right version of Python to then ask it the workflow questions. And what if I get that wrong?

45:46 What if 3.10 is not in the path that's installed, but why doesn't this work?

45:50 So on and so on.

45:51 So a couple of the interesting tools that have been growing a bit in more recent times, we've had the the py launcher on Windows for a while.

45:58 And Brett, unfortunately not here, is maintaining a PY launcher for other platforms as well.

46:04 And so there's some suggestion, I think Brett's actually experimenting a bit with adding some of this functionality into that tool. So kind of the primary function of the PY tool is you have that one command to launch Python, and it takes an option to select which version you actually want to run. So you don't end up with multiple copies on path, you don't worry about which order they're in. You just say PY, and you'll get the latest version, whatever the latest version is, because because it can do a more intelligent sort.

46:29 Or you say py-3.10-3.11.

46:32 - On Windows even, or you say the version in there, yeah?

46:36 - The Windows one has a lot of extra functionality.

46:39 I briefly looked at merging the two and kind of adopting Brett's one for both platforms.

46:44 But honestly, the Windows one, like 5% of the functionality is launching Python and the other 95% does not exist in the cross-platform one because it exists in the platform itself.

46:56 So there's a lot of other stuff that I don't even want to bring up in the Windows one.

46:59 But we do already have this extra tool that's getting installed everywhere, that's independently installable, that might be a suitable place to take on some of that workload.

47:08 I think the big challenge here, and I don't want to get into the Pipconda discussion again, but we have, at this point, 10 years worth of evidence of what happens when you put out a workflow tool that isn't strictly Python, but will give you Python.

47:25 and it hasn't beaten all the other workflow tools.

47:27 People still don't want to use the tool that does that.

47:30 And so I don't know if we can simply assume that providing that tool or mandating that kind of tool is going to be a winner because it exists, it's been around for a long time, and it's not won.

47:41 I think it's proven to be a fantastic experience if it suits you.

47:47 That's what Conda...

47:48 You listen to a Conda user and they are massively enthusiastic about it.

47:54 But it's because it fits what they want to do.

47:56 You listen to somebody who doesn't like Conda and they're equally frustrated with the choices it makes.

48:01 And I think, I think Steve's right.

48:03 I think we have to learn all of the lessons, not just some of the lessons.

48:07 And one of the lessons here is that sort of everything in one bundle tool is a mixed blessing.

48:14 I'm going to call from January because that's right in front of me.

48:18 And it seems very prudent.

48:19 Many of the respondents wanting a unified tool will have an implicit assumption that their preferred workflow will be supported. There are many workflows in here and trying to corral all of them into a single workflow is quite possibly a non-profitable problem. I don't think anybody responded to the survey saying please give a unified workflow tool that doesn't do what I currently do. Exactly. Please make what I do not work. Yes.

48:47 Make it hard. Everyone thinks their own workflow is normal and everyone else is the weird one.

48:52 I do want to, speaking of workflows, I was thinking through this process and thinking of like, well, what might an option be?

48:59 What might some other tool look like?

49:02 You all talk a lot about in the surveys and the responses about a user experience, right?

49:08 And we've got certainly notable people in the community who are well known for creating APIs that just connect with folks, right?

49:15 So I put together this idea of what if there was a few more commands in Python itself that you didn't even have to think about, do I have pip?

49:23 Does it use a hatch under the covers or does it not?

49:27 What have you had things like Python init, Python add requests, Python upgrade all, Python build.

49:34 I think you've just misspelled hatch here.

49:36 Haven't you?

49:36 I probably have.

49:37 You've spelled hatch with a P Y T H O N.

49:41 I probably have.

49:41 Yeah, exactly.

49:44 Well, but I don't have to think of pip is installed.

49:46 I don't think if pip is there, like, I'm almost afraid to put this up here as a proposal, because if it got adopted, then it might be the way and I don't like it.

49:56 I don't know if I would like it.

49:57 But have you thought to go this far to say like, we're not even going to talk about the tools that make this happen.

50:02 This might be pip plus Hatch making this happen behind the scenes.

50:05 You might set an environment variable that says, please use poetry when you do this stuff, but I don't want to talk or know about poetry.

50:11 I just want the output of it.

50:12 just Python install. That's all you tell them versus pip install dash our requirements.txt.

50:17 Oh, I meant pip three. Wait, pip three doesn't exist. Why doesn't pip three exist on and on and on? Right? Like, and then if you want to do more, you use hatch or use pip tools or insane, not insane. I'd use that. I think there is a quick, like Steve said, this is, this is almost hatch. Make app is the one I'm looking at and thinking, please give it to me now. But it's It's almost Hatch. The question is whether Hatch is where it is, or PDM, or Poetry, or whether it's Python.

50:44 If you want it to be the Python command, then I think there's a whole...

50:50 We're way too far through this now to talk about the role of the PyPA and how it links to the core developers.

50:59 But there's a whole disconnect that we struggle with, and we continue to struggle with, which is what can we do in packaging and what do we need the core to be involved with?

51:10 Pradyum mentioned earlier, Python core defer packaging decisions to the PyPA and to the packaging people, which is great as long as it works, but when it doesn't, when we need to integrate more, we're not really there yet in knowing how to address that sort of thing.

51:27 So I think a tool that does something like that, it's certainly what I'm looking for.

51:31 it's certainly what I think a lot of people see when they say workflow tool.

51:37 And as I say, we've got people like Hatch and PDM and Poetry making that a reality.

51:42 You just made tools into people.

51:44 Yeah, sorry.

51:45 I don't know all the names.

51:49 But yeah, we have people making that sort of thing happen in the different tools around.

51:54 Unifying is a question that I think we need to look at.

51:58 And there's a clear message that having 10 different tools that do this sort of workflow is not what people want.

52:05 But we don't know quite what the best model is yet. So there's some work to do there.

52:09 The massive danger, Paul, is if you pick one, and it turns out to not be really that great.

52:13 Yeah.

52:14 Which we've been burnt by before.

52:15 Many times.

52:16 So it makes us a lot more hesitant to pick something.

52:21 I think all I'll say on this is, yeah, there's tools out there doing a lot of this.

52:25 The best way to get it adopted into core Python is have a tool that is clearly the winner, that we can integrate that tool directly. And so the transition path becomes if you're using Python 3.36 or whatever version it makes it into, then you have Python that command. If you want to work with the previous version, then first you install, let's say, Hatch and use Hatch that command.

52:50 This is the kind of thing that might get integrated into that py launcher I mentioned before, because we have more ability to add more random commands to that.

52:57 All of these are valid Python commands today.

53:00 So people could theoretically be running these commands already and having it do something.

53:05 I'm clearly not doing what you intend here, but they're all valid commands.

53:08 And so we can't just push out a minor update that breaks them.

53:11 The only thing we do need to watch with that is something that Pradeon mentioned in his blog post, which is, we want to see a winner in one sense, but we want to be very careful not to end up in a competitive situation where, rather than working together to get to the ideal workflow, we're working against each other.

53:33 We do not want, it's not going to be good for users, it's not going to be good for the tool developers, it's not going to be good for the community if we're all trying to compete with each other on, I've got this whizzy new feature.

53:45 We want to work together and I think we want, I hesitate to use the word a winner, but we want a clear sort of best of breed that we can promote, because as we've said, we've been so burned by saying this is what we should use, having everything go horribly wrong, that we're very reluctant to do that without evidence. So we want to see something become that tool that people want. Which is going to get difficult as long as we have competing solutions where it's like, "Oh, now we're split 50/50. And now what? There were decent solutions. Whichever you pick makes half the ecosystem angry." Yeah, but I think it is important to eventually get help from CorePython. I know we were just talking about how Conda has been around for like a decade and that workflow tool hasn't won. But like if a decade ago, you know, on Python.org, you had that tool, I think that would have won. It's just about advertising it on core Python. So eventually we'll need their assistance.

54:49 Yeah, that's a really good point. Indeed.

54:51 And you know, we definitely do want to make it work from the core Python side.

54:54 I might be the least kind of conflicted core developer here. So I can say that we do want to make this work. It's just seen as kind of outside of the core runtime responsibilities.

55:06 One of the massive discussion threads actually kicked off because I mistakenly thought the steering council kind of owned responsibility for packaging and delegated it officially to the PyPA. But it turns out I was wrong, and they just don't cover packaging at all. And so packaging is kind of outside of core focus entirely. It's officially not cared for by the core developers, unofficially not cared for, if that makes sense. It's like, we do care about it. We do want it to work. We do want it to be a good experience because we know it's critical to the overall Python experience, but it's also just scoped out of being our job, which is why we don't hold up releases based on packaging and to get packaging features into the core runtime is, it just feels like a huge amount of work to do because it's got to overcome that this is so important to the core runtime, to the reference interpreter, that it's got to be in there, even though it's a packaging thing. So it's challenging, but there's definitely those of us who want to make it happen.

56:05 And one of the benefits of being outside of the language is that it can move faster.

56:09 Python has an annual release cycle compared to, to draw an analogy, the Rust plus Cargo story of six weeks.

56:16 And also, not having this be in the core language makes it possible for alternative platforms and implementations that don't exist, that CPython does not care about today, to support those things.

56:28 Wasm, which is a 303 support, pep11 for anyone who cares about where that word comes from. Pyodive exists. It runs things.

56:38 CPython compiles on Wobblin and it runs things. The packaging story for Python on the browser is going to be very different. The development workflow for Python on the browser is going to be very different. And if you try to shout poetry and paper or those specific rules as differently shaped into those workflows, that's just not going to work. And you also don't want to visual bad avenue of innovation using these tools. That's one of the pieces that is sort of a symptom of success or a problem of success, which is HAT, poetry, PDM, all of these exist because the other problems have been solved well enough and they've been solved well enough that these These are now the main endpoints.

57:25 They're innovating in this space, and there's other aspects of Python getting innovated on in terms of where it runs, in terms of how you interact with it even.

57:35 And as long as we don't stifle those, we're doing fine.

57:39 Yeah.

57:40 And that's a really good point about it not being in the core distribution as well.

57:44 If the ability to install packages was considered a core feature of the runtime, we wouldn't able to release the runtime for a new platform until we'd figured that out, because that would block the release because we'd have to say the Python is incomplete until it has a complete packaging story on this brand new platform. So because that is separated, we can release Python.

58:03 And so we have WASM releases of the CPython runtime because packaging is not part of that.

58:09 And so we don't have to wait for that to come up. And yeah, because it's independent, Anaconda can come along and build PyScript and build packaging around the runtime, because it doesn't have to be tightly integrated into it. So there's big advantages. Like there's a reason we pulled distutils out of the core library, because it was restricting things. And so it opens up more things, but it does put more responsibility on distributors, essentially, to build a distribution of Python that includes the workflow tools, the packaging tools, the indexes, the repositories, whatever they need to give users of that distribution a good experience.

58:46 And ultimately, a lot of this comes down to our distributions from Python.org have a very, very basic story for this. We have pip preinstalled. That's basically our entire story.

58:57 Linux distros have their own story, which again, is they keep a very narrow focus on what they want to care about. And users want things outside of that. Even conda users, very kind of narrow focus to what's in those repositories.

59:11 And when you try and go outside of that, then things start breaking down just the same as all the distributions do.

59:17 So it's got pluses and minuses.

59:19 Python gets into places where it otherwise couldn't if packaging was a core feature of the runtime.

59:24 But it does mean that packaging is determined by the distribution and not by the core team and not even by the core maintainers of the kind of satellite projects that are really, really close to the core runtime because setup tools can't determine how a Wasm build is going to work because they're not controlling that distribution.

59:44 So there's a separation of roles that is not really clear, even to most of us who are involved, to be honest, that we all have different jobs to do and someone has to pull it all together.

59:55 And unfortunately, a lot of the time it's the end user has to connect the dots.

59:59 Well, I think guys, we are out of time, I would say, although not out of discussion points for sure. This could just go on and on.

01:00:06 It was super interesting conversation. It's really great to see it getting this focus.

01:00:10 But yeah, it's going to be interesting to see where it goes. It's a challenge. But Harjeet, I really like your ideas that we're going to rise to it. We've now come, we've solved the hard enough problems now that this new thing is a problem. Ofek, go ahead.

01:00:23 I have one quick question because I'm sure listeners would be curious too. What do we think the next steps either are or should be for this? I know we split off into different discussions and we're trying to research the feedback that we got, but what do we think the next steps are? Or is that just the next step, just trying to understand what users want more?

01:00:45 I don't think we know yet.

01:00:47 Yeah, I mean, I've written far too many posts on where I think we've got to go next, but I do think we still have to, as Prajan mentioned earlier, level set.

01:00:56 There's a lot of people involved. We all have different backgrounds, different expectations, different experiences and we just need to talk and figure that out. And it's the kind of thing that would be ideal for us all to fly to some remote island somewhere for a week and just hash it all out in person. That's unfortunately not going to happen. So long discourse threads.

01:01:17 We're not leaving Hawaii until we solve this. We've got to stay. I'm okay with that. I will do it. Three months later, we're still there. Yeah, absolutely. All right. Well, you all, - Well, thank you so much for being here.

01:01:31 Thanks for taking the time and participating in this first, the original discussion, and then this here as well.

01:01:36 I think it's going to highlight a lot of interesting and unseen aspects for people.

01:01:41 Final word, listeners out there, they want to get maybe their feedback in.

01:01:46 We saw some folks in the audience asking how they take the survey.

01:01:49 The survey is closed.

01:01:50 I'll give you a chance to sort of say like, what next for people out there listening.

01:01:54 Steve, we'll go around the circle again.

01:01:56 You're the top of it, go first.

01:01:57 - If you're still on Twitter, then you can mention me in a tweet at Zooba is, you know, I do, I do read those and I do collect a lot of kind of random information ideas out of the otherwise discourse and started discussion and don't be surprised if we point you at an existing one and say we've done this one to death already.

01:02:16 So I always happy to hear more and I guess just be aware that we do get very overloaded.

01:02:22 Sure.

01:02:23 Paul.

01:02:24 Yeah, I think that's probably about the about the situation.

01:02:28 When I'm not very active on social media, you can probably ping me on Twitter or Mastodon and I might notice.

01:02:35 Certainly get involved, I can't promise, certainly get involved on Discord.

01:02:41 I think a lot of people are put off joining the conversations because it feels quite a hostile environment.

01:02:49 There's a lot of, like Steve said, we've seen that before.

01:02:53 We do want new perspectives.

01:02:55 We do want people offering ideas and it's hard.

01:02:59 It's hard to speak up because there's so much history that people will assume you know and you won't.

01:03:08 But please do, you know, come with half-baked ideas.

01:03:13 We'll maybe tell you how to bake them.

01:03:15 We'll maybe tell you we've already covered them, but we won't ignore them.

01:03:19 We'll see them.

01:03:21 And even if it looks like we're not picking up on things that you think are really important, they'll get in the pot.

01:03:27 We will be aware of them.

01:03:28 And that's the main thing.

01:03:30 What we want more than anything is to be aware of what people think.

01:03:33 Yep.

01:03:34 Ofek

01:03:35 I agree with what's been said.

01:03:36 I'm always on the discourse forums reading feedback and if any Twitter threads gain popularity.

01:03:42 I think it's important to realize most people that work on this are volunteers at the end of the day.

01:03:49 We might not have much time to iterate as fast as people want, but we are trying our best for sure.

01:03:55 Excellent.

01:03:56 And there was that big sponsorship to make major progress on PyPI.org.

01:04:01 Maybe we'll see something like that at some point.

01:04:02 Pradyan, you get the final word here.

01:04:04 That's literally what I was going to say.

01:04:06 Invest in Python folks.

01:04:07 If you work somewhere that uses Python, tell them to invest in the language.

01:04:13 And part of why we're having these discussions is because the role that initiated the user service is a sponsored role from Bloomberg.

01:04:22 And these sorts of investments into the ecosystem are vital to sort of make things keep working because there's only so far we can go with a bunch of people doing this in their evenings when they're, you know, slightly sort of bored and kind of want to keep themselves busy.

01:04:39 And these tough problems are not going to solve themselves because someone had half an hour in their evening or an hour in their evening.

01:04:46 Yep.

01:04:47 All right.

01:04:48 Good point.

01:04:49 And thank you all for being here.

01:04:50 Thanks very much.

01:04:51 Thanks, Michael.

01:04:52 Bye.

01:04:53 Bye.

01:04:54 This has been another episode of Talk Python to Me.

01:04:55 Thank you to our sponsors.

01:04:57 Be sure to check out what they're offering.

01:04:58 It really helps support the show.

01:05:01 Join Cox Automotive and use your technical skills to transform the way the world buys, sells, and owns cars.

01:05:08 an exciting position that's right for you at talkpython.fm/cox.

01:05:13 Take some stress out of your life.

01:05:15 Get notified immediately about errors and performance issues in your web or mobile applications with Sentry.

01:05:21 Just visit talkpython.fm/sentry and get started for free.

01:05:26 Be sure to use the promo code "talkpython," all one word.

01:05:29 Want to level up your Python?

01:05:31 We have one of the largest catalogs of Python video courses over at Talk Python.

01:05:35 Our content ranges from true beginners to deeply advanced topics like memory and async.

01:05:40 And best of all, there's not a subscription in sight.

01:05:43 Check it out for yourself at training.talkpython.fm.

01:05:46 Be sure to subscribe to the show, open your favorite podcast app, and search for Python.

01:05:50 We should be right at the top.

01:05:52 You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the Direct RSS feed at /rss on talkpython.fm.

01:06:02 We're live streaming most of our recordings these days.

01:06:04 If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm/youtube.

01:06:13 This is your host Michael Kennedy.

01:06:14 Thanks so much for listening.

01:06:15 I really appreciate it.

01:06:16 Now get out there and write some Python code.

01:06:18 [MUSIC]