Have you come across a GitHub repo with a Jupyter notebook that has a run in Binder button?
It seems magical. How does it know what dependencies and external libraries you might need?
And where does it run anyway? Like all technology, it's not magic. It's the result of hard work by
people behind the project. In this case, mybinder.org. On this episode, you'll meet Tim Head,
who has been working to bring Binder to us all. Take a look inside mybinder.org,
how it works, and the history of the project. This is Talk Python to Me, episode 256, recorded
February 20th, 2020. Welcome to Talk Python to Me, a weekly podcast on Python, the language,
the libraries, the ecosystem, and the personalities. This is your host, Michael Kennedy,
follow me on Twitter where I'm @mkennedy, keep up with the show and listen to past episodes at
talkpython.fm, and follow the show on Twitter via at Talk Python. This episode is brought to you by
Linode and Talk Python Training. Be sure to check out what the offers are for both of these segments.
It really helps support the show. Tim, welcome to Talk Python to Me.
Hi, Mike.
It's great to have you on the show, and I'm really looking forward to learning more about Binder.
It's fantastic to be on the show and to talk to you about Binder, what we do, how it came to be,
and hopefully how it will continue forever in the future.
I hope so. It's definitely going to continue in some sense, no matter what, where GitHub is taking
all of the public repositories and encoding them on tape and putting them in some vault in some Nordic country.
I can't remember exactly where, but it's probably already been archived there for the world.
So it's definitely going to continue, but I hope it continues actively as well.
Yeah, that sounds good. We have a contributor who lives in Norway, so maybe we should try and organize
a trip to wherever this vault is.
Yes, exactly. I can't remember where it is, which country it's in, but yeah, it's up there.
It's got to be near Norway. Pretty cool.
All right, now, I'm definitely looking forward to talking about Binder and learning more and a lot
of the behind-the-scenes stuff. But before we get to all that, let's just start with your story.
How did you get into programming and Python?
So when I was a teenager, I wanted to do what everybody 20 years ago wanted to do, is build websites.
And at the time, my dad told me, oh yeah, maybe you should check out Python.
And then they had this fantastic web server called Zope.
And then I learned how to use that and make forum software and other little websites like that.
And that's how I got into Python.
And if you wanted to be mean, never really learn any other programming languages.
If you don't have to.
I think there's value in other programming languages.
But people who know Python are in a bit of a special place because it's so widely used
and accepted, you're not forced to go learn something else necessarily.
Other than JavaScript, everybody's forced to learn JavaScript if you want to do anything on
the web.
Yeah, that's right.
So I know a little bit of JavaScript.
And I was a physics student at university and then worked at CERN as well as a physicist.
And there we write a lot of C++.
So staring at assembler code is the other thing I do.
Yeah.
So are you still working at CERN?
So no, I'm not an academic anymore.
You've hung up your tweed jacket and your pipe?
Yeah.
Actually, I'm not sure if you get those before you become a professor.
Maybe only when you get a tenure, maybe full professor, you get the hat at the end.
Yeah.
So I think three or four years ago, I left academia and thought there was no better thing
to do in your life than be unemployed and moved to Switzerland on the same day.
And I started my own business, started my own small consulting company around data science,
machine learning, that kind of stuff.
And today I work for a small company in Zurich that is called Scribble.
So like you scribble on a piece of paper and we do electronic signatures.
So if you need to sign documents which require legal signatures, you should come to us.
Okay.
Yeah.
Super cool.
What was it like working at CERN?
Oh, it was one of the best places I've worked in my life.
There's a reason the competition to work there is so crazy.
Yeah.
It's fantastic.
It seems like a really amazing place and it's one of the true cutting edge places where science
is happening these days.
And they also didn't set the atmosphere on fire or create a black hole or anything like
that.
So it was all good.
Yeah.
It's a great place to work and I really, really enjoyed it.
But at some point decided it wasn't what I wanted to keep doing.
Sure.
And so I switched to do something else.
Yeah.
You know, I said I was in academics for a while.
I'm working in math and I really loved it.
But in the end, I felt like I could just have more impact and just do more interesting,
concrete stuff with programming than I could with, you know, just math ideas.
Yeah.
I've been there.
I've been there with you.
Now, let's start this conversation at the high level before we dive down into Binder,
which is a tool we're working with and hosting notebooks in a special way.
Hopefully I got that roughly right.
Yeah.
That's about right.
Cool.
But let's start at a high level.
Just like, what's the state of notebooks today?
Now, just a little background on me.
If you don't know, I do more on the website, database side, random utility side.
Not as much data science.
Right.
Although I do pay attention to whatnot.
It's not where I live day to day.
So I'm genuinely asking, like, what's the state of notebooks today, do you think?
I think it is more exciting than it's ever been.
When notebooks started and, you know, you can discuss on who invented them.
But for a long time, it was a tool for describing what you were doing to a human and to the computer simultaneously.
Because you have the narrative text for humans and the computer text code for the computer.
And now people are, like, going crazy, you know?
People are trying to automatically turn notebooks into web applications.
People are wanting to run, like, only small parts of their notebook and make it look like it's within a normal editor.
And it's like a text file kind of thing.
How can we make a notebook, which...
Right, right.
Both, like, PyCharm and VS Code have that kind of flavor, right?
There's, like, a special comment that separates the cells.
But you're kind of in a text file, in one of their views, at least.
Exactly, yeah.
And I don't use it very much, so I'm not sure.
But I think you can then just highlight lines and say, run these lines in my file.
Right.
Which, I mean, yeah.
You can imagine doing all sorts of completely crazy stuff that way.
Yeah, it's pretty exciting.
And there's a lot of online hosted places as well, right?
Google and Azure both have ways in which you can log into your notebooks.
And it may cost some money.
They may be free.
It depends, right?
Yeah.
So there's Google CoLab, Azure Notebooks.
Various startups offer it as a service.
There's a service called CoCalc that offers hosted notebooks.
So there's a lot of people out there who do it.
And mybinder.org is one of them.
Okay.
I guess it's probably a good time to talk about Binder and, like, where does it fit in this world?
So Binder, what we offer people is that you send a link to somebody else.
And they click on it.
And if you did everything right, they can just run whatever code you wanted them to run.
For example, you wanted them to try out.
It should just work.
And it runs in their browser.
So they can do it from their tablet, from their phone.
If they want to use a laptop, they can use a laptop as well.
But they don't have to install anything.
Do anything like this.
And in that sense, it's just another notebook hosting service.
The twist is that you cannot create an account.
There is no way for you to make an account with us.
Okay.
And that means you can just send the link to everybody and it will just start, which I think is fantastic.
So people use it a lot, for example, for workshops, because everybody knows that a tutorial or workshop they went to where they spent the first half of the workshop trying to get everybody set up.
Right.
And with a service like mybinder.org, you can send them all the link.
And if the class is not ginormous, they follow the link and then they have something that they can use for the workshop.
Then you can spend maybe the end of the workshop teaching them how to set it up locally.
But you can get going.
And binder is something that you could set up locally?
Or maybe they would focus more just on here's how you set up this particular project with these notebooks and these requirements.
I guess either, huh?
But more likely the latter.
The answer is it depends what you want to do.
Imagine, like, how would I set up something that I can use for my course?
I would create a GitHub repository and I would put, for example, a requirements.txt in it.
And as human instructions, I would write, please run pip install minus r requirements.txt.
And this is such a common pattern that for mybinder.org, we built a tool that goes looking for these files and says, aha, I found a requirements.txt.
I bet you the author of this repo wanted us to run pip install minus r requirements.txt.
And in an overwhelming number of cases, that is what the author wanted us to do.
So that's what we automate.
And so the end goal is that we didn't invent any new way of setting up your software.
We tried to just spot the patterns of what lots of people are already doing.
That makes it easy to automate.
But it means also it should be fairly straightforward to then do it locally.
Right.
Because as long as you follow the same basic patterns as was intended anyway, then you're good.
But you get to avoid all of the challenge of, oh, wait, I don't have Python.
Or when I type Python, it says that print has these weird semicolon or these parentheses or, you know, some weird thing.
It's like print is not a function or I don't know, whatever it's going to say, because they have Python too.
And they didn't know that when they type Python, they got the wrong Python, but they don't have permission to install the right Python.
And there's just like, yeah, there's just layers of these challenges.
And the problem is often like that's the first thing to hit people.
Right.
Like in a couple of weeks, they're probably fine to be addressing these issues ago.
Yeah, I understand what's happening.
I'm going to fix this.
But that's not what you want to be.
Welcome to Python.
Here's your four problems to struggle through and set up.
Right.
Exactly.
And it takes an infinite or seemingly infinite amount of time to debug all these problems.
If you have a group of 30 people, I guarantee there is going to be people there who have a problem you've never seen before.
And now as the person trying to run the course, you're like, oh, my God, we're going to do some life debugging.
That's not what I wanted to show.
Yeah, exactly.
It's the way that a lot of training sessions begin or a lot of workshops begin.
It's definitely not a good impression for the students.
And it's certainly not productive time.
So this is really nice.
Right.
So you can set this up.
Typically, I don't know, all the workshops and trainings I did all had GitHub repos.
And it's like, hey, here's your GitHub repo for the stuff we're giving you.
Here's the repo.
Here's the part of the repo where it has the code that you're given.
Here's the code where I'm going to write and I'll put it in there later.
Get started.
And that's a perfect fit for Binder, right?
Exactly.
Yeah.
And we started a lot of people who work on Binder come from the Project Jupyter ecosystem.
So there's a strong focus on notebooks.
But now there are examples where you've replaced the UI of notebooks with VS Code because VS Code is also just a web app.
Actually, you can start if you wanted to.
You could start a repo, which to the users, presenters of it, it's just VS Code in the cloud somewhere.
Oh, no kidding.
Now, I knew VS Code did that.
I knew that that's something they announced under the term Visual Studio Online.
And also Coder.com was doing that as well.
But how do you guys do that?
Like, I guess VS Code will let you set that up for your own environment, not just for theirs.
Is that how it works?
So we actually take advantage of the very hard work Coder.com, I think.
I'll give them a shout out because I think they're the people who did all the work for the VS Code port or modifications.
I'm not sure what you call it.
It does run as a web app.
Right, right.
Coder.com is definitely the first experience that I've seen where that was happening.
Yeah.
And they publish their hard work as open source.
So we allow people to install that or trigger that being installed in their binder.
And then you can use it as an alternative UI.
So that was one of the things that I was thinking of here as we were exploring some of the use cases and how this is interesting and useful.
Right.
So it makes a lot of sense that this is a lot of sense.
So it's just a matter of where the server executes its kernel and whatnot.
Right.
So that's pretty easy to do, relatively speaking.
But if it's pure Python code, it's a different kind of challenge, right?
Because then how do you edit those files?
How do you interact with them?
How do you get a terminal into the environment?
It's a lot more multi-step, it felt like.
Yeah.
If you could fire up like a Visual Studio Code in the cloud instance, right?
That it's got the little terminal.
That terminal runs inside the container that's hosting it and so on.
I think that's pretty awesome.
That really expands the appeal of Binder, I think.
Yeah.
And you get a lot of the language server extension, the full, like, what is it?
Hints.
How to complete the function, what the arguments are.
All this stuff.
If you know how to install the plugins or enable the plugins you need, then you get all that good stuff.
This portion of Talk Python to Me is brought to you by Linode.
Whether you're working on a personal project or managing your enterprise's infrastructure,
Linode has the pricing, support, and scale that you need to take your project to the next level.
With 11 data centers worldwide, including their newest data center in Sydney, Australia,
enterprise-grade hardware, S3-compatible storage, and the next-generation network,
Linode delivers the performance that you expect at a price that you don't.
Get started on Linode today with a $20 credit, and you get access to native SSD storage,
a 40-gigabit network, industry-leading processors, their revamped cloud manager at cloud.linode.com,
root access to your server, along with their newest API, and a Python CLI.
Just visit talkpython.fm/Linode when creating a new Linode account,
and you'll automatically get $20 credit for your next project.
Oh, and one last thing.
They're hiring.
Go to linode.com slash careers to find out more.
Let them know that we sent you.
Do you set that up as part of, as a project owner?
When you create your binder setup, can you say, this is going to be a Python plus JavaScript thing,
so we're going to have to make sure those extensions come along for the ride?
Yeah.
So you, as the owner of the GitHub repo, you specify that you would also like to have,
I think it's called code server, the executable.
You would like to have that installed as well.
And then you format the link you share with people slightly differently so that we know to send you to this other UI.
And then, yeah, you need to also, if you know which plugins and so on to install,
then during the building phase of your binder, you have to add a few lines that we can execute to do all that stuff.
Sure. Okay. Well, that sounds very flexible and so on.
I want to talk about getting the launch binder, launch this in binder on your GitHub and all the details of how you do this.
But really, just since we're still kind of beginning, let me just ask you real quick,
how did you get started with binder in this whole project anyway?
That's a good link back to my previous life at CERN, where as a student and as a postdoc also,
we write so much software to analyze our data and it does fairly complicated stuff.
And so when you see somebody else doing something cool, you're like, oh, I wish I could do that as well.
But if you ask anybody in particle physics or at CERN to share their code,
and then it only takes you, let's say, a week to get it running, doing what they were doing.
You get this thing, you compile that from source, and then you do this,
and oh, you got to get this right version of the header.
Yeah. And so if it only takes a week, people are super impressed and super happy.
But for me and a bunch of my friends, it was just, we were like, no, this has to take like an hour maybe.
It's too long. If we just spend a week to figure out how to run it before we start modifying it, it's too long.
So at some point, we decided we need to do something about it or shut up complaining.
Yeah. Yeah. That's kind of my philosophy as well.
It's like, it's fine to complain and criticize, but it should come with a, but you should do this instead.
Or here's how we're making it better, right?
That's great.
So fortunately, there was a, or there's a yearly hackathon hosted at CERN called the WebFest.
And we're like, okay, going to take three days to try and build something.
And at least we will have tried.
So we started and the idea was to build something very similar to what we now call binder.
What was exciting is that on the Saturday, so it's a weekend event on the Saturday morning or afternoon.
I read an email from a Jeremy Freeman, who is the inventor or creator of my binder.org announcing my binder.org.
I was like, oh, that sounds very much like what we're trying to do here.
So from day one, that was, yeah, it was exciting to see that other people are trying to do the same thing.
Yeah. For me, I then took a detour, just doing some more science and lost my, my connection to this.
And I think it was three years ago, two or three years ago, a PyCon, somebody said, we're trying to restart my binder.org.
We've seen you did something similar.
Do you want to be involved?
Okay.
And since then, I've not managed to escape.
They pulled you back in.
Wonderful.
Cool.
Well, yeah, I mean, that totally makes sense.
It sort of fits with that overall theme of reproducible science and that kind of stuff, right?
Yeah.
If you can't create the environment to rerun or play or experiment with the code, well, that's a pretty bad shot against reproducibility.
Yes.
I will leave it at that.
For sure.
All right.
So the way that I learned about binder is I would go to various GitHub repos and I would see a little launch binder badge, right?
Like GitHub has all these little cool, I guess it's not really GitHub.
Like you can just put all these little badges on top of your readme that appear.
I guess it's a convention in GitHub.
It doesn't come from GitHub.
And it might say, this thing requires Python 3.5 or above, or the continuous integration is working, or there's 94% code coverage, or it could say, click here to launch this project in binder.
Now, to me, that was always really impressive because, you know, it's not enough to just take the code from the repository or the notebook from the repository and just run it.
Right.
As you described, there's all these requirements potentially, right?
Like if I'm using SciPy, you know, maybe that's not installed or more likely using some edge package that nobody knows about, or you need a certain version or whatever, right?
There's a lot of specific requirements that have to happen.
So to me, it just looked kind of like magic.
Like, oh, you can click on this button, and then this thing runs, but I have no idea how it might run because it seems like the environment where it's going to run should be so specific.
So how does this happen, right?
And I guess, yeah, give us the rundown of how that happens.
There's a pretty good little UI that you can get started with over at mybinder.org that talks you through it.
But let's talk about what happens there.
We use a little tool we built called repo2docker, and it does exactly what the name suggests.
It will take your repository and will look at it and say, if there's an environment.yaml, it will go, okay, we need to install Python.
Well, we need to install Conda, and then we need to run whatever the Conda command is to get all the stuff which is listed in the environment.yaml installed.
And that really is 80% of what repo2docker does is it will look for these very well-known files.
In the Python world, it's requirements.txt, environment.yaml, setup.py.
Does it know, like, pipfile and pyproject.toml and those things?
We have some support for both of those as well.
It doesn't seem to be used as much.
So I would say it's something that could do with more love.
Sure. Okay.
And then we have the same for the R community.
They have a whole bunch of magic files that the community has agreed on using as a format for specifying things.
The Julia community.
Because the notebooks will support a bunch of different kernels these days, a bunch of different languages and runtimes.
And so I guess one of the questions is, when I create a Python project, I don't typically tell it, you're a Python project.
I mean, I guess the closest I ever get to that is I will have the gitignore be the Python default gitignore.
But other than that, when I create a new project, I don't tell it it's Python.
I just put Python files in there.
But I might also put JavaScript files or less files or other things that could confuse you guys.
So how do you, when you look at one of these projects, know, oh, this one's Python, that one's Julia?
We don't try and guess that so much as we have a list of files that we recognize.
So like, yeah, requirements.txt.
And when we see that, we say, okay, now add like the commands to install Conda, add the commands to install these pip packages to a Docker file.
And we build a Docker container for you.
I see.
So for example, if you see like a requirements.txt, you're like, aha, Python.
Exactly.
We don't try and like look at the files in the repo in general and try and deduce.
Okay, there's 80% Python files and 20% JavaScript.
Let's install Node and Python 3.7 or something like that.
Yeah.
It always makes me, I guess, frustrated or something.
When I see that, the GitHub estimation of what the project is, you know, you can like click down and the languages and it'll show like, you know, 70% this, 20% that.
Because sometimes there's just some huge file, right?
Like maybe I have one notebook, but there's like a ton of output in that notebook.
But it's otherwise pure Python straight files, .py files.
And it'll say, this is like 80% Jupyter.
Like, you know, not really.
It's more like output from Jupyter that you're counting or I'll decide, you know, I want to bundle up some node packages and put them in the repo so I don't ever have to worry about them vanishing or changing or ever.
Just put them there and they're fine.
And then it becomes a JavaScript project because, you know, it's got more JavaScript than it does Python, but it's not really.
It's just like the libraries, right?
So I can see that that would be very fraught with error.
Yeah.
So instead, the slogan we have is we reward community best practices by automating them.
We try and encourage people to just be boring and do the mainstream thing.
And in exchange, we can automatically build a Docker container or Docker image for them, which does what they want to do.
Right.
So one of the main things and the way you solve the challenge I started outlining in the beginning is like, it seems like magic.
Why is this thing that seems like it has a bunch of dependencies and is very specific?
Just run when I click it.
And it's because you've looked at the repository.
You've followed these best practices.
You've sort of guessed at the best practices and found what you're supposed to do.
And then you defined a Docker file that then built an image that then you run as a container when you click the button.
That sets up that environment, right?
Yeah.
And then, and all as a user, all you need to bring is something that is like a web browser.
And then at the very end, we connect you to it and off you go.
And to that, you have an environment.
So that's pretty interesting.
Where does that run?
Well, we're lucky to have four clusters around the world now, which is fantastic.
So we rely on people donating resources to run all these containers for people.
And we have one cluster in Google Kubernetes engine.
We have one at OVH, which is a European cloud hoster.
We have one sponsored by the Turing Institute in London.
And we have one bare metal Kubernetes cluster at a social science research institute in Germany, in Cologne, called GISIS.
So they are really at the front, you know, none of this cloud hosting business.
We run our own Kubernetes cluster.
That's right.
You go in there, you pull the cover off of the 1U server, and you can just see Binder right in there.
Yeah.
That's really cool.
Are you looking for more or is it, is that enough?
Is it okay?
So our master plan for how to make this sustainable is to encourage more and more research institutes or cloud providers to host a small chunk of mybinder.org.
Because that way, each individual contributor doesn't have to pay a cloud bill, which is hundreds of thousands of dollars, but only maybe $20,000.
And if you're a big research university like MIT or University of Oxford or someone like that, spending $20,000 on something which benefits you because you can use it at your university for your researchers, but also benefits the whole world, it's still a difficult sell.
It's a much easier sell than if we come to you and say, do you have $200,000?
And they're like, oh.
In any currency, no.
Yeah.
People will just laugh at you and show you the door.
So that's the plan.
So the short answer to your question, are we looking for more, is yes.
It would be very interesting to add more clusters to this.
It should be easy to do technically now that we've gone from one to four.
It should be easy.
Pretty much after you go from one to two, that's the hardest step.
Right?
And then onward, it's not necessarily easy, but it's the...
Going from a very bespoke, it's all matching this to like, now we have multiple environments.
Well, that's a pretty big step, I would say.
Yeah, that's true.
It comes with its own challenges because now you have four times as many things that can go wrong or idiosyncrasies to deal with.
But it's great to see that we can run on four so different Kubernetes flavors.
And I think it's great because it keeps us honest when we say we are not building something which is tied to any one cloud provider and their secret source.
So you can really take it and run it at home.
Right.
Yeah, that's super cool.
So basically, if you have admin access, like Binder has admin access to a Kubernetes cluster, it can create containers and pods and then spin them up and spin them down.
And like, it's basically just managing a Kubernetes cluster wherever that happens to run.
Exactly.
Yeah.
Okay.
Yeah.
That's what we do.
Yeah.
That sounds very exciting, actually.
That's cool.
Now, one of the things that's probably worth mentioning is if I have a GitHub repository and I go through this effort, this minor effort described at mybinder.org to like set this up and register it and whatnot and get my little badge so people can run my code there.
That's all well and good.
But what happens as I make changes to my GitHub repository?
Like, oh, I need a new version, a new library I'm going to add, or we're going to update this code, but it's going to require some underlying fundamental change to the environment.
Every time you make a commit to your repository, when you then launch it, we check in our cache, do we already have an image for this commit of this repo?
And if the answer is no, we will rebuild it or build it again.
Right, right.
Like probably you tag it by like git commit hash shah or something like that, right?
Yeah, exactly.
Okay.
And that's nice because anytime you change your repository and add a new dependency, we will just automatically rebuild it next time.
It has the disadvantage that it can take quite a long time to build your repository, depending on what crazy stuff you're trying to do, how many dependencies you need to install and compile from scratch.
It can take a long time to build the Docker image for your repository.
Right.
Do you do anything like layer this?
So with Docker, you can have like layers of Docker files and dependencies and it will just, it'll cache all of them and only build the changes.
Do you do anything like here's the layer that is the dependencies of this project?
And here's the layer that actually has the code because the dependencies probably change infrequently, whereas the code is probably, you know, 10, 100 times more likely to change.
Right.
And the slow part is not getting the code.
The slow part is getting the pip install dash R from their Ubuntu or whatever.
Yeah.
So we try and be clever about how we order the layers and the Docker.
Right.
Because that's the trick to making it do the minimum work when a change happens.
Yeah.
What makes it tricky is that a lot of package managers allow you to do arbitrary stuff.
We have a few, hopefully enough pieces of code that inspect your requirements.txt to try and figure out, are you referring to stuff in the rest of the repo?
Yes or no?
Because if you are, then we need to update the whole rest of the repo before we run your file.
If no, then we can cache it.
So, yeah, we try and be clever on that front.
Right.
Because your biggest expense, at least I think, there's actually a Jupyter notebook that talks about this, which we could get into, which is fun.
But your biggest expense is compute, right?
Yes.
As opposed to storage or bandwidth or something.
Yeah.
We do have a fairly large Docker container registry.
And the funny story about it is that for a very long time, we paid no attention whatsoever to it.
And then one day in this notebook that you were referring, which shows you how much money we spend on which line item in our cloud build, we started noticing a new one.
And we're like, what is this?
Why is it getting bigger constantly?
And it turns out that there was, I think, tens of terabytes of images in our container registry.
And that is the level at which it starts being noticeable on our chart.
Right, right, right.
That's like $20,000 or $10,000 or something like that.
But it's a non-trivial number.
Yeah.
So I actually haven't looked at our billing costs in quite a while.
Before we had, when we only had two clusters, so that's probably at least half a year ago or so, we would say that it costs between $80,000 and $100,000 in Google Cloud cost to run mybinder.org.
Yes, the vast majority of that is paying for the virtual machines.
Right, right, right.
If you're a regular listener of the podcast, you surely heard about Talk Python's online courses.
But have you had a chance to try them out?
No matter the level you're looking for, we have a course for you.
Our Python for Absolute Beginners is like an introduction to Python plus that first-year computer science course that you never took.
Our data-driven web app courses build a full PyPI.org clone along with you right on the screen.
And we even have a few courses to dip your toe in with.
See what we have to offer at training.talkpython.fm or just click the link in your podcast player.
I guess that's worth talking about as well.
So there's a notebook, which I'll put the link into the show notes.
Basically, it's showing you the real-time, semi-real-time.
You can adjust it.
It's a notebook.
The cost of over the day, over the week.
And it's a non-trivial number, right?
Like, I'm on the weekly cost, and it's showing, on average, maybe $1,000 a week plus a little bit more.
You know, that's...
I know open source is doing well these days, but that's a lot of money, $1,000 a week for compute.
So where does that money come from?
You talked...
You sort of hinted at it before, but where does it come from?
So the particular notebook there only tracks the cost we incur from Google.
Okay.
From the Google Cloud.
Which is, like, not necessarily a quarter, but one of the four, right?
Yeah.
It's probably the biggest of the four.
So I'll talk about how that bill gets paid.
At the very beginning, we were fortunate enough to have a grant from the Moore Foundation,
which included a chunk of money to pay for the bill.
And that was several years ago.
Now, we have friends, our benefactors at Google,
who so far have been able to justify why Google should give us credits.
I see.
Are high enough to pay the bill.
So that's fantastic to see.
So in some sense, Google's donating that compute to the project.
Yes.
Yeah.
Have you considered reaching out to the other big groups like Azure and AWS?
See if they want to be part of that party to get their name in some little halo effect?
Yeah.
So, I mean, that's how we got the cluster OVH, which is a European cloud hoster.
They donate the compute resources for that cluster.
The Turing Institute's cluster runs on Azure cloud.
And I don't know exactly how the invoicing works there.
But I would imagine that at least in some way it's sponsored or supported by Azure.
The fact that the Turing Institute has enough spare money to finance such or donate resources for such an altruistic project.
Yeah.
Okay.
It's really cool because it really shows you that, you know, this is, it's not free.
And it's, I mean, at the core, right?
Somebody, those images have to get built somewhere.
They have to, the Docker containers and pods, Kubernetes pods have to run somewhere, right?
And this is, and also probably, I know it's probably a small percentage of the people that touch the button,
but it's still got to be a non-trivial amount of like real computational stuff happening, right?
Like it's scientific in large part, I would imagine.
Yeah.
So luckily for us, most people who start a notebook spend a lot more time thinking and reading than running code.
Yeah.
So we can cheat and overcommit our CPUs by quite a large factor.
Yeah.
I would think.
Yeah.
But yeah, I mean, they're not sitting there idling.
No, I'm sure.
Also, this doesn't help for the Python file and VS Code angle, but it might help for the notebooks ways.
Like a lot of those notebooks come pre-populated with the last data they had run, right?
You don't have to run them to read them initially.
Yes.
Is that true for your setup or is that just true for GitHub?
No.
So if the notebook in your repository has the output still in it from the last time it was run,
then we will show it to you because we use standard JupyterLab or Jupyter Notebook.
Right, right.
A UI to show it to you.
And so that way you get something to read before you ever try and run code.
Cool.
Yeah.
So maybe people actually load it up and never actually run it or they might not run the expensive bits or something.
So that's got to help as well.
Yeah.
So then it's a very expensive way to view your notebooks.
It would be good if you just want to read it.
Just read it on GitHub or something, right?
Yeah.
If the GitHub viewer works well, then that's good because that's much cheaper to run than starting up a Docker container.
For sure.
And, you know, I guess there are definitely benefits that you have on interactivity as well, right?
Like GitHub doesn't, it's kind of amazing that you can look at an output of a notebook and it looks like it ran,
but it's just the cached version or saved version of whatever was before.
But, you know, a lot of those have like the little widgets, those IPy widgets or whatever.
Yeah.
You have like little sliders that you can play with and like adjust it.
And in order to do those types of explorations, even if you're not writing code, but you're kind of exploring parameters,
you've got to have a real life system to do that, right?
Yeah.
You need some kind of kernel connected to it to run the computations that are needed when you slide the slider to 11.
Right.
Yeah.
Cool.
Now, I think it's awesome that all these people are donating the compute to the environment and making this available to the entire world.
But there might be situations where people want this type of system, but they, for some reason, can't put their data publicly out there or they don't want to link to it or they just want to keep it more controlled.
Is there a way to take what you guys have built and say, create a mine, mine, all mine binder.org rather than, you know, like an internal version of it that's not just out there on the public cloud?
Yeah.
So the software that is behind my binder.org is called binder hub, like Jupyter hub, but binder hub.
And that's open source, like all other Jupyter projects as well.
And you can deploy it yourself on your compute with your credit card.
And then you can access private repositories.
You can limit access to your binder instance.
So you have to log in instead of right now where it will, it's completely open to the public.
Sure.
Yeah.
So basically, once you have those links, you can just visit it.
Like that's the point.
You already emphasize that, right?
That you're not even supposed to have an account, which is kind of the opposite of I need to keep this private.
Exactly.
And also because we take compute, which has been donated to us by people.
We say, if you have private repositories, you probably also work for somebody who could pick up the bill themselves.
So it's a political decision that we've disabled these features for my binder.org.
But you can take the same software and run it yourself.
And then you can access private repos.
So basically, there's no technical limitation.
But right now, in order to run one of your repositories on mybinder.org, it has to be a public repository.
That's right.
Because that's the zen that you guys are going after.
That's the overriding philosophy of what you're doing, right?
Yeah.
Okay.
Yeah, that sounds totally reasonable.
Now, I guess this repo to Docker is also pretty interesting, potentially on its own, right?
Like, it's cool that you guys are using it for capturing these environments.
So you can run them on mybinder.org.
But is that something people would find useful outside of that use case?
Yes and no.
There's nothing stopping you.
Or we encourage people.
For example, when they...
So you can run repo to Docker locally on your laptop.
And it will perform its little magic trick just as well as it does online.
Right.
We encourage people to do that, for example, if they're trying to debug why their binder isn't building or why it isn't doing quite what they want it to do.
Oh, interesting.
So if things are not working right, you're like, this container won't build or it's not finding the files or whatever it is, right?
The volumes aren't mapped right.
The ports aren't mapped right.
You can play around with repo to Docker locally and get a better shot at figuring that out, huh?
Exactly.
Because you can see a lot more of the logs.
The turnaround is potentially much, much faster because you have a more powerful machine.
You're just more direct contact with it than if you have to control it via some web form with the log automatically scrolling paths and so on.
Right, right.
I'm going to go do another commit to the repo to force a GitHub webhook to go off and make it happen again or whatever.
Yeah.
Exactly.
So you can use it locally.
The disadvantage is that you probably don't have as big a library of cache Docker image layers on your laptop that repo to Docker uses.
Potentially you have lots of them already because Docker is very good at filling up your hard drive.
Right.
It won't clean up any of those cached ones unless you run like a Docker cleanup.
I forget the exact command.
But yeah, it's really easy to fill up your computer with Docker images that are stale cached results, right?
Exactly.
So you can run it locally.
I do run it locally once in a while to just get the environment that the author of the repository had in mind.
However, what I'm finding is that if the repository builds on mybinder.org or with repo to Docker,
because it's in some way very simple minded what repo to Docker recognizes,
the instructions to do it by hand are also fairly straightforward.
So if you're comfortable using Conda, then it's quicker to make yet another Conda environment and just do what the author wanted you to do.
And because you can try whether it actually works by clicking on the badge in the readme and seeing it run on mybinder.org,
you're like, yeah, I'm pretty sure the instructions are complete.
And I'm not going to spend two hours and then find out that they forgot something.
Sure, sure, sure.
That's pretty cool.
I guess maybe if it depended on Linux and you were on Mac or something like that,
that might be a quick way to jumpstart a Docker container without knowing too much about Docker.
But yeah, if it's a kind of standard environment, then there's probably not a huge benefit.
Yeah.
If you're on a different flavor of Linux or whatever, then yes, automating the build of the Docker container and have it run locally is great.
And it is something people do, but it's, I would say, just not as convenient as clicking the link.
So that's why not as many people are doing it.
Yeah, for sure.
It's easy.
Can I get a public repository into mybinder.org that didn't decide to be in there?
And what I mean is I've got to go through mybinder.org and put in the repo info and stuff in general to set this up.
Could I just go, this one doesn't have a link, but I'm just going to give it to mybinder.org anyway and see what happens.
Yeah.
Yes.
You don't have to be an author of the repo or have any special rights on the repo to launch it.
Right.
So with no account and it's required to be public, right?
It's pretty hard to not fill out the form at mybinder.org with the info you want, right?
Exactly.
And a lot of projects will just work.
Yeah.
Because of the practices that you follow, right?
Exactly.
Yeah.
So then you can open a pull request and add the badge to the readme.
That's exactly what I was thinking.
Yeah.
So if you find a repo that should have a launch in Binder and yet it doesn't, a real nice way to make a simple contribution would be to go fill out mybinder.org.
If it works, go do a PR with the details required.
I mean, you could just edit the readme file on a branch, put the little icon there and submit that as the PR like here.
I was missing this.
I fixed it.
Yeah.
That's a super contribution for the project.
It's a good way to get started and it will help whoever comes next to the project because they'll see the badge.
And even if they don't yet know what mybinder.org is, they might click it and then they can run the examples.
Yeah.
It seems like a really nice, generous thing to do and super easy.
Well, cool.
So we're getting near the end of our time and I was going to ask you just a really quick sort of high level question.
Looking back a bit on our conversation and your experience over time.
People recently have been asking me, why do you think Python has become so popular in the data science and the scientific computing space over the last five years or so?
You know, someone who worked at CERN and has been probably more involved in that than I have in a lot of ways.
What are your thoughts?
Why Python?
Why did it become so much more popular recently?
I think the short answer is I don't know because I've, since I was 15, thought Python is a pretty good language for programming.
Finally, everyone agrees with me.
Exactly.
So I don't know what really what happened.
I think part of it or why I think why Python, not some other language is there's a quote somebody else told me is you invite people to a job interview and make them write something on the, do some coding on the whiteboard or something like that.
And they will write, even if they are, I don't know, C++ or Julia or whatever programmers, often they will write in something which looks very much like Python on the whiteboard.
They will not put all the curly brackets.
Or if you read Wikipedia, often there will be about algorithms, there will be a little section in pseudo code and you can almost copy and paste that and it will run.
Right.
So I think that's a killer feature in some sense.
It makes it just so much more accessible to people who don't think of themselves as programmers.
They are, they work in an insurance company and they want to do some data science.
They don't think of themselves as programmers.
They are, I don't know, actuaries or.
Right, right, right.
I think that agrees a lot with my general working theory is that Python is one of these special languages where it's as simple as possible to get started with like a tiny bit of computation.
You don't even have to have a function, you know, forget compiling, linking, headers, static main voids, just like here's the three lines I want.
I'm going to use those libraries.
I'm going to do this.
And so people easily get into it in the beginning.
But then unlike a lot of easy languages, you don't really outgrow it.
Right.
It's not like, well, you can't use Python anymore because now we're doing astronomy or whatever.
I was like, no, it's just, you just keep using the libraries and you can keep adding more computer science like concepts, functions, and then classes, then generators, then whatever.
So I feel like it sucks people in who don't believe, just like you said, that they're programmers.
They believe they're biologists, astronomers, physicists, whatever.
But then it's kind of got this, like, well, I already know this.
It's totally working.
Why would I leave and pick up a harder language?
Because there's just kind of this gravity.
Like, once you get sucked into it, there's no reason to get kicked out of it because you can just keep growing with the language in the libraries.
That's my theory as well.
Yeah.
Yeah, I think so too.
And the fact that we can put a nice user interface in the programming language that you use Sense onto big, trusty Fortran and C++ libraries that have been around to do really heavy lifting, linear algebra and whatnot.
I think that is fantastic.
If you imagine Python didn't have that feature, then we would be stuck.
We'd have to write all this stuff from scratch.
Yeah.
Like this, we can put a nice UI on Fortran code and get all the benefits of having well-tested Fortran code do crazy linear algebra for us.
That's perfect.
But not think about it ever again.
Nice.
All right.
Well, yeah, that was definitely a good, insightful answer.
I like it.
All right.
Now, before you get out of here, before we call the show, you've got to answer the final two questions.
So, if you're going to write some Python code, what editor do you use?
Today, I use Atom.
Okay.
Well, cool.
Yeah, Atom is neat.
My favorite editor probably is Emacs in a console.
But at some point, I had to admit that I didn't want to spend as much time as I used to trying to understand how to get JavaScript tools to hook into my editor and auto-formatting stuff.
So, yes, I use Atom now.
Nice.
Very cool.
And then notable PyPI package.
Maybe not something necessarily super popular, but something like, oh, I saw this and it was so cool.
You should check it out.
Need to think.
While you're thinking, let me tell you about one thing that I ran across.
It's not exactly that, but it's actually super cool.
And I think it's relevant to the audience who would be interested in this topic as well.
So, have you heard about Carnets?
C-A-R-N-E-T-S?
Carnets?
No.
So, this is a standalone Jupyter Notebook environment that runs on iOS.
Not like the browser sees it, but it actually has NumPy and SciPy and all that stuff installed and Python executing disconnected on iOS.
So, we could put that one out there for sure.
And that's cool and it's open source and people can go check it out.
It does uncertainties.
So, maybe, yeah, it is actually just called uncertainties.
Oh, nice.
That's a good name.
Yeah.
So, it lets you put in numbers with uncertainties on them.
Okay.
And then you can do complicated computations on it and it will spit out, you know, the answer is three plus or minus 1.7.
Right, right.
Because if you have plus or minus 1, but then you square it and then you add this other uncertainty to it, right?
Like, the propagation of uncertainty is not obvious.
It's uncertain even.
Yeah.
I mean, it's one of these things where it's not difficult, but it's hard to do right.
Yeah.
You very easily make mistakes.
So, yeah.
That's cool.
Uncertainties.
That's a cool package.
Okay.
Uncertainties.
Nice.
Another one that's kind of in that realm is Pint, which lets you do different units and multiplications and divides and whatnot.
It's pretty cool.
Okay.
Very cool.
That's a good recommendation indeed.
All right, Sam.
Well, we're about out of time.
So, maybe a final call to action.
People are excited about mybinder.org and this whole concept that we talked about.
What do they do?
Try it out.
Tell a friend about it.
That is, I think, an easy thing to do.
And you can get it done because it's easy.
Yeah.
It looks like you've automated a lot and it looks really not hard at all to get started with.
Yeah.
And, of course, we would be super happy if people find mistakes or want to add new features if they stop by and make code contributions, make contributions to the documentation, or help us deal with the fact that there's so many people who use it.
If you have questions, you can contribute to mybinder.org, especially if you can't program.
That's actually an asset because there's lots of people who know how to program, who help run mybinder.org.
But explaining how it works, advertising it, giving talks about it, all that kind of good stuff.
Adding launch and binder to various repositories that should have it.
Yeah.
For example, yeah.
Yeah, those are pretty straightforward things to do.
Awesome.
All right.
Well, it was great to learn more about mybinder.org and what you guys are up to.
Thanks for being on the show.
Thanks for taking the time to talk to me.
Yeah, you bet.
It was great.
Bye.
This has been another episode of Talk Python to Me.
Our guest on this episode was Tim Head, and it's been brought to you by Linode and Talk Python's online courses.
Start your next Python project on Linode's state-of-the-art cloud service.
Just visit talkpython.fm/linode, L-I-N-O-D-E.
You'll automatically get a $20 credit when you create a new account.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our Everything Bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
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.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.