Python is often described as a batteries-included language and ecosystem.
In fact, that's been taken so far, there's even a delightful Easter egg in the Python REPL.
Just type import anti-gravity to see what I mean.
Where do these powerful packages come from?
Well, the Python Package Index, or PyPI.
On this episode, you will meet Nicole Harris, Ernest Durbin III, and Dustin Ingram.
They were part of the team that has just launched the new version of PyPI over at pypi.org.
Not only have they given us a great new website around packaging and Python,
they have laid the foundation for innovation in the space for years to come.
This is Talk Python to Me, episode 159, recorded April 18, 2018.
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 ActiveState and Codicy.
Please check out what they're offering during their segments.
It really helps support the show.
Hey, everyone.
Before we get to the exciting news about the new PyPI launch,
I want to tell you about a brand new course we just launched.
It's called Python 3, an Illustrated Tour.
And it's a five-hour visual and code-based tour of all the features in Python 3.
It's written by Matt Harrison, who has authored 15 technical books and is a best-selling Python author.
Check it out over at talkpython.fm/illustrated.
And if you get the course this week, we'll throw in Matt's newest Python book for free,
which is a perfect complement for the course.
And if you have the Everything Bundle already, then you should definitely check out the course
because it's included in your bundle, and you can just go take it.
I hope you love this new course.
We have many more coming down the pipe, and I'm looking forward to sharing those with you as well.
Now, let's hear about the new PyPI.
Nicole, Dustin, Ernest, welcome to Talk Python.
Hey, thanks.
It's great to be here.
Thanks for having us.
Yeah, you all have done something amazing.
It's almost like you've caught a unicorn in the mythical sense of, like,
there's been this talk of a new PyPI website and infrastructure for so long, and then, like, here it is.
And you all are, you know, really central to doing this.
So I'm super excited to talk about this, the rollout, the technology behind it, new features we're going to get.
We have already gotten things like that.
But before we get to that, let's start with your story just briefly since there are three of you.
How do you get into programming Python?
Nicole, go first.
I started off with programming generally about 10 years ago.
My degree is actually in film and photography, and I wanted to make a website to put up my animation works.
And that kind of led me to HTML and CSS, which is still my specialization.
And from that, kind of, I became what was back then a sort of generic web designer before we had lots of different specializations.
And then my husband is actually a Python programmer.
So that's how I got involved in the Python community.
And I don't program in Python very much these days, but I do sort of dabble in it every now and again.
Yeah, yeah, very nice.
Ernest, how about yourself?
I graduated from school with a degree in physics and math in the sort of peak of the recession back in 2007-8 era.
And eventually conned my way into a job as a business analyst.
And at that point, I started programming in order to stop using Excel.
And then years later, I've come to this point.
Very cool.
I love how you sort of took your career and just kind of laddered it up or leveled it up.
Right?
Like, I'm math and physics.
I'm not going to work at CERN.
So now what?
And then you just, you know, work your way up that ladder.
Like, I also, I've said this several times on the show, of course.
But I also was working my PhD in math and then kind of abandoned for my self-taught developer path many years ago.
Dustin, how about you?
Yeah.
So I went to school for computer science.
And I'm not really sure when I first was introduced to Python.
But I do remember at some point, you know, after having done a lot of C and C++ in my studies, coming across this Python thing and being like, oh, this looks so much nicer.
So I slowly sort of worked that in as much as I could.
And, yeah, now I could probably call myself a Python developer.
That's pretty awesome.
So you're like, this can't work.
There's only five lines, right?
Like, in C++, I'd definitely have to, like, write a whole app around this.
So, but it works.
It's the beauty of Python, right?
Nice.
Okay.
So first of all, I want to start with a big piece of news, which we've been hinting at, or I've been hinting at, but has a particular date.
So the new PyPI.org, which, by the way, for a while is PyPI.io.
I want to ask you about that.
But PyPI.org has launched and Legacy PyPI is shutting down April 30th, right?
That's on the blog recently announced.
Congratulations.
How do you all feel about that?
Thanks.
I think we're super excited.
Yeah, I don't think there's anything negative to say about it.
I mean, it's just to see the culmination of the effort come to, like, a moment has been incredible.
And there'll be another sort of celebratory secondary on the 30th when we sort of say goodbye to something that's been around for so long.
Yeah.
We're going to have to get used to less gray, more red, or more blue, right?
It's blue, isn't it?
Is that your work, Nicole?
It sounds like you might have done a fair amount of the redesign HTML bootstrap type of thing.
I joined the project back in 2015 because Donald, who's our lead developer, I think you've already met and interviewed.
Yeah, he's been on the show twice.
He's great.
Yeah.
So he put a call out basically to say, I'm rebuilding this thing, but I'm terrible at design.
So is there anybody out there who can help?
And I got in touch, and so that's kind of how I ended up in charge of both the user interface, the user experience, and I also took charge of the HTML and the SCSS code base as well.
So kind of front end minus JavaScript.
Yeah, that's really cool.
Anything that looks good is Nicole's doing and not any of the rest of us.
I got to say congratulations because I do feel like it looks really modern, not overly designed, but it definitely feels like, you know, 2018.
Somewhere you want to be.
It doesn't look old, neglected, gray, and just like default, like browser font style, right?
Like it's really, really good.
And I think on one hand design, it's how much does it matter, right?
It's like a package warehouse.
But on the other, I think it sends a message to the community like this place is special.
We care about it.
We put in effort to style it and make it really look good and be usable, right?
Yeah, and I think a lot of the design focus for me was thinking about how much Python is a teaching language and how for how many programmers it might be their first experience dealing with a package index.
So it was really important to me that it looked friendly and it reflected the values of the Python community.
So both in terms of the design, but also in terms of the accessibility features that we've built into the front end code base.
We're trying to make sure that it's serving as many people as well as possible.
That's cool.
And do you mean things like ARIA, like screen reader indicators and stuff like that?
We've done a reasonable amount of work on that so far and we've actually got an accessibility audit happening this week as well.
So there'll be more improvements on that side.
But given there's so many users of the site currently, it's just from a percentage perspective, you know, that there is going to be a portion of those users who are going to be using assistive technology.
So we need to be looking after them.
And I think that reflects the Python community and the way that we go about things offline as well.
Very nice.
Let's touch on the contributions the other two of you have made.
So Ernest, what was your major part in this whole project here?
Sure.
So since about 2013, 12 or 13-ish, I've been contributing to the Python Software Foundation's infrastructure.
And so this is the servers and services behind python.org, www.python.org, mail, wiki, etc.
And so PyPI is one of the largest and most used of the services provided by the PSF.
And I got involved primarily just keeping things turned on.
In 2013, there was a large contribution that I did to modernize the infrastructure that hosted the old PyPI.
And over the past few years, I've continued that work in adding to the reliability and telemetry of PyPI.
And so with the warehouse project, Donald, Stuffed, and myself both sort of took a step back and said, if we were going to do it all over again, how can we make sure we have excellent infrastructure for warehouse?
So my main contribution in the most recent work has been a mixture primarily of the infrastructure behind PyPI.org and also some code changes that features as well as just stuff to make it more compatible and easier to operate and do so reliably.
Yeah, very cool.
Dustin, how about yourself?
Yeah, I joined the project just as a volunteer contributor about two years ago.
I think I just had happened to come across it looking at Donald's GitHub and I was like, wow, this is a really usable PyPI, but it's not finished.
And, you know, as a new contributor, I was pretty just attracted to it because I could actually contribute to it.
Legacy is Behomoth and has very few tests.
And even to run it locally, you have to actually go in and comment out a bunch of code.
So it's really abrasive for new contributors.
And warehouse is not like that at all.
So I sort of started making some contributions, doing some like Elasticsearch tuning and that kind of thing, and just adding elements to the UI that weren't there before.
And so I think I learned this to work necessary and also making a lot of contributions to the just tooling ecosystem.
So that's other projects like Twine and pip and things like that, just to work with the new PyPI.
Yeah, very cool.
Now, the three of you are here, but you all have mentioned Donald Stufft, who's been spearheading this and deserves a lot of credit as well.
So congratulations to him.
Who else?
Is there anyone else who we should sort of give a shout out to while we're talking to you all?
Yeah, absolutely.
I want to point out Sumina.
Sumina, I actually have never tried to pronounce Sumina's last name out loud.
So Sumina H took an incredible role in the project management and leadership over the past few months and bringing this together.
Absolutely.
It was a huge driver in a lot of the work that we did to encourage and welcome and have sticky contributors to the project.
So I sort of said this a few, I don't remember when exactly, but there was a point where whenever Donald or I would tweet the PyPI team, what we meant was whichever one of us happened to have done something that week or that month with PyPI.
And I attribute personally a lot of the reason why when I say the PyPI team now, it's a collection of more than like five, I mean, it's probably close to like seven or eight people who are regularly contributing and there's a team.
And when I say that now, I say it earnestly, pardon the pun.
But yeah, so Sumina must be, in my opinion, must be sort of encouraged and called out here as well.
Yeah, I just want to say, I don't think the project would have been as big of a success as it was if Sumina hadn't been sort of organizing and hurting us along the way.
She did an exceptional job.
So glad to hear.
So congratulations to you all.
So I have two sort of burning questions around the new PyPI.org.
Three.
Let's start with a simple one.
We have PyPI.python.org slash PyPI, which is a crazy location on the internet because why the duplication?
But anyway, we have that.
And then for a little while, you had PyPI.io.
And then you switched to PyPI.org for like where the actual new warehouse, the new Python package index lives.
Why did you change it halfway along the way there?
Sure.
This is a good story.
So it started at Python.org slash PyPI is where it initially lived.
And then it moved to PyPI.python.org slash PyPI because it was easy to change the domain and not so hard, not so easy to change the URLs.
Right.
It was more easy to separate it like the infrastructure to another server rather than behind the load balancer or something like that.
Right.
Mm hmm.
Okay.
And then eventually PyPI.io, I don't remember when we got it, but we've been using that for sort of the internal domain for PyPI for a long time.
So for the actual servers behind the scenes.
And when warehouse started to get to the point where Donald was like, oh, man, this is real.
We can start deploying this somewhere.
We went PyPI.io because we had it.
The frustrating part is that PyPI.org was not owned by the PSF or Python community member for a long time.
So basically, the reason why it switched midstream was that PyPI.org was successfully obtained by the PSF and by the PyPI maintainers.
It was the sort of the gold standard of the domain that we desired, but it wasn't ours until I don't remember when it was when that happened.
But when it became ours.
Yeah.
When it became ours, we immediately switched.
I see.
So that was what you wanted all along.
But there was just this like squatter type of situation thing going on.
It is the Internet, isn't it?
All right.
So whoever wants to take this one, feel free to jump in.
One thing that I'm wondering is what features or benefits do we get other than the underlying system is more polished, easier to contribute to and so on.
But as just a user, like suppose I don't care about that.
It could be written in PHP for all I care.
But when I go to it, what do I get to do that's better or different?
Honestly, there's not much different.
Most of the goal of this project was to move to a system that would allow us to more easily add new and exciting features.
So we have a lot of ideas like new APIs and ability to deprecate packages and things like that that are now going to be, you know, not trivial, but much, much, much easier to implement.
Much easier than they would have been on legacy.
So a lot of this is just modernization efforts and taking what was originally just a proof of concept that became PyPI into something that's actually been thought through and designed and robust.
Yeah, I think you mentioned earlier, and Donald himself had said this previously, that the original PyPI, the gray one, not the blue one, was really like based on almost like custom web programming, not even like Pyramid or Flask or something.
It was really hard to get to.
People would come and say, hey, I want to contribute the new feature.
They would look and go, actually, not that much.
And then they would go away, right?
And so now, maybe this is a good place to switch into it.
You know, we could talk a little bit about what the underlying technology for that is, right?
So maybe Dustin Ernest, talk about the back end.
And Nicole, we could touch on the front end as well, because that also got super modernized, I'm sure.
Yeah.
So the thing about legacy is that it was written at a time that predates a lot of the frameworks and tools that we know exist today.
So, you know, it was doing the best with what it had, I think.
It's not a real direct criticism of it, but it just it came into existence like really early before much of the other stuff, right?
Like you pip install Flask, but where are you going to do that from if you don't have it?
It's old.
Yeah, the modern PyPI, the framework we chose to use is Pyramid.
And that was after a little bit of experimentation that sort of Pyramid just allows us to have a little more control over various things that we need to do to be PyPI.
And I think a big part of this project was the infrastructure work that Ernest did.
And I think he should talk about that more.
Yeah, go for it.
We're now deployed on top of a nice, buzzy framework, piece of infrastructure called Kubernetes.
And so we sort of looked at that as getting to the point where it as a technology, Kubernetes has come so far.
And by the time warehouse is going to be really real, Donald and I are both comfortable with sort of targeting that.
And the biggest drawback that that as a platform has is right now sort of the industry standard of the de facto for deploying to Kubernetes is you write a bunch of YAML or you use something to generate a template for YAML.
So the goal was basically to have a lot of similar features to other platform as a service and do so without really having to have warehouse maintainers or PyPI maintainers worry too much about what's actually happening.
And so a project came out of this work called Cavitage, which is a platform within Kubernetes and a web app and worker on top of it that just basically manage continuous deployment.
So you can set and configure your environment variables and such and then deploy your service and it pops up in a known URL.
That's really sweet.
So you basically, as a contributor, I do a check-in to a Git branch, maybe a PR.
And when that is accepted, that will trigger sort of Kubernetes to pull down a new version and just kick off, you know, sort of reroute the request?
What happens there?
Not yet.
That's the dream?
That is something that is another long-term benefit that we can sort of foresee out of this.
Right now, the biggest benefit that we get from this is we have incredible flexibility in the way that we deploy warehouse and how we change how many resources it has effectively.
So all of the primitives of the platform of Kubernetes effectively are really excellent.
It's just that you have to bring them together and that's the part that's sort of difficult.
So one of the biggest benefits we get is, you know, the zero downtime deployment.
So since PyPI went live on Monday, we've already deployed like 30 times and nobody noticed, which is great.
And then also just being able to be really flexible.
We have, I think it's like five different types of things happening behind pypi.org.
And we're running certain workloads under G Unicorn because they perform very well under G Unicorn.
And the primary site is deployed using Twisted for that purpose.
So overall, just, you know, having a little more flexibility and scalability was the main driver.
And down the line, we're really excited to see about doing things like you mentioned, being able to do branch based deploys, et cetera.
Yeah, that's really cool.
Go, Dustin.
I just wanted to mention, I totally forgot there is one feature that I'm super proud of that pypi.org does that Legacy did not.
And I can't believe I forgot about this because this is my baby for a long time.
But you can now write markdown descriptions on PyPI.
Yeah, that's awesome.
Which is a feature that people have wanted for a really long time.
And that's really the one big thing that I'm super excited to say that the new PyPI does.
That's cool.
And that's part of that modernization that you're talking about, right?
Like markdown, I don't know what people would have thought that meant back when it was created.
But now, obviously, it's like the de facto way of formatted, structured input that doesn't break the site because it's missing a div or something, right?
So it's really cool.
Markdown didn't even exist when PyPI was first created.
Yeah, I'm sure it didn't.
Nicole, how did the sort of redesign look?
Did you try to take what was there and like patch it up?
Or are you like, I'm just going to recreate this from scratch and style it up from scratch?
What was that process like?
Before I answer that question, I actually have something to add on the infrastructure question that you asked.
One of the things that I really appreciate about the project is how easy it is to set up as a contributing developer.
So I am not the most technical contributor, but I found the project really, really easy to set up with Docker and Docker Compose.
So the infrastructure that the team has set up in terms of being able to hack on this project is really, really amazing.
And it really lowers the barrier to entry for a lot of people.
We've seen people who've made their first open source pull request on this project.
That's really great.
Yeah.
It's really accessible for people to actually come and contribute to the project.
So I don't want to undersell that aspect.
I think that's really important.
I agree that it is.
And I think that's one of the real powers of this whole Docker thing is, right?
Like, it kind of comes all together.
But Docker on its own brings almost equally many difficulties or challenges at the same time.
And this, like, bringing in Kubernetes kind of, like, to make all the pieces fit, I think, is really, really clever.
So quite nice.
This portion of Talk Python to Me is brought to you by ActiveState.
ActiveState gives you a faster way to build and secure open source runtimes from your first line of code through to production.
Every second you spend building your Python distro or trying to secure your Python programs is less time spent doing the work you love.
You've got better things to do than trying to resolve dependencies or making sure that you tick off all security boxes when you ship to production.
Standardize on your Python builds so you can have less friction in the development cycle and you can deliver apps faster.
You can also get a unique server-side way to verify your Python applications at runtime.
Bake security right into your code without impacting performance.
Go faster, spend more time doing the work you love, and comply with your enterprise security needs.
Try ActiveState and see why it was chosen by IBM, Microsoft, NSA, Siemens, PepsiCo, and more.
Join millions of developers who trust ActiveState to build their open source language distros.
Visit talkpython.fm/ActiveState for a special offer.
That's talkpython.fm/ActiveState.
On your other question.
So in terms of the redesign, basically Donald just gave me free reign to do whatever I needed to do because I hadn't – like to give you an impression of the old code base, I wasn't even – you know, Donald basically said don't even go and touch that.
Like don't look at anything over there.
Don't set it up.
Just avoid at all costs because he knew that that would be a world of pain for me.
So I didn't really take any of the HTML or the CSS or the design from that.
It was just like, okay, so we've got this fresh new thing.
We want to show that it's a fresh new thing.
And we want to bring it to the standards, modern design standards that people expect.
We want it to be responsive so it works across all devices and we want it to be accessible.
So I basically started from a completely clean slate.
That's not true.
Donald had put together some templates, but he was basically like throw that in the bin and start again.
So that's what I did.
That's really cool.
So what are some of the technologies in the new one?
It looks to me like it's probably bootstrap based, which I'm a fan of, so that's cool.
And what else?
No, it's not bootstrapped.
No, it's not bootstrapped?
No.
Okay.
What's involved there?
Okay.
So we're going to go into a bit of CSS and HTML naming methodology.
So it's the HTML users BIM, which is a naming methodology for controlling the specificity of your CSS.
And then basically each of the areas of the front end is a separate block or component within our SCSS code base.
So basically the idea is we've built up a custom reusable CSS code base.
Yeah, that's really nice.
And you're using SAS, you said, or SASS, which is like programmable CSS that then compiles or transpiles to CSS, which is really nice.
So it sounds like if people want to contribute to the UI side of things, it's pretty modern and fresh if they want to drop in.
It is, and it's documented as well.
So it's fairly clear how that system works.
If you want to change variables, if you want to change what are called mixins, which are kind of like functions, reusable functions in SCSS.
And if you want to modify a certain part of the code base, it's really obvious when you look, when you inspect the HTML, it's really obvious where the corresponding CSS is for that within the code base.
So it's quite logical in terms of the way that the file structure is being set up.
And I don't take credit for that.
So it uses a system from a CSS guru called Nicholas Gallagher, who's, I mean, if anyone's into CSS, that's someone you should be following.
So it uses the IT CSS system from here.
That's cool.
I feel like CSS and a lot of the web design stuff kind of gets the short end of the stick, but it could either be a serious drag to work on or it can be really beautiful depending on how you do it, right?
The challenge with CSS is kind of achieving something at scale.
Like I think most people can, you know, write a decent CSS code base for small projects.
But when you start to scale projects, that's when you kind of have all this complexity with the cascade, things starting to break where you don't expect them to break.
So that's why from the beginning, I introduced these kinds of systems that I knew would allow us to scale the code base as we add new features.
I feel, I can't remember who on my show said it before, but somebody said they feel like CSS and large projects becomes a write only.
Like you don't actually change anything.
You only go to the bottom and maybe overwrite it or add another file that replaces it.
You know, like adds to it.
Pretty interesting.
So let's talk about the actual rollout because actually before we talk about the rollout, let's talk about the traffic.
I don't know, maybe Ernest, this is most clear on your mind, but this site and this underlying infrastructure, it handles a little bit of data, right?
In total, PyPI does.
The numbers are not directly in front of me.
Why did I do that?
But I have a slide deck somewhere that has this information.
But it's many, it's like 30 or 50 terabytes a month, like something to that size, I think.
It's a tremendous amount.
I think it's like 10 billion requests per month is our running average right now.
Let's go look at numbers.
So if we go and look at the old service to get it in the last month, so that excludes two days, we did a total of 6.5 billion requests at the edge.
6.8 billion requests per month and 1.5 petabytes of data at the edge.
Petabytes.
Holy moly.
And so we're also doing that at around 150 milliseconds of latency and with not that many errors, all things considered.
It's always important when we talk about these huge numbers to take one step back and go, yes, that is what the service is a total and total does.
But it's all thanks to Fastly, which is the CDN provider.
Right.
Because of the CDN.
Yeah.
Which is the CDN provider that offered to front PyPI many years ago.
And so just that one change was the most significant thing that happened to PyPI until, in my opinion, Monday.
But at the back end, we still do something like 25 to 30 requests per second across a myriad of different routes.
Yeah, that's really cool.
And Pyramid is working out pretty well for you.
Like my entire site, my course site, my podcast site, and various other pieces of infrastructure are almost all Pyramid.
There's a little flask in there.
And I think it's just been rock solid.
So I've enjoyed it a lot.
But how is it working for you?
Yeah, I've had no complaints.
I mean, I didn't really use Pyramid before I started contributing to the project.
And now it's definitely my preferred framework for more intensive web applications in Python.
So I like it a lot.
Yeah, it broke my brain.
I mean, like I got to the point where now I'm like, oh, of course, like this is how this works.
And I go back and I work on some of the flask.
I was like, oh, I can't do that here.
And so overall, I think I agree with what Dustin sort of alluded to earlier around the control and precision that you can get from Pyramid that other frameworks sort of make you run around to do.
Yeah, nice.
So the rollout.
So I set the stage with how much data you guys do, how much traffic you do.
When you flip the switch on that, that's got to be a...
So did you just go, it all goes here?
Or did you like do some sort of like, let's take 1% of 1% of the traffic and like slowly roll it over?
Like, what was it like?
The main traffic sources for PyPI are pip installs, XML, RPC.
So we have an XML RPC API and that gets a lot of traffic because it's mostly post requests and it's hard to cache that.
And then, you know, a very small fraction of that is actual web traffic.
So, you know, pypi.org existed for a long time before the launch and you could go and do everything on, you know, via the web interface that you could do on regular legacy PyPI.
So that was, you know, didn't require a lot of traffic and worked fine.
And so what we did was sort of some incremental load testing where we would switch certain either some pip traffic or XML RPC traffic over to pypi.org and see how it stood up.
Yeah.
So once again, Fastly was sort of predominant in that effort.
So because we were doing those redirects at the edge, we were able to set rules there.
And so like right now, actually, there's still quite a bit of traffic going to the old pipe or to the legacy PyPI backend.
And we can do that because we're not redirecting the traffic over to PyPI.
So we were able to like tune it at like 5, 10, 15, 20% for the heavy hitting stuff and test ahead of time.
And so when we switched, basically all we did is we started issuing redirects from the old service.
And so it was a one time click, but there were like weeks and weeks of like incremental quick load tests for where we would throw a bunch of traffic at it.
There was some replaying we did ahead of time as well.
Yeah.
Oh, replaying.
That's pretty cool.
That's a basically capture the exact web traffic and you replay it against the domain and just see how it behaves.
Right.
It wasn't the exact traffic.
We were taking measured, basically percentage stuff and then redispatching a request that looks like it.
And because the problem is we can't just do every request blindly or people would like dual submit up, you know, dual submit an action or something.
That's true.
Right.
You got to have non-modifying type of stuff or test data or something, I guess.
Yeah.
Pretty cool.
So how did it go?
Perfectly.
Not a thing went wrong.
It was good for the first 15 minutes.
I think we were all really excited.
It's working.
Wait a minute.
It's working.
Then the issues started rolling in.
What do you guys run into?
Sure.
So previously, all files uploaded by users to PyPI.
So these maintainers uploading their packages were hosted under the same domain.
So packages were hosted at pypi.python.org slash packages, some stuff.
During this switch, we decided to make a separate service, a separate domain for hosting user content.
If you've ever seen the documentation that used to be hosted at or is still hosted, I'm sorry, pythonhosted.org.
The main reason for that is that serving user-generated content from the same domain that you're actually operating a service from can be dangerous from some security perspectives.
So the thing that went wrong is that when we switched over, there were redirect loops and all sorts of craziness happening for people trying to download files from files.pythonhosted.org, our new host.
Ultimately, it was a bewildering and sort of bizarre thing because we had a number of factors at play.
We had files that were cached were fine.
Files that weren't cached were going to end up in this redirect loop.
We had some host names involved.
And overall, it was just, and it would happen, we realized that it's sort of the worst possible time.
So if you go to status.python.org and scroll down a little bit, you can read an incident report that sort of describes in more detail what went wrong.
But effectively, we were making this change as part of the rollout.
And an esoteric thing that occurs, I guess, occasionally when you try to move a host name from one CDN configuration to another CDN configuration.
We mishandled that.
And so it was a one line.
The fix was one line, and it was like 13 characters.
But it resolved it.
And so, yeah, not everything can go perfect.
Well, sometimes the best, most memorable lessons are taught in production.
What we talked about before we started the official recording that everyone was listening to is your overall, as a group, your overall thought was this was a big success, even if there was like a blip here or there.
Yes, absolutely.
Aside from like that, you know, files outage, which is kind of the core use of VPI.
So that's kind of a big deal.
But aside from that, you know, everything else worked great and continues to work great.
So we're generally pleased.
Like 99% of things worked perfectly.
Yeah, that's really great.
So I think this is one of those things, like I'm sure people were concerned about switching, like what might go wrong.
Like, will we break like Netflix deployment because they can't get a pip install to work on some like Docker container in like a continuous build because something like, you know, these types of I may be affecting this, but you sort of had to go through that to be on the better side of the world.
Right.
So now you Nicole's designs up the pyramid app that you all built is up.
And now it's it's just there to be polished and built upon.
Right.
Yeah.
I think that we're our hands are.
Well, once legacy is shut down, our hands are untied and we can make, you know, we can make progress in places that we would that we sort of wouldn't wouldn't have been able to in the future.
Something that I like to point out about PyPI, the historical PyPI is that there was a point where it was pretty much the only non static web host that Python.org had.
And so it would end up getting a bunch of features thrown into it that weren't necessarily critical to its operation.
And so as we split into warehouse features were removed from PyPI legacy and sort of while they were both simultaneously in existence, we had to be very strategic about what things we added to warehouse or PyPI.org.
And so once legacy is shut down, we can start to make much more progress and do so much more quickly and much more safely than we ever have been been able to before.
And so that alone is probably the biggest long term benefit of this is being able to do the things that people need, whether it's design or functionality.
I think if if you have to remain like with on parity with this older system that totally you're not designing one thing, you're designing almost like two things or you're constrained really painfully.
So you'll be free.
They share a database.
So that also is a huge complicating factor.
Very interesting.
I guess a couple questions just really quick on that.
And then I want to kind of talk about where things are going.
You said they share a database.
Like what database is that?
Where is the actual web apps running your Kubernetes containers running these days?
We use Postgres for a database and we have a very generous donation for in-kind service, basically.
So AWS said, yeah, you can run PyPI here.
And so right now we run we run the entire stack in Ohio.
I picked where it deployed.
So I picked Ohio.
But in the Ohio region for AWS, we've got like I think it's like nine medium-ish sized servers running Kubernetes.
And we're using RDS and Elastic Cache for Postgres and Redis and such.
That's cool.
And Dustin, I heard you talk about Elasticsearch, right?
Is that that's involved as well?
They're another sponsor in kind.
And that's for the search on PyPI.org is far, far better than it was on Legacy, which is basically a super naive search.
So now we can do full text search across descriptions and summaries and package names and even author maintainer names.
And it's a little more performant than the previous search and a little more reliable and better results.
Yeah, perfect, perfect.
All right.
So let's talk about where things are going, I guess.
So you have a roadmap laid out at wiki.python.org slash PSF slash warehouse roadmap.
I'll put that in the show notes, of course.
So the very first thing, you have a bunch of stuff, which is pretty awesome.
It's like, here's a milestone, closed.
Here's a milestone, closed, completed, right?
These are great.
And then the current one that's like coming in progress is shut down Legacy PyPI.
You all want to talk about that?
That's coming on the 30th, right?
Like that is, we're recording right now on April 18th.
So 22 days.
Yeah, go Dustin.
We sort of kept Legacy up for now just because there are a few big users of PyPI that weren't able to sort of make the migration in time.
So the idea is to keep it up for just a little bit longer.
And then fully, the domain will continue to exist.
So pypi.python.org will redirect to pypi.org.
But the legacy service will cease to exist.
That's the big change you were talking about, Ernest, where like you'll kind of be free to build this thing as its own creation, right?
Not mirroring that.
Yeah, it's interesting.
I think the first thing that Warehouse ever did that was production impacting was take control of the database schema.
And that was years ago.
And so we started tracking database changes there.
And then uploads came.
And then the actual web app came up and was usable and such.
And we added features there to get to parity.
And so everything that the project was sort of undertaken up to this point, except for, you know, markdown descriptions.
I think that's it.
And the design, yeah.
And, of course, the refresh design has been just to make sure that we're doing everything we can to keep from breaking too many people.
It's impossible for us not to.
I mean, it's impossible for any service to make progress without, at some point, deprecating older APIs and such.
And so we're really getting to the point where we've pared down a lot of things.
And we can start looking forward to, you know, value-add features, if you will, where it's like security features, audit features.
Accessibility is a big thing that, you know, we're looking forward to as well.
Yeah, very cool.
So that comes on the 30th.
And it'll be officially, the chains will be broken and warehouse will be its own thing.
And that'll be great.
This portion of Talk Python is brought to you by Codacy.
If you want to improve code quality, prevent bugs and security issues from making it into production,
and at the same time speed up your code review process by 20%, then you need to try Codacy.
That's C-O-D-A-C-Y.
Codacy makes it easy to track code quality and identify and fix issues by automatically analyzing your commits and pull requests
with all the most widely used static analysis tools.
Codacy helps great teams build great software.
Join companies like DeliverHero, PayPal, Samsung, and more.
Try your first code review by visiting talkpython.fm/Codacy and linking your GitHub or Bitbucket account.
You can also just click on the Codacy link in the show notes.
So then you have, under your roadmap, you have another section called Post-Lugacy shutdown.
And then kind of beyond that, you have Cool but Not Urgent, which is a nice way to categorize it.
So maybe we could kind of touch on those.
And whoever feels most like it's in their space, just grab it.
So like Dustin, there's something called incremental searching, search indexing rather, coming.
Tell us about that.
Yeah, so right now, the way the search index works, you upload a package, our index runs, I think every, now it's every three hours, roughly, when it actually runs.
So there's a lot of packages index.
And we don't have, at the moment, a way to sort of incrementally update the index.
So as soon as you publish a package, you know, it shows up in search results.
I see.
So you could say, like, this part is super stale because I know it just got updated.
So rerun the search, but only on this package, for example.
The goal was, you know, we got search up and running on PyPI.
And it was still a lot better than Legacy.
So it was good enough for launch.
But, you know, it can be better.
So that's one of the things we're focused on adding.
Sure.
And while you're on it, like, there's the autocomplete for search, which will be pretty nice.
There's also a search API.
That's pretty cool.
Like, does that exist?
Is there a way to search now and in the future?
Like, this is going to be a thing?
What's the story?
Technically, we have the XML RPC API that is technically deprecated.
You probably shouldn't be depending on it or using it or adding new things that depend on it.
It does have the word XML RPC in it, right?
That should be an indicator that it's deprecated, but no.
But you can technically search from this API.
And this is how, like, if you type pip search, whatever, that's how you get results through there.
But XML RPC, like I think I said before, is really hard for us to cache.
It's a big consumer of our bandwidth and backend resources.
So the idea is to sort of move to something that is a little more cacheable.
So this would be, we have a lot of ideas about future APIs for PyPI.org.
And, you know, something that might be included in that is a search API.
The other one that's interesting to me is the Psycho PG 2 warning.
So I guess that's just like you guys are using Postgres basically.
Are you using the asynchronous stuff or just synchronously?
No, warehouse is all synchronous right now.
Are you thinking of any way to get something async in there or does it not matter?
So a number of the services that are behind the entire sort of service, it's like the service umbrella, if you will, of what PyPI is.
So PyPI, it has been broken up into hunks.
And so for some things, it truly does matter the way these, you know, the way these requests are handled.
A lot of the really incredible work that was done initially on warehouse by Donald was just how aggressively cached everything is.
You know, the goal is basically to make as few requests require a transit to the backend as possible.
So we don't have a ton of concurrency concerns around that.
But for some services that do see lots of traffic, like we have a service that just translates old URLs to new URLs.
And that is effectively proxying information.
And so that's a knockout use case for async stuff.
Yeah, pretty interesting.
Let's see, what else is in your post-legacy shutdown here?
We have stop having a staging environment.
Is that because of the Kubernetes stuff that makes it not required?
So that's talking about test PyPI, which would be at test.pypi.org now.
That existed so that people can, or it currently exists so that people can do stuff and not worry about it being on the real PyPI.
So you can practice uploading a package, see how it looks on PyPI.
And I think there's a lot of reasons for it to exist, sort of just as an experimental and educational tool.
But the main reason I think people use it is to see if their restructured text descriptions are going to break or not.
Because historically, PyPI would just, it's sort of all or nothing.
You either get a perfect description or it just looks like plain text.
There's some ideas about doing some new things that might obviate the need for test PyPI,
like the ability to stage your releases.
So you're going to make a new release of your package.
You can upload them all to PyPI, but they're not actually published yet.
You can go and look at them, but no one can see them.
And then you hit a button and they're released.
Yeah, that's very cool.
And a big reason why that's important is we have immutable releases on PyPI.
And so right now, there's a lot of frustration that comes from users around they upload a package.
They don't like what they saw.
They try to delete it.
And they get a warning that says, when you delete this, you won't be able to reupload it.
And then they go to reupload it and they're frustrated.
So then they try to delete the project.
And then they go and they reupload it again.
And it says, no, you still can't reupload that file.
And so this is around primarily a caching and immutability thing to basically say that files can't be replaced.
So if you've been installing a file from PyPI for however long, it will still be there.
And so giving people a way to trial things without committing, basically, if you go to the permanence of the thing, is a big reason for that as well.
And when you get billions of requests, one pip freeze can make it part of the history of the software, right?
For sure.
All right.
So just really quick, some other things.
You have GitHub sign-on coming along, renaming projects, a few other cool things.
In the cool but not urgent, the one that stood out most to me was a mobile app.
Like, what's the story with the mobile app there?
Nicole, are you going to be designing a new mobile app for PyPI?
I don't know whether or not.
I mean, this has been a suggestion from the community.
And I think we're still working out whether or not that is something that's justifiable in terms of our time and the resources that we have on the project.
What exactly, like, do you guys know, like, what the goal of the mobile app?
I mean, you're definitely not going to pip install, like, onto your mobile phone.
Like, that wouldn't mean anything, right?
Is it more about management and, like, seeing stats?
I think it was more just about, like, can we offer this user interface as a mobile app as opposed to a responsive website?
And for me, I'm not sure how much value that would bring.
We probably have, like, I mean, I don't have the statistics in front of me, but it's less than 10% of our users are using a mobile or tablet device.
So, and the site works on mobile now better than the old ones.
So, I'm not sure whether or not we'll go down that road.
What I think is most interesting about the mobile apps issue that's being tracked there is a prerequisite for that is effectively the next generation of an API for interacting with PyPI.
That's one of the biggest things that is intended to be undertaken at the PyCon sprints this year.
And so, now, putting my PyCon hat on and my warehouse hat on at the same time, I think it'd be an excellent idea for people who are interested in helping to contribute to the discussion and design of the next generation of APIs for PyPI to consider attending the sprints after PyCon this year.
The sprints are Monday, Tuesday, Wednesday, Thursday after.
And there will be a number of contributors to the project around.
And that's one of the main things we plan on discussing.
It sounds really good.
Yeah.
Very, very nice.
A couple others.
Let's see.
The university, a simple one, package update feed.
So, that's like I can subscribe to real-time changes to the back-end data.
So, I know if I'm like, if I've pulled that down or something, I could refresh, say, like my local PyPI caching server type thing.
Yeah.
So, there's a lot of third-party services that depend on PyPI that kind of want real-time notifications about new package uploads or removals and that kind of thing.
And so, this is just going to be a new API for, you know, like a tool like PyUp, which lets you like automatically upgrade your dependencies when they're released.
Yeah.
I use PyUp on my stuff.
I love it.
Yeah.
It's great.
So, we want to be able to support them, make it easier for them to do their job and use PyPI.
So, that's one of the things we're thinking about.
Yeah.
You don't want to have to suck all that data down just to get a new batch.
Kind of like your incremental search.
This is like the external version of it, sort of.
Yeah.
Exactly.
So, another one that's really closely related to it, like including related to PyUp.io, like you just mentioned, is security notification system for Python packages.
That sounds really useful.
We just had this year or is it in the last year, like some sort of test malicious stuff uploaded to PyPI, right?
A couple of packages that were sort of hitting on typo squatting.
Didn't really seem to do anything, but still kind of scary.
So, knowing about security notifications, I guess not necessarily just people uploading malware, but like, hey, we actually forgot to check the password in this login field.
You probably want to get the newer version that checks the password type of thing, right?
On legacy, you could do this thing called hiding releases, which just made them not show up, but they basically still existed and it's not going to prevent you from using them.
One of the things that we're thinking about doing with the new PyPI is either adding the ability to deprecate a release saying like, you should not use this anymore.
It doesn't work or being able to market as insecure in some way.
So, there's like a known vulnerability in it and you should upgrade to the new version.
And, you know, this is something that's going to have to change in a lot of different parts of the packaging ecosystem.
So, like, pip needs to be able to say, hey, you told me to install this version and PyPI says it's insecure and tell the user, give them a warning or whatever.
But, yeah.
Yeah.
I mean, just related to that, I would love to be able to type pip security checkup on like an environment or something.
And go, these two things have security warnings.
These have updates, but they're feature only or something to that effect, right?
That would be cool.
Yeah.
And I mean, to be clear, it doesn't happen very often that there are security vulnerabilities in Python packages.
But it's something that could happen, might happen.
We want to be able to support it.
Yeah.
For example, Django had one or two minor security issues patched, right?
And you'd want to know if you were built upon Django, like, hey, you should probably install a new version before people start doing anything with that, right?
Yeah.
Very cool.
So, just super quick.
I'm about out of time, but just touch on one more thing.
Like, this week, I think, pip 10 was released, right?
That's correct.
I don't know how much any of you all had to do with that, but still pretty good news, right?
Yeah, it's great.
It had been a long time.
Since we had a pip release, so.
Yeah, it's really exciting.
I mean, the biggest thing is that it's a pretty foundational refactoring of a lot of the internal stuff.
And it puts, in my opinion, anyway, one of the things I'm most excited about it is it puts a lot of the internal tooling of pip and makes it more available for more interesting things built around and on top of PIP, not necessarily at a CLI basis.
Because right now you've got to, like, if you want to use PIP's stuff, you have to, you just have to jump into, like, super private APIs to do it, which isn't so great.
That's really cool.
Probably will make pairing it with this work that you're doing on the server side easier as well.
All right.
So I think I have other things I would love to talk to you about, but I think we're sort of running low on time.
So let's get to just a couple of things here at the end.
Final two questions, just quick, since they're straight of you.
Nicole, start with you.
If you're going to do some work on this project, what editor would you use?
Like, what typical editor do you use?
I use Atom.
Okay.
Very nice.
I don't think that I know about that one.
Tell me a little bit about it.
You're talking about text editor?
Yeah.
So it's Atom, which is developed by GitHub.
Oh, Atom.
Oh, yeah.
Sorry, sorry.
Yeah, I must have misheard you.
Atom, of course, I know Atom.
Yeah.
Sorry, that's my accent.
No, no.
Yeah.
Cool, Dustin.
I'm a Vim user.
Vim, right on.
Ernest?
I also am a Vim user.
Nice.
All right.
Now, this particular question I ask of everybody, but it's kind of interesting because you're
both on the inside and the outside.
So, notable PyPI package.
Ernest, how about you go first?
Notable in what way?
Notable in that, like, it's probably not necessarily the most popular thing.
Like, people always say requests, which is fine.
But, like, I learned about this thing.
You should totally check it out, sort of notable.
Like, it's not necessarily totally known, but it's actually amazing.
And it's just a pip install away.
Recently, with the type of squatting thing we sort of talked about, I was on the hunt for
something that would just tell me all of the standard limb module names.
And that exists.
And go figure, it is called, I think it's called standard limb module names.
Descriptive names are good.
Yeah.
And so, we were able to add that to PyPI and very quickly be able to have a good block
of that first line of defense.
Somebody didn't try to pip install regex or something.
Right, right, right.
Yeah.
Pip install re.
No, not doing that.
Dustin?
In the course of this project, I had this sort of favorite Python package I'd learned about,
which is pretend, which we use pretty heavily on Warehouse for sort of mocking things out
in tests.
So, the new PyPI has like 100% test coverage.
So, there's a lot of mocking going on.
And so, that's, I think, Alex Gaynor's tool.
And it's been really helpful.
I think my, as of lately, my favorite package is not actually on PyPI, but I just discovered
it the other day.
I'm kind of a sucker for like funny little hacks or jokes.
And so, this guy, Dominic Medzinski, he made this project called Import PyPI.
And it's really interesting.
What it does is it sort of wraps the import command.
And if you don't have a given package on your system, it will go out to PyPI, get it, and
install it, and it will just work.
So, you never actually have to pip install anything again.
I ran across that as well, and that's pretty interesting.
It's quite ironic it's not on PyPI.
But, yeah.
Does it do that on the fly?
Yeah, it does.
I think it does.
If it doesn't find it.
I don't think it's really recommended for production grade usage, but it's a fun little hack.
It is quite interesting for what it's worth.
Hope it puts a --user on it, at least.
All right, Nicole, do you have one?
Oh, yeah, I do.
As I said, I only dabble in Python.
But when I was dabbling, I got really into testing, and I really liked Factory Boy, which
creates factories.
So, I use that a lot for running Selenium tests running over my Django code base when
I was developing with Python.
It was a really cool project.
I think it's actually based off a Ruby project originally.
Yeah.
A ThoughtBots factory bot.
So, yeah.
It's a really great project to work with.
Awesome.
That sounds like a great one.
All right.
Well, thank you all for being on the show.
I want to give you one final chance for a call to action.
There's people who have packages they maintain.
They should probably play with your stuff, right?
Try the new thing.
We have people who maybe want to contribute to open source.
Ernest, you spoke about the sprints.
What should people do?
They should come to the...
If they're going to be a PyCon, they should come to the packaging sprints.
So, I'll be there.
Ernest, some part of Ernest will be there after running PyCon.
We'll see what's left of him.
And we're going to just sprint on the packaging ecosystem, including PyPI, and see what we can build.
Awesome.
You should go verify your primary e-mail.
Janitorial aspects of that.
So, go verify your e-mail address.
That's super helpful for us.
Yeah, that's awesome.
Yeah, Nicole.
The other thing is I'm planning on running a sprint also at Europython this year in Edinburgh.
So, for people who are based in Europe who want to contribute to the project, we'll be running a sprint there as well.
And the other thing is people should consider donating to the Python Packaging Working Group because we actually were lucky enough to receive an award from Mozilla to be able to fund working on our warehouse for the last few months.
But that money is about to run out.
We have used that money to get to our goal, which is to launch the new PyPI and shut down Legacy.
But in terms of the future development of the project, you know, any funding that we can secure is obviously going to mean that we can move faster and more reliably and be less reliant on our volunteers for our sort of core infrastructure.
So, yeah, I know the PSF is currently running a fundraising campaign.
So, certainly consider donating to the working group.
And there's a handy link, actually, at the top of the new site if you do want to donate.
So, yeah, any contributions would be most welcome.
That is a great suggestion.
And, yeah, I think people definitely should do that.
I forgot to call out the Mozilla Open Source Foundation and say thank you for that.
But, like, the reason we're here having this conversation and it got this major boost is largely, like, that was a major factor in it, right?
Dustin, you wanted to add something.
Yeah, the Mozilla Award is definitely the reason why this was all possible.
So, yeah.
I wanted to have a call to action.
Anyone that wants to contribute to the project or just contribute to Open Source, come and find us on GitHub.
We are a pretty friendly group and we have a bunch of issues tagged a good first issue that you could take a crack at.
And we'd like to see more contributors every day.
Absolutely.
And it's much easier, as you all have laid out, for various reasons why that's the case.
Ernest?
Yeah, I definitely wanted to just, like, I'm shaking here.
How did we not talk a little bit more about Mozilla Open Source Support Grant Program?
Indeed, it is the sole reason why PyPI.org launched on Monday and not in, like, another year or 18 months.
Because just the amount of work that went into making this all possible, I think, in retrospect and without being super optimistic looking forward, wasn't incredible.
And just based on looking back, it probably would have been an indefinite period of time before this occurred without being able to have people committed and thinking and soliciting the community to help as well.
So Mozilla was instrumental and forever indebted to them for how much they made this happen.
Yeah, that's really awesome.
And thank you to them.
That's great.
I want to add one final thing.
People should donate to the Python Packaging Working Group.
But they should also, if they have a company that massively depends upon Python, they should say, dear company, you're running a $5 billion business on this.
Could we set up a $1,000 recurring donation monthly to this?
Because without this, your business goes away, or at least a good chunk of it.
Yeah, the number of organizations and companies that depend on PyPI are most of them, it seems like.
So, yeah, it's now possible to make recurring donations.
So we definitely appreciate the support.
Right.
Awesome.
All right.
Well, let's leave it there.
Thank you all for being on the show.
It's been a great conversation.
And congratulations on the launch.
I'm super excited to see it.
Thanks, Michael.
Thank you.
This has been another episode of Talk Python to Me.
Our guests have been Nicole Harris, Ernest Durbin III, and Dustin Ingram.
And this episode has been brought to you by ActiveState and Codicy.
ActiveState gives you a faster way to build and secure open source runtimes.
From your first line of code through to production, check it out at talkpython.fm/activestate.
Review less, merge faster with Codicy.
Check code style, security, duplication, complexity, and coverage on every change while tracking code quality throughout your sprints.
Try them at talkpython.fm/codicy.
C-O-D-A-C-Y.
Want to level up your Python?
If you're just getting started, try my Python jumpstart by building 10 apps or our brand new 100 days of code in Python.
And if you're interested in more than one course, be sure to check out the 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, Google Play feed at /play, and 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.