00:00 To make software useful, honestly, to even make it real, you have to ship it.
00:03 Building that web app? Then get ready to deploy it. Building a tool set for data scientists?
00:08 How are you going to send them that application? Did you manage to get a cool GUI app going in
00:12 Python using PySign? It's time to have your users start downloading it. Python is an amazing
00:17 ecosystem, but one of the frailer parts of it has been shipping or deploying software,
00:21 especially to end users. In this episode, you'll meet Cliff. Join the two of us as we discuss
00:26 where we are and where we're going with shipping Python code. This is Talk Python to Me,
00:32 episode 127, recorded June 12, 2017. Welcome to Talk Python to Me, a weekly podcast on Python,
00:53 the language, the libraries, the ecosystem, and the personalities. This is your host,
00:58 Michael Kennedy. Follow me on Twitter where I'm @mkennedy. Keep up with the show and listen to past
01:02 episodes at talkpython.fm and follow the show on Twitter via at talkpython. This episode has been
01:09 brought to you by Rollbar and Datadog. Be sure to check out what they're offering during their
01:14 segments. It helps support the show. Hey, everyone. Two things I want to share quickly before we jump
01:19 into the conversation with Cliff. First, when we started talking with him about what he's up to
01:23 day to day, at the time of the recording, he couldn't announce the company name or say too much
01:28 about what he was doing. But they have since launched, and their name is Pilot. Pilot does
01:33 bookkeeping for startups using a combination of expert human bookkeepers and software automation.
01:38 It's a software service that does your books, not an app for you to do your own books. So you can find
01:44 out more about them by visiting pilot.com. And while you're there, you can imagine that
01:49 Glyph has definitely shipped some Python code to it. Next, I have a new course to announce. I just
01:54 released RESTful and HTTP APIs in Pyramid. This course will teach you the mechanics of building
02:01 amazing APIs in Python, of course. But you also learn the theory of RESTful HTTP services in general,
02:07 how to design them, when and how to use HTTP verbs and status codes, content negotiation,
02:13 and even a little SQLAlchemy. Check the course out at talkpython.fm/REST. That's R-E-S-T.
02:19 Now let's talk about shipping some software. Glyph, welcome to Talk Python.
02:23 It's great to be here.
02:24 Yeah, it's a real honor to have you on the show. You've done so much cool stuff. And
02:28 I'm surprised our paths haven't crossed more, but I'm glad they're crossing today.
02:32 Same here. And I gotta say, I know you're always so complimentary of your guests, and it's an
02:37 honor to be on the show. But I gotta say, you podcasters do some real good for the Python
02:42 community yourselves. I feel like I'm talking to a rock star here, too.
02:45 Well, thank you so much.
02:47 It's just a great way to access the culture of the elite in the Python community, the luminaries.
02:54 I know a lot of people listen to this show and really get a sense of what the culture of the
02:59 community is like from it. So we all appreciate what you do for the community.
03:03 Thank you so much. I definitely see that as like one of the major services that we provide,
03:10 you know, just to get the backstory. Like everybody knows about requests. They know about
03:15 Twisted. They know about all these things, but you know, they just know the API. They don't know
03:19 the story and the people. So as much as we can share that, that's awesome. Speaking of stories,
03:23 how do you get into programming?
03:25 Well, that's a very long one. A lot of people, you know, there's a sort of stereotypical story
03:30 of like, well, I had an Altair when I was a kid and I learned basic. And so I had a kind of
03:36 oddball version of that, which is that my father, who's a fairly prominent software developer himself,
03:42 he was an APL programmer when I was a kid.
03:45 APL blows me away, by the way.
03:47 Yeah. Have you ever actually seen like a full APL program?
03:50 I've seen little snippets and it's incredible. Could you just describe what the syntax looks like
03:54 to everyone? Cause it's really not standard.
03:56 Imagine that you were an astronaut on the moon at an archeological dig and you found a tablet
04:02 that was a programming language from an alien civilization. That's what APL looks like. It's
04:08 a combination of geometric symbols and Greek letters. And I think there might be some Hebrew letters in
04:14 there. It is a very odd sort of programming language in that it comes off this
04:20 evolutionary branch that did not have a lot of other languages on it. And it's definitely not
04:26 the main one, you know, the sort of algal derived C, C++ type programming languages that we're all
04:33 used to these days.
04:34 Yeah. It's really a great description, like an alien one. When people ask me to describe it,
04:39 I think of it's like, if Egyptians used hero graphics to like program, like this would be APL basically.
04:47 Yeah, very much so. so, and of course, when I started learning to program at eight years old,
04:52 that was not what I was looking for.
04:53 Did you try to learn APL at that age?
04:55 Dad tried to teach me. That's might not be the same thing. So I sort of learned a little bit of APL
05:01 just enough to, start trying to write a text adventure, Zork style video game.
05:07 So, I learned how to do the very first thing, which was variable assignment. So that when you would type
05:13 West, it would print out the description of the room to the West. And that's kind of where I stayed
05:20 in terms of programming sophistication for the next decade or so. Oh, well, maybe not decade,
05:24 maybe around eight years. But I, so I started off trying, I didn't want to learn a program. I just
05:29 wanted to be able to do just enough to make these Zork style video games. And I could not, without
05:37 learning to code, obviously I couldn't actually get anywhere. So I went from there, which was APL 68K
05:42 on the Amiga to HyperCard on the Mac. And, HyperCard was, I don't know, probably some of your
05:51 listeners are familiar, but maybe not all of them. HyperCard was a English like scripting environment
05:57 where you weren't writing a program, like a textual thing. You would launch HyperCard and you'd start
06:04 editing these documents, which were a combination of like buttons and text fields, as well as little
06:09 scripts that were attached to each of them. And so I spent a long time very, very tediously kind
06:15 of teaching myself to code by accident because I had chosen this environment because it was the one
06:20 where you didn't have to know how to code. And finally, after years of resisting this, I discovered
06:26 what a variable was. I discovered that you could like have a value that didn't have to be like put
06:33 into a text field or stored as a buttons label. Like you could just actually have a abstract notion
06:38 of a value. And that sort of blew my mind. But, and one of the reasons I'm telling the story is like,
06:44 I feel like that archetype that we have of the kid who learned basic and was programming since they were
06:51 like five years old, kind of discourages other people from getting into coding. They feel like,
06:56 Oh, I couldn't do this. It takes forever.
06:58 I'm too old to get started.
06:59 Yeah. Like you have to do this from it's, it's like a language learning. You can only do it when
07:05 you're really young. And I, despite having a story where I did learn to code pretty young, I feel like
07:11 it's important to emphasize. I screwed it up as hard as I could. And I really like squandered every
07:16 opportunity to learn anything useful until I was at least 16. At which point I actually started to
07:24 learn to code. I learned some C++, and then I learned some Java and started actually making games
07:30 because it was pretty hard to do it without actually knowing how to do any of the coding part of coding.
07:36 So I went from there where I was doing a bunch of kind of hobby projects and game development. I got a
07:42 job at a small software company in New Jersey and had a terrible, terrible experience writing their
07:50 flagship application in Java. We were reporting it from an old legacy, a database system to Java.
07:57 And I went wrong with that experience. What didn't go wrong. It was a interesting lesson in depending on
08:06 proprietary software you don't pay for. The major thing that went wrong was the Java runtime environment
08:13 on the Mac at the time would leak about three quarters of a megabyte of memory every time you opened a
08:19 window. And since this was a closed source runtime and our entire application was based around these
08:25 windows that would open and close, you would lose just megabytes of memory at a time. And, it was
08:31 many like as a cocky 19 year old, I didn't know anything about doing metrics or setting performance targets or
08:39 anything like that. So we got several months into the project and I of course had been reassuring
08:43 everyone the whole time, like, this is going to go great. This is going to be fantastic. It's going to
08:47 be so much better. We got close to what should have been the end date of the project and it turned into
08:52 frantic bug hunt, trying to figure out where these problems were coming from in our code. And it turned
08:58 out they were coming from the Java runtime.
09:00 Oh yeah. And so you're, you're thinking, what are we doing wrong? Let's, let's double check it one
09:05 more time and there's nothing you can do, right?
09:06 Right. It's never the compiler until one day it actually is the compiler. And then you're in a
09:11 really bad situation. So I spent a while trying to debug that. I really, I did like Java as a
09:17 programming language, but I left that job shortly thereafter, just because I felt like dying of shame
09:23 after convincing everyone this is going to be great. And then, you know, that was a huge disaster.
09:28 So as a formative experience that taught me that maybe I should be looking for systems that have an
09:34 open source component, that if there's a horrible, horrible bug, I can kind of get down into the
09:38 runtime and fix it myself. And that's one of the things that led me to discover Python.
09:42 At the time between jobs, I was kind of working on this text adventure. Once again, this is a
09:48 recurring theme in my program. I bet you're a fan of muds and these types of things.
09:53 Oh yeah. No, I was definitely played one or two in my time.
09:57 Nice. Me too.
09:58 And so, yeah, so I was developing this thing and I had written it all in Java and it was a giant,
10:03 massive multi-threading, like four or five threads per connection. This was, many of your listeners,
10:12 I hope will be too young to remember this or will have blanked it out as a traumatic memory.
10:17 But this was a time when there were, there was actually a marketing term, massively multi-threaded.
10:22 This was like a good thing that you would be proud of that your code would do.
10:25 And so this Java thing definitely qualified and it was full of just unfixable race conditions and bugs.
10:34 So one of the things that the Python language had, which I didn't have exposure to in Java or any of
10:41 my previous C++ work was the select module. And the select module, I discovered it first because we,
10:48 one of the people who was helping me out with this was developing a kind of client server protocol.
10:54 This was a mud with like a rich text front end so that it wasn't just a console.
11:00 Graphics and background patterns and things like that.
11:03 And so he was rewriting this communication layer with the client and he was tired of coordinating the five or six threads that got involved in the networking layer.
11:14 And so he just wrote it to use the select module to detect which of the operations that we might need to do to the socket were available, read or write or error.
11:26 And I had never seen such a thing before. And I thought to myself, that's interesting.
11:30 So you could do like two or three things at a time, but without threads.
11:33 And that's more or less where Twisted came from was I had started investigating that.
11:37 And it ended up being a much simpler, less error prone way to develop apps.
11:42 And so I fell in love with Python on many levels simultaneously.
11:47 One of them was that it made that whole style of programming possible.
11:51 Another was that it sort of was this thin foam padding around C that made it easier to distribute applications.
11:58 And this thing's not sharp. It doesn't cut me anymore. Does it hurt?
12:01 Exactly. Yes, it was. Physically, it didn't hurt. Actually, I was typing so many fewer lines of code in Python that I wasn't developing serious wrist pain or anything at the time.
12:13 But like after a day of coding, I would feel it if I were writing in C++ or Java.
12:17 And in Python, like it literally did not hurt me to code. So that was a pretty big upgrade.
12:22 That's really good. That's cool. Yeah, that's an unexpected benefit.
12:27 So I think this using things like IO ports and completion ports, this type of programming that's sort of asynchronous but not threaded.
12:35 That's something that takes a while to run into maybe a little bit less these days.
12:41 But certainly, it's really easy to jump into threading straight away and just think I need parallelism. Let's go create threads.
12:47 It's kind of interesting how it depends where you come from, like different programming cultures, I think give different exposures to this.
12:54 I actually did a PyCon talk a couple years ago called So Simple You Could Even Do It in JavaScript about event-driven programming.
13:01 Because if you come from a background, not just of JavaScript, but of any kind of graphical user interface, event-driven programming is very natural.
13:10 It just seems like something you do.
13:12 Even like VB6 or something like that. Yeah.
13:14 Right. Just because it's really clear when you're saying like on click, do X, on mouse down, do Y, right?
13:20 Like those types of things make intuitive sense.
13:22 The problem is when you're kind of in a back-end environment.
13:26 You're talking to a database or you're doing some kind of transaction processing.
13:30 And then you have to say on transaction complete.
13:33 And you think to yourself, but wait a second, why can't I just block?
13:36 Like this is kind of like a function call.
13:38 And that's when thread seems really appealing.
13:40 And if you've been developing things that way, then it just seems natural to keep developing them that way once you have concurrency.
13:48 I do think that it's definitely kind of becoming more popular in that domain.
13:53 But there are lots and lots of programmers that you might consider sort of novice or like not really or like non-programmers who can code, who actually take to it very easily.
14:04 And so it's kind of an interesting piece of expertise that people pick up in odd ways.
14:08 Yeah, I'm sure.
14:09 And also the rise of JavaScript, the rise of Node.js, they really put that front and center like it's unavoidable.
14:16 Exactly.
14:17 And it's that same thing where you just say, you know, on click equals and then some code.
14:20 And it intuitively makes sense.
14:22 You don't have to explain that that's an event handler and, you know, the cascading model in JavaScript.
14:27 You can learn a whole lot about handling events before you hear the word event.
14:30 Yeah, for sure.
14:32 So what do you do day to day for like professional work?
14:36 I work at a startup that is started by one of your previous guests, I believe.
14:41 Jessica McKellar.
14:42 Okay.
14:43 Is one of the founders.
14:44 And we do bookkeeping.
14:47 Actually, we're a bookkeeping service.
14:49 Primarily, I think right now for startups.
14:52 But the idea behind the company is there's lots of apps for doing your own bookkeeping like QuickBooks.
14:59 We do the work of bookkeeping with software, though.
15:03 So we can automatically classify transactions.
15:06 And so our product is not software.
15:09 It's your books.
15:10 So awesome.
15:12 Yeah.
15:12 Yeah.
15:12 That sounds really awesome.
15:13 But of course, you know, we have some software behind the scenes.
15:15 So since podcasts are a durable cultural artifact and our name is temporary, I will avoid saying our name.
15:22 Hopefully we'll have a permanent one soon.
15:24 Well, it sounds like a really noble goal.
15:27 There are pretty decent bookkeeping bits of software like QuickBooks.
15:32 I'm not sure I'm willing to judge it.
15:34 FreshBooks, Invoiced, those types of things.
15:37 But that doesn't solve the problem of like, hey, I would rather like do something technical and not force myself to become an accountant.
15:44 Right?
15:44 Yeah.
15:44 We are bookkeeping for companies that don't want to worry about bookkeeping.
15:47 Right.
15:48 And we have a real focus on automation and trying to make things kind of seamlessly just work.
15:53 Nice.
15:53 That sounds really fun.
15:54 Do you guys have like machine learning and stuff going on there?
15:56 We have, I guess I could say we have proprietary machine intelligence, which might mean machine learning or might mean a pile of regexes.
16:04 Who could say?
16:05 Yeah, sure.
16:05 Yeah, who could say?
16:06 All right.
16:06 Awesome.
16:06 Well, it sounds like a really fun project.
16:08 So we're going to talk about some, spend a little time on your PyCon talk.
16:14 Now, this is the PyCon 2016 talk, but were you at the 2017 PyCon?
16:18 I was.
16:19 In fact, I spoke at the 2017 PyCon.
16:21 That's right.
16:22 That's right.
16:22 I do.
16:22 I also have, we're going to also talk about your talk there.
16:24 How was that experience?
16:26 What do you think?
16:26 I mean, PyCon is always a highlight of the year.
16:28 There's just so much stuff that goes on.
16:30 I can't possibly consume all of it.
16:33 One of the really interesting things about PyCon is for a technical conference that has like a really large number of tracks.
16:38 And in fact, not only does it have a large number of tracks, but there's kind of an intentional scheduling thing they do where they will put high profile talks up against each other.
16:47 So Corey Benfield, for example, gave a really good talk right at the same time as I did.
16:53 So I didn't get to see his.
16:54 Yeah.
16:54 And that was inside requests or something like that, right?
16:57 I believe that was, I always get mixed up which year it is, but yes, I think that was it this year.
17:02 Okay.
17:03 But there's so much stuff going on beyond just the talks.
17:07 I mean, there's the summits.
17:09 There's just an incredible hallway track where there's people doing open spaces and informal conversations.
17:16 And it's a real opportunity for open source projects to get together and be strategic, which is not something that we get to do a lot in open source.
17:24 But we get to sit down and see people from Twisted and Requests and AsyncIO and Flask and Jinja and Django, all in the same room, all kind of talking about the future of Python and how we're all going to add features to our various projects and things that we can work together on, standards we can collaborate on.
17:47 And so there's so much stuff going on at PyCon, no matter what your level of skill is.
17:52 There's a lot of new folks.
17:54 Every year at PyCon, I learn something really interesting about some of the software that I work on from someone who's either never used it or who's just started using it for something really unusual.
18:03 So I love hearing from those types of people as well.
18:06 Yeah.
18:07 So PyCon, always amazing.
18:09 Yeah.
18:09 I definitely look forward to it.
18:10 I'm already looking forward to the next one.
18:12 And it's like 49 weeks away or something, right?
18:16 Just to start get a calendar, start checking them off or something.
18:19 I really like what they do with the program committee where there are also a lot of new speakers every year.
18:24 Like there are people sharing new and different perspectives.
18:27 It's not, you know, obviously I give great talks.
18:30 You should go see all of my talks.
18:32 They're all archived.
18:34 But it's not just me and Corey and Hinnick and Guido standing up every year and giving the same talk over and over again.
18:41 It's like if we want to be, if the old timers want to get up on stage and say something, it's a very competitive environment because there are people talking about monitoring black holes with Python or...
18:55 ...innovating robots in factories or all sorts of stuff, right?
18:59 Yeah.
19:00 There's just so much, especially with the uptick in data science, there's so much science going on that has Python involved in it in some way.
19:07 Yeah.
19:07 That's interesting.
19:08 It's probably going to only get more competitive in that there are more people and more disciplines it's pulling from.
19:14 Exactly.
19:15 And it's great to see that reflected.
19:16 I like to say that Python is always the second best language for everything.
19:21 So it's never quite the best thing you can reach for, but as soon as you need to do two things, suddenly it's the best language because you can't do machine learning and be a web server at the same time in any other language nearly as well.
19:35 Unless you want to try to write it in R, which I hear is theoretically possible, but I'm not sure it's a good idea.
19:40 Yeah.
19:41 Well, it comes down to that same thing.
19:43 I can guarantee you R is not the second best language for writing a web server.
19:47 That's right.
19:49 That's right.
19:50 This portion of Talk Python to Me has been brought to you by Rollbar.
19:54 One of the frustrating things about being a developer is dealing with errors.
19:58 Relying on users to report errors, digging through log files, trying to debug issues, or getting millions of alerts just flooding your inbox and ruining your day.
20:07 With Rollbar's full stack error monitoring, you get the context, insight, and control you need to find and fix bugs faster.
20:13 Adding Rollbar to your Python app is as easy as pip install Rollbar.
20:18 You can start tracking production errors and deployments in eight minutes or less.
20:22 Are you considering self-hosting tools for security or compliance reasons?
20:26 Then you should really check out Rollbar's compliant SaaS option.
20:29 Get advanced security features and meet compliance without the hassle of self-hosting, including HIPAA, ISO 27001, Privacy Shield, and more.
20:39 They'd love to give you a demo.
20:40 Give Rollbar a try today.
20:42 Go to talkpython.fm/Rollbar and check them out.
20:45 I definitely want to touch on a few of your projects before we get into shipping software because you've got some popular projects and you've got to package them up and ship them.
20:56 So maybe we could touch them.
20:58 Like probably the best known one is Twisted and the stuff that's spun out from Twisted, right?
21:03 I think that that will probably hound me to my grave is the most popular thing I've ever done.
21:08 Yes.
21:10 Yeah.
21:10 You don't get a pick, right?
21:11 Indeed, we do not.
21:12 So maybe tell people what Twisted is for those people who don't know.
21:17 Twisted is an event-driven programming system networking engine for Python.
21:22 It's a thing that basically if things happen on the network or over the passage of time and you want to get a method called on your objects, as a result of that, Twisted can help you out.
21:33 It's got web client and server.
21:35 It's got an IMAP client and server.
21:37 It's got a DNS client and server.
21:39 It's got a whole bunch of protocols implemented.
21:41 And it's also got a lot of stuff that lets you kind of combine asynchronous control flows in various interesting ways.
21:50 It's kind of almost the original framework for this.
21:53 I hesitate to say that because there are a lot of precursors that Twisted drew from.
21:58 But a lot of those precursors were much more special-cased and kind of purpose-specific.
22:03 Whereas Twisted, like the concept of a deferred originally came from Twisted and deferreds eventually moved kind of front-end into JavaScript and eventually deferreds became promises.
22:13 And promises are obviously a very popular thing for JavaScript developers to use these days.
22:18 So Twisted is both new and dynamic.
22:21 There's lots of interesting stuff going on in that community.
22:23 Lots of modern practices being adopted.
22:26 But it's also very kind of venerable and pretty old as a non-legacy technology goes.
22:33 Yeah.
22:34 It was definitely one of the original ways to write this style program that you talked about in the beginning,
22:40 where it's kind of IO completion port, not just 100 threads running next to each other, right?
22:45 Right. And one of the things we did, we actually presented a paper at Usenix at the very beginning of the Twisted project,
22:50 talking about the need for kind of a high-level interface to things like IO completion ports.
22:55 Because at the time, FreeBSD was adding KQ, and Linux was starting to add ePoll,
23:00 and Solaris had its own high-performance multiplexing mechanism.
23:05 But of course...
23:06 You guys are like, stop the madness. We can't have all of these.
23:08 Well, actually, we were kind of almost saying the opposite.
23:11 We were like, this is great, all these hyper-optimized, low-level kernel things.
23:15 And I guarantee you, no one will ever write an application to talk to one of these.
23:18 You're going to get the three biggest servers out there to do it, and then no other app will ever be able to take advantage of your custom kernel special thing.
23:27 We need a way for apps to write against a common API so that when the kernel goes off and does some crazy new thing,
23:33 we can actually use it without having to rewrite all of our code from scratch.
23:37 So there was definitely an element of stop the madness from the perspective of stop putting all of these new .h files that I have to include.
23:45 Like, they're not helping me.
23:48 Yeah, yeah.
23:48 It sounds really interesting.
23:49 So Twisted's still going strong, huh?
23:53 People are still doing interesting new things with it?
23:55 Oh, yeah, absolutely.
23:56 One of the interesting things about it, which I did predict when AsyncIO came out,
24:00 there were a lot of people who don't like Twisted for one reason or another
24:04 and who were sort of sharpening their knives when AsyncIO came out.
24:08 And they were like, oh, great.
24:09 Now, you know, we don't have to use Twisted anymore.
24:11 It's like, it's true.
24:12 If you don't like Twisted, there's like more options now.
24:14 But there was a sense among many people that it was going to kind of be the doom of Twisted.
24:19 Oh, now there's this event loop in the standard library.
24:22 But one of the interesting things that came out of that was that event loop is just one small piece of what Twisted did.
24:30 And we did not want to have to be the kind of standard bearers for all event-driven programming in Python.
24:36 We wanted to provide like a nice little suite of protocols that all work together nicely and like tools to help you with testing and like generally be like a framework.
24:46 But it would sort of be like if Django, let's say, were the only way to speak HTTP from Python.
24:53 And one day somebody came out with a second web server or there was like a web server in the standard library.
24:58 Yeah, watch out.
24:59 There's a bottle now.
25:00 Everyone's going to just stop using Django.
25:02 Exactly.
25:03 It's like, no, Django does like one or two other things that you might want to do.
25:06 And Twisted's the same way.
25:07 We've actually seen a big uptick in activity and interest.
25:10 A lot of other people starting to pick up Twisted.
25:12 Because for a long time there was a vacuum in the standard library.
25:16 It really wasn't clear how Python was going to do concurrency.
25:20 And now that the answer is like async await, event-driven I.O., that's what's coming.
25:25 That's the future.
25:26 It's like, oh, okay.
25:27 Well, Twisted's been in the future for the last 15 years.
25:30 That's cool.
25:31 Are you thinking of, or can you already like access it in Python 3 with like async and await type programming models?
25:38 Oh, yeah.
25:38 No, we support.
25:39 So I believe we've been adding new features every release for the last couple of years.
25:44 I'm not sure exactly where everything landed.
25:46 But in 17.5, which is a release that just came out, I believe, yesterday, we have full support for converting deferreds into futures and creating futures from deferreds.
25:59 So not only can you use async await, which you've been able to do for a while with Twisted, you can even use Twisted in the middle of an async I.O. app.
26:06 You can switch to use some Twisted library code and then switch back anytime you want.
26:11 So it fully integrates at every layer.
26:13 Oh, that's awesome.
26:15 It's got coroutine support for interacting with futures.
26:17 It's got event loop support.
26:19 It's got an async I.O. reactor that you can use.
26:21 So you can map Twisted's event loop on top of async I.O.
26:24 There's TXTULIP, which is a third-party thing that's been able to do this for a really long time, even before Tulip became async I.O.
26:33 and got it at the standard library.
26:34 So we've been really – I mean, Twisted has always been a very integration-focused project.
26:39 I mean, we speak gross, difficult protocols like IMAP, so you don't have to.
26:45 And, you know, we do the low-level plumbing so you don't have to, too.
26:49 Yeah, that sounds really, really nice.
26:51 So two quick comparison questions.
26:54 First of all, what do you think of some of the new frameworks coming out, like UVLoop and things like Sanic and Jopronto and those efforts there?
27:03 I mean, I think it's great that everybody's learning this new paradigm and doing cool little experiments with it.
27:08 I do think that there is maybe a slightly odd perspective where people are looking at something like Sanic, which is brand new and kind of named after a weird meme,
27:22 to be equally kind of feature-complete and robust as something like Twisted.
27:27 And I think that in many cases, like, the comparison is almost unfair because, like, it's not like Sanic comes with its own DNS server, right?
27:37 Like, there's a lot more stuff in the Twisted ecosystem and in the Twisted core.
27:41 I think both those projects, personally, I think they're pretty interesting and they look very promising.
27:46 But I don't feel like they're close to ready yet.
27:50 Yeah, I think that, I mean, they're certainly ready for some things.
27:52 And I wouldn't want to discourage people from trying them out.
27:55 But I also think that it's important to kind of calibrate your expectations.
27:58 I mean, there are many things that Twisted still doesn't do right after 15 years of trying to do this.
28:05 And so I think that there's also, like, Curio and Trio, like, weird new event loop models that people are experimenting with.
28:12 Yeah, that was my second question.
28:13 Like, Curio also sounds a little bit similar to Twisted in that it's trying to really be the loop and, you know, talk different protocols in the network and stuff like that.
28:23 I mean, I think that the idea behind Curio and Trio was kind of to invent a new style of programming.
28:29 And Twisted has this kind of unofficial policy of no new ideas.
28:33 We don't implement anything, like, novel or original.
28:36 Everything that Twisted does at a kind of fundamental level is something that my dad was doing on Stratus mainframes with, in C, in, like, the 80s and 90s.
28:49 So, you know, we are not as focused on kind of being a research platform, which means that, you know, there's kind of less interesting new agey stuff in Twisted that might spark an interesting research direction.
29:02 But it also means that you can kind of let Twisted be boring and make your application be the interesting part.
29:07 Yeah, well, sometimes boring is good if you're building on top of it.
29:10 That is our hope.
29:11 Nice.
29:12 All right.
29:12 So you want to just maybe touch a little bit on some of your other projects that you want to mention?
29:16 And then we can talk about shipping software.
29:18 Sure.
29:19 I mean, a couple that I think are always need to be mentioned in the same breath as Twisted are Klein and Trek.
29:24 Klein is like Flask, but for Twisted.
29:26 Trek is like Requests, but for Twisted.
29:28 They're a little bit different than Flask and Requests in certain ways.
29:33 But if you want to build like a kind of standard service-oriented app or like a little web app with Twisted in an event-driven way, those are pretty much almost required.
29:43 Right.
29:43 Because you're going to need to not just listen on HTTP, like Twisted, the web server that comes with Twisted, you should think of like as a competitor to Apache or Nginx, not Django or Flask.
29:54 It's a web server and it's designed to be, the API that it offers is designed to be kind of like a configuration language for composing resources together.
30:02 Whereas like Klein is an app platform.
30:04 You can write a little server with it.
30:07 And then there's also TX Acme, which is based.
30:12 So I made a project called TX S&I, which was just sort of designed to make it easy to dump your SSL certificates into files without caring what order the private key and the chain certificate and the nine other things you seem to need to dump into a SSL configuration.
30:27 You could just kind of put them all in a file in any order and call it like your domain.pem and it would automatically get loaded.
30:33 And then Tristan Seligman built on top of that with TX Acme, which is a Let's Encrypt implementation for Twisted.
30:38 So you can just like combine those three things and get a service that automatically listens on an SSL port, automatically provisions the certificate and gives you nice async server and client web APIs.
30:49 Oh, that sounds like a fun set of building blocks.
30:52 So yeah, so those are the ones you should definitely check out.
30:54 We've also been trying to make an effort to move some of the data structures that Twisted uses that have nothing to do with event-driven programming, that are just kind of useful Python library functionality, out.
31:03 So Mahmoud Hashemi recently extracted our URL object into a project called Hyperlink.
31:10 And Hyperlink got adopted partially as part of that inter-project communication and collaboration that I mentioned at PyCon into the Python HyperOrg.
31:20 The name and the fact that the org is called Hyper are just kind of a coincidence, but people I'm sure are going to assume that it's called Hyperlink because it was made by Hyper.
31:28 But that's a really handy object if you need to parse URLs like a web browser does, like dealing with Unicode and all the different places that Unicode can show up and parsing percent escaped stuff into human readable text.
31:43 That's a handy library to have.
31:45 That sounds nice.
31:46 And that's the kind of stuff you don't want to mess with, with weird escapes people can do to get around security and all sorts of stuff, right?
31:53 Oh, yeah, you can find slashes in all kinds of strange places.
31:56 And yeah, Hyperlink, it's because it kind of parses like a browser does.
32:00 It lets you do all kinds of interesting stuff, like interesting transformations where you can say there's like a click method that'll take a URL and give you a new URL.
32:08 It's like a link to the URL, which is the kind of thing where if you like doing web crawling or, you know, indexing web documents, it's the sort of thing you have to be able to do a lot.
32:21 So, but there's a couple others.
32:23 There's also incremental, which is we have a version object in Twisted because we were very concerned with backward compatibility and long term support for various things that you need to be able to track versions.
32:35 So we spun that out to a different library.
32:38 It's also eventually, which is because we're concerned about compatibility.
32:41 Compatibility means you need to have deprecations.
32:45 And so eventually is a library for deprecating stuff and eventually removing it, which is where it comes from.
32:52 Yeah, I really like that project.
32:54 Yeah, we're hoping it becomes a little more popular because like in such a high level dynamic language as Python, you need to be kind of disciplined about making sure that you communicate to your users like, hey, this is going away.
33:05 It's going to stop working in so many versions.
33:07 And like this is perhaps segwaying into our main topic here.
33:10 It's important to be able to do that because you want people to be if they're packaging applications, including your stuff, if it's part of their requirements that text, you want them to be able to upgrade regularly.
33:21 But you also want them to know how much technical debt they've got pending and like how much work they have to do before they can upgrade again.
33:27 Yeah.
33:28 And you don't have the compiler with a, you know, a deprecated flag right there.
33:33 Right.
33:33 And so you basically have this runtime thing that does something similar, which is cool.
33:37 Exactly.
33:37 Yeah.
33:38 Nice.
33:38 Hey, everyone.
33:40 This is Michael.
33:40 Let me tell you about Datadog.
33:41 They're sponsoring this episode.
33:43 Performance and bottlenecks don't exist just in your application code.
33:47 Modern applications are systems built upon systems.
33:49 And Datadog lets you view the system as a whole.
33:53 Let's say you have a Python web app running Flask.
33:55 It's built upon MongoDB and hosted and scaled out on a set of Ubuntu servers running Nginx and MicroWSGI.
34:00 Add Datadog and you can view and monitor and even get alerts across all of these systems.
34:05 Datadog has a great getting started tutorial that takes just a few moments.
34:09 And if you complete it, they'll send you a sweet Datadog t-shirt for free.
34:13 Don't hesitate.
34:14 Visit talkpython.fm/Datadog and see what you've been missing.
34:18 That's talkpython.fm/Datadog.
34:22 You gave a really nice talk and you structured it in the form of a play, more or less, at PyCon 2016 called Shipping Software to Users with Python.
34:32 And this is something I'm also super passionate about.
34:35 And I feel like we've seen the growth curves of Python really, really taking off and, surprisingly, even in the last few years, becoming much more popular than it was.
34:45 But I think if we had a better deployment story, it would even be steeper, that curve.
34:52 I totally agree.
34:53 And this is one of the reasons that I wanted to write that talk in the first place was that I was and am really passionate about Python being available to people kind of where they are.
35:04 One of the things that drove me to talk about deployment is it's cool that Python's usable as a web service thing.
35:12 It's certainly been a huge driver of economic activity and scientific discovery in that kind of role.
35:18 But there's also something just tremendously empowering about being able to program your own computer and make it do useful stuff for you.
35:27 Yeah.
35:27 And the problem with having a kind of broken deployment story is it seems like a kind of arcane technical solution, system deployment or application packaging.
35:37 But when you think about it, it's really just like some fifth grader makes a hilarious guess the number game.
35:44 And then they want to share it with their friend.
35:46 Like what do they do at that point?
35:49 They go to their friend's house and they set up their machine to run it.
35:51 Right.
35:52 Exactly.
35:52 They take their laptop over there because that's all you can do these days.
35:56 And so that often drives educators away from Python because if they do it in Java or they do it in – so in Java, it's a little bit weird.
36:05 You often have like a strange runtime environment that all the students have to set up.
36:10 But if it's in JavaScript, they just load the web page and there it is, right?
36:13 Yep.
36:13 And Swift is making inroads there as well with their playgrounds and all that kind of stuff as well.
36:18 Exactly.
36:18 And Swift is as amazing as playgrounds are and there's a lot to like about them.
36:24 It's almost the thing that I was – it's sort of the nightmare scenario that I'm afraid of, which is why I really think we should get our deployment story together in the Python community, which is that it kind of draws this line between technical people and non-technical people.
36:38 And if you're like a real programmer, you ship to the app store.
36:41 And if you're just playing around, you use playgrounds.
36:45 And that dichotomy creates this sense that people are not empowered to do like real programming or make real apps.
36:52 And I think there's two sides to that.
36:55 Apple's also done quite a bit to reduce the barrier to entry on shipping software into the app store.
37:02 It's a lot less expensive than it used to be.
37:03 It's a lot less effort than it used to be.
37:05 But it is still this hurdle that, for example, kids are just never going to get over.
37:10 Whereas when I was learning to program as a kid, the sense that grown-up professional, serious software company like Broderbund could make something and put it on floppy disks and then you could do the same thing was very powerful.
37:23 It was really – it gave you a sense that you could do something real in a way that kids don't get to experience in a lot of different levels.
37:29 Like if a kid wants to be a doctor when they grow up, they can't like kind of do some surgery just to try it out, right?
37:36 But as programmers – That's right. We hope not.
37:38 Exactly.
37:40 But as programmers, you know, we have this luxury of the safety of being able to potentially make something that's like real and useful and shareable.
37:48 But if deployment doesn't work, you don't get any of that.
37:51 Yeah. Yeah, absolutely.
37:52 And on the other end of the spectrum, if you go to the pro places and you say, let's write some – especially like the one that really strikes me is, let's write a GUI app in Python that we're going to ship around, right?
38:06 Like it certainly is possible and we'll talk about some of the tools that you can do it with.
38:12 But it's not as easy as some of the other here's the thing I compiled and you just take it and it just runs stories.
38:19 Right. It's really not very streamlined.
38:22 And it is getting better, but again, I guess we can talk about how.
38:25 Yeah, yeah, absolutely.
38:26 So you said that you had your talk sort of focused in different areas.
38:31 Like you were focused on maybe the people that create libraries, the people who run stuff in the cloud, like web developer types.
38:40 And then this third one where we talk about either from a kid perspective, like learning or from a pro perspective, shipping stuff to end users, right?
38:50 Was that basically the three areas you were focusing on?
38:53 More or less, yeah.
38:54 I mean I also talked a little bit about the people maintaining the infrastructure in Python, but that's kind of more of a like telling them to consider those other three perspectives.
39:04 Right. Okay. So you went through some of the stuff that you can do for the server side and that's pretty straightforward.
39:10 Like we can make packages.
39:12 We can use things like Twine and ship those up to PyPI.
39:16 We can package them as wheels.
39:18 We have requirements.txts.
39:20 Like that kind of stuff.
39:21 I don't know. It's super clean, but it certainly works well once you get used to it.
39:27 Like I've had a few people who are learning Python web development come to me and say, this is all really hard.
39:31 How do I make this stuff work?
39:32 Like I don't know what to do.
39:33 So maybe it's not hard, but it, and you kind of touched on that.
39:38 It's like, it's confusing or not clear what the steps are.
39:41 Yeah. One of the problems is, you know, we actually have a fair amount of documentation at this point, except there's so much of it now.
39:49 We trip over our own feet trying to explain to users how to do this kind of stuff.
39:53 And so you end up with something where it's like, it's actually pretty straightforward to assemble a Docker container, let's say.
40:00 But you'll find so many half written tutorials and there's so many concepts and so many separate tools that you have to chain together that most people do not end up on the fast path.
40:10 They do not end up just doing the one thing that's going to be easy for them.
40:14 And I think that that's getting a little bit better in terms of like what things people are linking to and what you happen to find just thanks to PageRank kind of finding the better articles over time.
40:24 But yeah, it's starting to stabilize a little bit as well.
40:27 Yeah, it's definitely been a long slog to get here, though.
40:30 And where we are is definitely not ideal.
40:32 One of the points I think that I didn't make in the talk that's probably worth talking about is that Python is not a deployment platform.
40:41 And so everything that we do, the things that I talked about in the talk, the things that we're talking about now, distutils, setup.py, virtualenv, right?
40:50 These are mostly developer tools.
40:53 They're for assembling the software into some shape, but they're not really for shipping it.
40:58 And one of the reasons that Cloud Python has gotten a lot better is that most of the assumption about where you're deploying your stuff is shifting towards containers.
41:07 And Docker is a deployment platform.
41:11 That is a system with like a pretty clear contract of what goes into a software artifact.
41:17 Like it's a Docker image.
41:18 That's it.
41:19 There are really no other options.
41:21 How do you run it?
41:22 Well, it's got an entry point.
41:23 And that's it.
41:24 Like there's a couple of things you might need to document.
41:27 I have a whole separate series of blog posts and stuff about type system for Docker and how it needs to be more expressive.
41:35 But basically, if you hand an ops person a Docker image, they more or less know what to do with it.
41:40 It's a clear integration point between Python people and systems people.
41:45 And the tools that we have at our disposal, like PIP, like distutils, like virtualenv, make sense in that context.
41:52 And we can pretty easily script them to do the right thing to build a Docker image.
41:57 But Docker is just one deployment platform.
42:01 And the problem is we need tools that deploy Python to multiple different deployment targets and not try to come up with a quote unquote Python deployment target that is universal and works.
42:15 Right. Like, for example, in the GUI space, just because you get a Docker container and you can ship that to end users and go, now run the Docker container.
42:24 Right. There's no Docker run on my iPhone.
42:26 Right.
42:27 Yeah, exactly.
42:28 That shows up in a couple of different places.
42:30 I mean, there's any kind of GUI front end thing suffers from this.
42:35 Like the GUI front end stuff just can't be shipped in that style.
42:40 But also it can't be as easily shipped with shell scripts.
42:43 Right.
42:44 The reason Docker works so nicely with the Python tool chain is that most of the things that we've sort of been building up from are a combination of dependency on some Linuxy,
42:54 type tools that are the low level stuff and then a script to assemble them into a coherent, like runnable shape.
43:00 And that's pretty easy to do in Docker, but that's a lot harder to do on, let's say, Windows.
43:06 Right.
43:06 Where ultimately you're just trying to get a P executable or zip file together.
43:11 But the process you need to go through to do that in order to, like, integrate with the Windows compiler and all of that stuff,
43:19 you actually kind of have to know about those tools and you can't just, like, write a little script and copy some binaries around.
43:25 Right, right.
43:26 The system's got to be, like, in a place to receive it in the first place.
43:29 Exactly.
43:29 Yeah.
43:30 So you kind of taunted the audience a little bit with this thing you called pip.app.
43:34 And you're like, okay, here's how we're going to deploy it.
43:36 We're going to run this thing called pip.app.
43:38 We're going to select our program.
43:41 We're going to select our dependencies.
43:42 We'll, you know, choose the operating system and we'll just package this puppy up, right?
43:46 Yeah.
43:47 And why can't we have it, right?
43:48 Like, this seems like a kind of almost obvious tool.
43:52 But it's, I think that one of the reasons that nobody's made such a thing is that it's, you have to care a lot about the general case.
44:02 And you have to care a lot about the end user experience.
44:05 And in the kind of open source world to scratch your own itch, you're never that end user, right?
44:10 You've already gotten to some point that's further down the line than just, like, I don't know what Python is.
44:15 But if we were thinking about making this in, like, a 1990s style desktop app where, like, a user finds your floppy disks in the store and can't talk to you after that, like, you'd better make it work just from the beginning.
44:29 And if we thought about it more like that, I think that people would end up having to Google for those confusing virtual end articles a lot less often.
44:36 And, you know, part of the problem is just that we don't have that many volunteers who are working on this stuff.
44:41 I think you're touching on a super important point.
44:44 And I've spoken to several people about this.
44:48 Like, you know, I sort of opened this section by saying if we could get the deployment, especially the client side UI style deployment better, it would just open up an entire new avenue of growth for Python and where we could really leverage apps.
45:01 And I was talking to somebody and said, look, this is a problem that is super important we need to solve.
45:05 And I said, well, it's just not a thing that I find people who do Python do very often.
45:09 We don't run into this problem.
45:10 And we don't run into this problem because it's so hard that we don't even consider doing this most of the time, right?
45:16 Exactly.
45:17 And it's really kind of sad because, in fact, it's not that hard.
45:20 And, like, 80% solutions exist for so many of these problems.
45:24 Yeah.
45:24 I mean, Dropbox is on, like, they always have that huge number.
45:29 I'm not sure what it is, like 10 billion computers or something.
45:32 They're running everywhere.
45:35 And that's a Python desktop app.
45:36 So clearly it's not going to, you know, wreck your company if you decide to use Python.
45:41 You know, they had to do some work to make that work.
45:44 And they made it work for them.
45:46 And I absolutely don't want to criticize Dropbox for not doing enough to help the open source community because they've definitely done tons of stuff.
45:53 Lots of really interesting work has come out of there.
45:55 But at the same time, like, if somebody else wanted to follow in their footsteps and make another Python app that would deploy to, like, a zillion machines, they'd kind of have to solve a lot of the same problems again in a different way because the Python ecosystem has moved quickly and has got a lot more and better tools than when Dropbox was first started.
46:16 So there's just problems.
46:18 The problem is everybody who's, like, really, really concerned about this problem is already too busy already.
46:23 Like, I gave this talk to try to help newer people to the community try to understand the problem because as we spent quite a while talking at the beginning of this show, I've already got a lot going on.
46:35 Like, I've got to, you know, keep the books for our customers and write software to automate financial stuff at work.
46:41 And then I come home and then I maintain Twisted and I maintain Climb and I maintain Track and I do all of this stuff.
46:47 And I, you know, try to keep the peace in the community and make sure the mailing list doesn't go down and keep our servers running.
46:55 And at the end of all that, I just don't have any time to start the fairly ambitious project to fix all of these problems.
47:03 Yeah. Well, and it doesn't sound to me, from what you described just now, that you individually have this problem, right?
47:11 And I feel like there needs to be, you know, a couple of major companies or a couple of major projects that are like, we need to build this app and ship it this way.
47:20 And we need to just fix the tooling to make it work for us and take the community along with us.
47:25 Yeah, I feel like it's the person who's going to have this exact problem is kind of hard to imagine.
47:30 Because if you want to ship a desktop app and you have interesting enough logic and enough investment in Python, there's lots of ways you can just do that today.
47:40 You can grab Pi to app and you can grab Pi to exe and you can work around the same seven bugs that everybody who uses them has to work around.
47:49 And eventually, after you've had a couple of professional programmers hammer on it for a few weeks, you'll have a deploy pipeline that works for you.
47:56 You put it into your continuous integration system and then you're good.
48:00 Right. Once you get around that, you make it work, then you forget how you even made it work, right?
48:04 Exactly. And then it's in your, you know, when you do something in your code that makes it stop working, then you notice and you back it out.
48:12 And this is actually one of the problems I didn't talk about in the Python talk was that one of the reasons this is so pernicious is that we don't tell users to start by deploying.
48:23 Because Python is so flexible and it's so empowering to just get in there and, you know, make a module and then make another module next to it and edit the first one to import the second one and then just change it and maybe even reload it on the fly.
48:35 There's all this cool stuff you can do with that and with Jupyter Notebook, just typing code into cells and never even put it into a module that by the time you have something you want to deploy,
48:47 you might have made a dozen mistakes about how you're loading resources or about how you're getting your code installed or the layout of your repository, right?
48:59 It's pretty easy to end up in a place where you can't even write a setup.py because all your modules are expecting to import stuff from like three different paths at the same time.
49:07 And at that point, you have to like back out of whatever weird structure you've got yourself into and then recreate something sensible.
49:15 And that's the point where you throw up your hands and go, I'm never going to ship this thing.
49:19 Like, I'm not going to rewrite my app or it's just not going to work for real apps or whatever, right?
49:23 So that's super interesting.
49:25 You're basically proposing that like if you know that you want to use Py2 app or Py2.exe or the cross-platform Py2 installer or Shakespeare's or some probably combination thereof,
49:36 like write your hello world and then create your hello.app and start building them up together.
49:43 Is that what you're proposing?
49:44 Yeah, I mean, I think for anybody who's out there who's thinking, I want to make a desktop app.
49:49 I want to make a mobile app.
49:50 I want to make a low-level system utility.
49:53 One of the categories we haven't talked about too much yet is just like if you're making a program that needs to like be a system control thing for Unix systems at a level lower than like Docker, right?
50:05 Like you want to write your own SSH server or something like that that like controls a system.
50:10 You also can't ship it as a Docker container because you need it to like live on the Debian or the Red Hat system.
50:16 So you need to ship it as a package.
50:18 So if you're in one of those categories and you're like, I want to ship this command line thing or GUI app and you're thinking, I'm definitely going to want this to have a GUI.
50:25 I'm definitely going to want this to ship as part of Homebrew.
50:28 I'm definitely going to want to ship this as a Debian package.
50:31 Whatever it is that your deployment target is, deploy your hello world to that target and get like Travis or some kind of continuous integration system to start running it for you and doing that build and making sure that it at least basically works.
50:46 Because it's really, really easy.
50:48 Once you've got that set up, once you've got that pipeline working, it'll pretty much keep working.
50:53 You might have the occasional problem where like some third party library has a weird like shared object that you need to install in some funny way.
51:00 But if you know that at that moment when you're adding that dependency or you're installing that tool, if it breaks right then, you could say, aha, I'm not going to use that.
51:11 Or I'm going to get in touch with their maintainers and say like, why is this broken?
51:14 As opposed to writing a big complicated app, getting everything all done, and then ramming headfirst into this brick wall of like, now how do I put this on somebody else's machine?
51:27 Because one of the things that you don't realize is you're making all kinds of decisions about how to get it to run on your machine.
51:33 And they seem like totally sensible, right?
51:36 You have icon.png and it's in the current directory.
51:40 So you just open up icon.png and you read it.
51:42 Except what's the current directory?
51:44 How do you know that it's in your git checkout?
51:47 Because your git checkout is not going to be there on your target machine.
51:50 So unless you're going to ship dev tools to everybody, you have to think about, well, where does that resource come from?
51:55 And that's exactly the kind of stuff that trips people up with packaging.
51:58 Yeah, that makes a lot of sense, actually.
52:00 I hadn't really thought about it that way, but it certainly makes a lot of sense.
52:03 I mean, it feels a little bit like, let's write 100,000 lines of code and then run flake 8 on it to find the problems.
52:11 Right.
52:12 Just the first time.
52:13 Exactly.
52:14 And a day before you ship, right?
52:17 Yeah.
52:18 Or another way to think about it is like, let's write 10,000 lines of code and we'll make sure that all unit tests pass, but we'll never run it.
52:28 Because we'll just assume that it'll work if we run it.
52:30 But of course, you run it that first time and it's like, oh, you forgot a couple of unit tests.
52:36 And your build pipeline is the same way.
52:39 So this is when I talk about pip.app, what I'm really talking about is not just like, let's make it easy, but let's make it the first thing you do.
52:48 So if there are bugs in it and there are problems with it, you're just doing it constantly.
52:52 So you notice when there's an issue.
52:54 Yeah.
52:54 I think that's really great advice.
52:56 So, you know, there might be a lot of people listening who don't, are not familiar with pip.app or pip.exe and how these things work.
53:03 Basically, you can take this pip.app utility.
53:07 So let's stick on the macOS for a moment.
53:09 And it will create, like kind of embed a Python runtime that you need, all the dependency packages that you need, your code and package it up in a way that looks just like Safari or something.
53:21 And users double click it and it can run.
53:23 Right?
53:25 Exactly.
53:25 Yeah.
53:25 And so they don't even necessarily, it doesn't even matter what version of Python they have, whether they have Python.
53:31 It's just, they get the app, it runs because it's a self-contained unit, like other runtimes like Go or certain Windows EXEs.
53:40 Yeah.
53:40 And this is exactly what I meant when I said that Python is not a deployment target.
53:44 Like macOS is the deployment target.
53:46 And the Mac says what you have to do to be an app.
53:49 And PyToApp just makes Python be that thing.
53:52 Right.
53:52 Here's your P list.
53:53 Here's your resources.
53:54 All that kind of stuff.
53:55 Exactly.
53:56 And it just bundles it up into the shape that macOS expects without any regard for like what else is on the system.
54:02 And really like Go is sort of famous for producing these static executables where they include all of your Go dependencies.
54:09 But oddly enough, Python is sort of in a better place for many operating systems than Go would be.
54:16 Because what Go lets you do is it lets you put all of your binary resources into one file.
54:21 But that's kind of a red herring.
54:23 The thing you actually need is to put it into the shape the operating system expects, which is almost never one file.
54:29 Windows is the one place that that's true.
54:31 But on Windows, there's a whole system for like tacking on resources into a .exe.
54:37 You can, I believe, Windows loads from the end of the binary.
54:41 So you can actually tack like you can, your binary can just be a zip file.
54:45 And then you stick the executable on the end.
54:48 And suddenly it works and it launches.
54:49 And I might be mixing that up.
54:51 I know that Unix is one way and Windows is the other.
54:54 And one's the beginning and one's the end.
54:55 But that kind of thing is like once you know how you want your app to run, it turns out that actually on Windows and on the Mac, you often need like shared libraries or DLLs or resources or things that can't be put into a single binary.
55:13 Like an app on the Mac cannot be a single binary.
55:16 It has to be at least an info.plist and an executable.
55:19 And practically speaking, you need a dozen other resources like icon files and other things.
55:24 And similarly, like even if you're just talking about command lines, right?
55:27 You think single file binary, you think, oh, that's really good for the command line.
55:30 That's really how I want to run my stuff is I just want to have this one binary.
55:33 And that can make the deployment process easier.
55:36 But how do people actually deploy stuff onto the command line on the Mac?
55:40 Do they like curl a binary in chamod plus exit?
55:44 No, they brew install it, right?
55:46 And homebrew has a whole complicated multi-file setup where the deployment target is homebrew.
55:51 That's a really interesting point.
55:53 In your little PIDA app graphic, you had the various targets.
55:57 And one was Ubuntu, one was Windows, one was macOS.
56:00 But another was a chocolatey install.
56:02 And one was a brew install.
56:04 And one was an aptitude package and things like that, right?
56:07 Yeah.
56:07 And each of these kind of defines its own deployment surface.
56:11 And the reason that you don't want to just be randomly curling some Go binary onto your system
56:16 is because that initial install is just one thing.
56:20 You've also got to have an update process.
56:23 And that update process probably has to be cryptographically signed or something.
56:26 Like somebody needs to be in charge of making sure there's a secure pipeline to
56:30 deliver it to all your users.
56:31 And then that has to run on a CDN to make sure you don't have too much load.
56:35 And by the time you're done with that, you've got JSON files that are describing your metadata
56:39 and hashes and all kinds of other stuff which don't fit into that one binary anymore.
56:43 So Go can kind of get you started.
56:46 And it can make a lot of parts of this pipeline easier.
56:48 But one of my favorite examples of this, which I don't think I mentioned in the talk
56:52 because I think I found out about it somewhat later, is Askinima, which is a website.
56:58 It's a really cool website for sharing like screencasts of terminals.
57:02 Have you ever used it?
57:02 No, no, I haven't.
57:03 But you have to put a link in the show notes for us so we can check it out.
57:06 Definitely.
57:06 But the idea is it's just this little thing.
57:09 It's like a social place where you can share your various like Emacs and VI sessions.
57:14 Nice.
57:14 That's awesome.
57:14 And when you do this, they have a local TTY recording tool, which they originally wrote
57:19 in Python.
57:20 And then, of course, because Python makes deployment hard, they rewrote it in Go from scratch.
57:26 And then they rewrote it again in Python because they just went to Python 3 and they shipped
57:33 it as a thing that you brew install because it turns out going to the single file Go binary
57:37 didn't really help solve their problems that much.
57:40 Right.
57:41 And, you know, Go is a lot lower level language.
57:43 So it didn't like there were a lot of things that they lost as well.
57:46 So by just kind of going straight to the never mind the single file thing, we just want to
57:52 make sure that this is brew installable.
57:53 It got to what their users really wanted, which is way to get it installed.
57:57 That's like easy to explain.
57:59 It doesn't require a lot of sysadmin knowledge to keep updated.
58:02 It doesn't require a studio.
58:03 Exactly.
58:03 Yeah.
58:04 You just type the brew install command.
58:05 And the killer thing about the way that the thing that people think they want when they
58:11 hear a single file is when you've got a Python install and you're doing like pip install
58:17 to get your tools installed.
58:19 The problem with that isn't that it's multiple files.
58:21 It's that it's sharing all kinds of files.
58:23 So you do a pip install A and then you do a pip install B.
58:26 And if you just need tools from A and B, they can conflict with each other.
58:31 So pip install B breaks A because they're all reading from the same location.
58:37 All their libraries are piled on top of each other.
58:39 And there's no dependency checker in pip, which makes sure that A isn't going to break.
58:43 The versioning metadata isn't fine grained enough for A to even know that it's going to
58:48 break when B gets pip installed.
58:49 So it's just too fragile to try to share all of this stuff between Python libraries.
58:55 It's not like a .so where you can have like a very, very strict binary interface.
59:00 That never, ever changes.
59:02 Like anything can change in any Python file anywhere and potentially break every user of
59:07 that library.
59:07 You pretty much need to do a full on test run of your application to make sure that it's
59:12 not going to break with a new version of a dependency.
59:14 So it's that sharing that becomes a really big problem.
59:18 Yeah.
59:18 And sometimes you can't even avoid that because you're using two packages.
59:21 They might both use a dependency, but they were built against different versions of that
59:25 dependency or something, right?
59:26 Exactly.
59:27 And there's nothing really wrong with that even.
59:29 That's the, when you describe the problem, it sounds like, oh, that one library really
59:33 should have ran its tests.
59:35 Shame on them.
59:36 But it's not really, it's, it's not their responsibility to make sure that whatever random
59:41 versions of libraries on your system happen to work, they have a continuous integration system
59:46 that says what they work with.
59:47 And so, you know, we've gotten a lot of improvements in the Python ecosystem for library developers
59:53 to put out more and more robust artifacts.
59:55 But that last mile of like, put the application together, packaging everything together.
01:00:00 One tool that I really like that I use a lot is Pipsy, pip S-I, which I don't think is actually
01:00:08 an acronym for anything, but I pretend that it stands for pip script installer.
01:00:12 What it does is you do Pipsy install HTTPIE, let's say, or Pipsy install Boto3 or AWS CLI
01:00:20 or something.
01:00:21 And it will install a new virtual env that contains just the scripts that come from that top level
01:00:31 package.
01:00:31 And it'll like symlink those scripts into a shared directory, but kind of hide the virtual
01:00:37 end from you.
01:00:38 So it's every single tool that you need is installed into a separate virtual end for
01:00:42 its own requirements installed into it.
01:00:44 It's still kind of a developer installation tool because you already need to have Python,
01:00:49 you already need to have virtual end.
01:00:51 There's like a little bit of setup that goes into installing Pipsy in the first place and
01:00:54 bootstrapping it.
01:00:55 But then once you've got it, at least your stuff doesn't break all the time.
01:00:58 Like, yeah, it lets you play with stuff more aggressively or without care, right?
01:01:04 Right.
01:01:04 It's isolated and it's kind of installed the way that it should be, which is that each
01:01:07 app has its own dependencies.
01:01:09 Because again, Python is not a platform.
01:01:11 The compatibility guarantees that a library can make in Python are not strict enough that
01:01:17 you can have users upgrading their own stuff and then thinking it's going to work afterwards.
01:01:22 Like you need to ship a user all of the libraries that you tested with.
01:01:26 Yeah.
01:01:26 Yeah.
01:01:26 That makes a lot of sense.
01:01:27 So one thing that you held up as a good example is Briefcase.
01:01:31 I think that Briefcase is headed in a really good direction.
01:01:34 I think that they, that project has set up some really good infrastructure in terms of
01:01:40 like how they think about the long-term solution to the problem in that they have great onboarding
01:01:48 for new contributors.
01:01:49 They show up at lots of events.
01:01:50 They had a great presence at PyCon.
01:01:53 And they also, so they're, they're playing the long game here.
01:01:55 They recognize that this is a very big complex problem.
01:01:59 That's going to require a lot of people to solve.
01:02:00 And that it's also multi-layered.
01:02:01 Like one of the parts of the Beware project is not just Briefcase, but Batavia.
01:02:07 And Batavia is this transpiler from Python byte or not transpiler.
01:02:14 It's a Python virtual machine written in JavaScript.
01:02:17 So that you can ship your PYCs into a web browser.
01:02:20 And that doesn't seem like it's really related to Briefcase at first, until you realize that
01:02:26 the vision that they're pursuing is ship Python anywhere, write all of your code in Python all
01:02:32 the time, which is really the vision that I'm also sympathetic to.
01:02:36 And, but unfortunately what that means is because they are taking this very long view of the problem,
01:02:41 it's probably not the thing that you would use like right now for everything.
01:02:45 It does have some really great iOS build templates.
01:02:48 If you were going to do a mobile app in Python, it's probably the best place to start.
01:02:52 Yeah, I agree with that.
01:02:52 They, Russell Keith McGee did a, a bunch of the build work on Pythonista.
01:02:58 So I don't think that Pythonista, that the iOS app that runs Python is itself like straight up
01:03:05 deployed with Briefcase, but it shares a lot of that same technology.
01:03:07 And so there's kind of a, at least a proof concept that it can work really nicely.
01:03:11 I don't know if you've played.
01:03:12 Yeah, I've played with Pythonista.
01:03:13 It's a cool app for sure.
01:03:14 It's basically, it's a Python editor and runtime for iOS.
01:03:20 Maybe also an Android.
01:03:21 I don't know about Android.
01:03:22 I'm pretty sure it's just iOS.
01:03:23 Yeah.
01:03:23 Yeah.
01:03:24 Which it's impressive to me that that's even possible given all the restrictions that Apple
01:03:29 puts on executables.
01:03:30 Yeah.
01:03:30 I mean, they probably wouldn't like it if you started shipping apps to people in the form of
01:03:35 like that really, really long base 64 encoded.py files.
01:03:41 There is some tooling to actually help you write an iOS app inside Pythonista on iOS.
01:03:47 You do need to like have a Mac to kind of bounce your project off of because you need to do the
01:03:53 build of an iOS app on a Mac.
01:03:55 Yeah.
01:03:56 But I've done that.
01:03:56 I've downloaded the templates and like made a little hello world out of the scripts that come
01:04:01 on Pythonista, which is actually kind of another interesting reflection of the same problem from
01:04:06 a different direction, which is that Pythonista does not have any equivalent to pip.
01:04:11 So it's actually very hard to write full apps that take advantage of the Python ecosystem because
01:04:18 you can't, your build pipeline can't include that kind of like, and install this requirements.txt file
01:04:24 first.
01:04:25 Python's less fun when you, you have no import.
01:04:28 Yeah.
01:04:29 I mean, Pythonista kind of cheats a little bit because it just gives you a thing that like
01:04:33 already includes like requests and like NumPy and some pretty big chunks of SciPy, I think
01:04:39 are also in there.
01:04:40 So it's, it's just kind of like, ah, here's about a third of the interesting stuff in the
01:04:44 Python ecosystem.
01:04:45 Just in a big box.
01:04:46 But yeah, the, the idea that like you can grab this, you know, from the, the staggering ecosystem
01:04:54 that Python has to provide for you.
01:04:56 That's really what makes this interesting because if you're just going to write an app, you know,
01:05:01 do it in a Swift playground and then, you know, copy the Swift code to a Mac and write all of
01:05:07 that yourself.
01:05:07 It's not that much different than Python.
01:05:10 Like Python might be a little nicer, but once you can pull in stuff, like you can pull in
01:05:15 Jupyter or something like that and you can have like live introspection of your objects
01:05:19 in your app or you can pull in something like NumPy and have that tremendously powerful numerical
01:05:24 library at your disposal, it starts to make the investment in Python kind of make sense.
01:05:29 Yeah.
01:05:30 Yeah, it definitely does.
01:05:31 I think Swift is a fine language.
01:05:32 I just think their equivalent of the standard library is really, really not, not a great story.
01:05:38 It's pretty bare bones.
01:05:40 Yeah.
01:05:40 But, but, you know, Python, the way Python can compete with that is by being yet more robust in the library ecosystem and not by kind of cutting itself off at the
01:05:50 knees and saying like, here's a really streamlined deployment experience that only works if you
01:05:55 write all of your code yourself.
01:05:56 All right.
01:05:57 Yeah, absolutely.
01:05:58 We definitely don't want, I want to see that.
01:06:00 So, Cliff, this is a bunch of great advice and hopefully a lot of inspiration for, for people
01:06:07 that, like you said, go that last mile to kind of close the gap and make this really sweet
01:06:11 deployment story.
01:06:12 Well, I certainly hope that, folks get inspired to go do that.
01:06:15 I think that, if you are kind of, if you feel like you're just a regular developer and
01:06:20 you don't feel like you could take on something this ambitious, going and helping out the Beware
01:06:24 folks, get briefcase into the kind of shape that it can just do a lot of this work
01:06:29 itself is probably the best way to help out the community at this point.
01:06:34 Yeah, I agree.
01:06:34 And they are, they have like basically a mentorship program for first time open source contributors
01:06:40 and they're very welcoming there.
01:06:41 So it's, it's a nice environment.
01:06:43 Definitely.
01:06:43 I think that that's one of the things that they, they might do better than almost any other
01:06:46 project I've seen is that they are really focusing on the people problems and making it
01:06:50 easy to get involved with the project and make a real impact quickly.
01:06:54 Yeah.
01:06:54 It's good to see they're working on this problem as well, cause they're doing cool stuff.
01:06:57 All right.
01:06:58 So I think we probably should leave it there for, for that, but let me ask you the two questions.
01:07:02 So we talked a lot about shipping Python code, but if you're going to write some Python code,
01:07:06 what editor do you use?
01:07:07 So we began with a story about my childhood and I feel it's only fitting to, to end on one
01:07:13 because I've heard you ask this question of a lot of people and they all give you an answer
01:07:18 and I have an answer, but I, I think it's important to reflect on where that comes from.
01:07:23 When I was 10 years old, my father sat me down and he said, you're going to grow up and
01:07:30 people are going to tell you that you should be a VI user or you should be an Emacs user.
01:07:36 And what I have to tell you is they're both wrong.
01:07:40 You need to do both editors because sometimes you're going to be SSH'd into some machine
01:07:44 that you have.
01:07:46 He probably said telneted, but you know, sign of the times.
01:07:49 Same basic thing.
01:07:50 You're going to be in on some console where you can't install anything and Emacs isn't there
01:07:55 and the environment's set up wrong.
01:07:56 And you're really going to want to know how to be able to exit VI.
01:07:58 And at the same time, like Emacs is this tremendously powerful library ecosystem of all kinds of
01:08:04 sophisticated stuff that you probably want to be able to leverage to be able to use like
01:08:12 an IDE.
01:08:13 So I actually learned pretty young, both Emacs and VI.
01:08:17 And I have tried to take that philosophy to heart in that I have a working Sublime Text
01:08:22 configuration.
01:08:23 I've been working on upgrading that to Sublime Text 3.
01:08:26 I haven't messed around with Adam too much yet, but I definitely intend to.
01:08:29 And my wife is a big proponent of Visual Studio Code.
01:08:33 So I feel like we should all learn to use editors in harmony.
01:08:38 Yes.
01:08:39 That said, Emacs is the best one.
01:08:41 And that's what I use.
01:08:43 That's a great story.
01:08:45 Thanks.
01:08:45 And a good answer.
01:08:46 All right.
01:08:47 And notable PyPI packages?
01:08:49 I'll throw a twisted out there for you straight away.
01:08:51 Yeah.
01:08:52 Actually, I wanted to talk about, I wanted to bring up one that we haven't already mentioned
01:08:56 in the course of this discussion.
01:08:57 And so I think Hypothesis is a package that I would really recommend people check out.
01:09:02 I haven't used it very much yet, but what Hypothesis is, is it's a generative testing framework.
01:09:09 So you kind of give it a piece of code that you want it to test, and then you give it some
01:09:15 variables, some ways that it can generate data or state for that code to be tested in.
01:09:22 And then you kind of fire it off, and it will figure out what's interesting to test about
01:09:28 your code in some ways.
01:09:30 I'm making it sound a little bit more magical than it is, but it lets you, like if you have
01:09:35 just a function that takes two numbers, and there are range limits on how those numbers
01:09:41 are supposed to relate to each other, like there's one case where they're equal to each
01:09:44 other, and there's one case where the first one's greater, and one case where the second
01:09:46 one's greater.
01:09:47 Hypothesis can, if properly set up, discover that those are the three things that you can't
01:09:52 three unit tests you need to write.
01:09:53 And there's like a whole bunch of values where it behaves one way, and a whole bunch of values
01:09:56 where it behaves a different way, but it'll kind of like minimize and do like a binary
01:10:00 search to find the interesting test cases for you.
01:10:04 And so I haven't, like I said, I haven't really used it myself yet, but I have been investigating
01:10:09 it, and it's kind of changed the way that I've thought about how tests can interact with
01:10:14 each other.
01:10:14 And I would, I know a couple of my friends have given it a spin on various kind of complex
01:10:19 testing projects, and it's really helped improve the reliability of their software a lot.
01:10:24 It's, it's found bugs in a way that like straight up unit testing generally doesn't.
01:10:28 Yeah, it's awesome.
01:10:29 I've definitely heard that as well.
01:10:30 And there's some amazing stuff hypothesis can do.
01:10:33 I actually had the David McIver on there on episode 67.
01:10:38 So quite a while ago, but talking about that there, and it's, I'm impressed with it as well.
01:10:41 And it pairs up with the other unit testing things.
01:10:44 Like you can use it with pytest or with Tox or whatever.
01:10:48 Yeah, it's really, it's a, it's kind of a power up for your tests.
01:10:51 It's not like a whole new testing system.
01:10:53 People have used it with Twisted's built-in TestRunner and as well as pytest and a whole bunch
01:10:59 of other ones.
01:11:00 Yeah.
01:11:00 So you touched on this just a little bit, but one more chance, final call to action.
01:11:05 You've got people caring about this deployment story.
01:11:08 What can they do?
01:11:08 Well, so aside from just like go help beware, the thing to do when you go help beware is
01:11:14 if you're the sort of person who has like a virtual machine or like the ability to spin
01:11:20 up new VMs, run a VM for some GUI operating system, whether it's macOS or Windows and pretend
01:11:27 you don't know anything about Python and you want to just write a little GUI application,
01:11:33 try to find a tutorial.
01:11:35 And in your fresh new VM with no developer tools installed, try to make an app that you
01:11:42 can run on a different VM also with no developer tools installed.
01:11:47 And the interesting thing about this is, well, the reason this is my final call to action
01:11:53 is if you do this, you will see all of the places that even if you yourself are only do
01:12:00 like web-based Python and don't do a lot of stuff with GUIs or desktop apps or mobile apps,
01:12:05 you will see all kinds of places where you know where the sharp edges are and you know exactly
01:12:12 what to do and it's not really written down anywhere and try to figure out how to take
01:12:16 that process to like the parts of the process that you understand that you know how to get
01:12:20 done the same way, the right way every time.
01:12:23 Blog about it, write about it, contribute to packaging.python.org that where there's documentation
01:12:29 for how to set up packaging and try to think of whatever you're trying to help with these issues,
01:12:34 whether it's Beware or just on your own blog. Remember where the actual beginning is and don't
01:12:43 just write tutorials for people who already have pip installed and already have Python installed and
01:12:48 already know the difference between Python 2 and Python 3. Just go back to the beginning and think
01:12:53 hard about what it would take for a total beginner to get started because there are a lot of total
01:12:58 beginners out there that do not have a friend to kind of shepherd them through that wilderness and I feel
01:13:04 like we're losing a lot of new Python programmers who if only that part were easy, they would be
01:13:09 coming to PyCon with us every year.
01:13:11 Yeah, absolutely. Well, that's a great thing for people to try. I totally think it would be helpful
01:13:16 to go through that whole exercise. All right, Cliff, thank you so much for being on the show. I really
01:13:21 enjoyed chatting with you.
01:13:22 It was a total honor to be here and see my name up in lights next to all those other luminaries that
01:13:27 you've interviewed.
01:13:28 I'm thrilled to put it up there. Thanks again.
01:13:32 This has been another episode of Talk Python to Me. Rollbar takes the pain out of errors. They give you the context
01:13:39 and insight you need to quickly locate and fix errors that might have gone unnoticed until your users complain,
01:13:45 of course. As Talk Python to Me listeners, track a ridiculous number of errors for free at
01:13:50 rollbar.com slash Talk Python to Me. Datadog gives you visibility into the whole system running your code. Visit
01:13:57 talkpython.fm/Datadog and see what you've been missing. Don't even throw in a free t-shirt for doing the
01:14:02 tutorial. Are you or a or a colleague trying to learn Python? Have you tried books and videos that just left you bored by
01:14:09 covering topics point by point? Well, check out my online course, Python Jumpstart by Building 10 Apps at talkpython.fm/course to experience a more engaging way to
01:14:18 learn Python. And if you're looking for something a little more advanced, try my WritePythonic code
01:14:23 course at talkpython.fm/Pythonic. Be sure to subscribe to the show. Open your favorite podcatcher
01:14:30 and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes,
01:14:36 Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.
01:14:42 This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it.
01:14:46 Now get out there and write some Python code.
01:14:48 Thank you.
01:15:08 Thank you.