 This afternoon's presentation the future of Python packaging is by Richard Jones. Please make him feel welcome Thanks, Joe So this is going to be a talking kind of three parts The my history with Python packaging goes back almost 20 years So I'm just going to give it a little bit of a history so there's a bit of context of where we are today So I'm going to do that first and I'm going to talk about what we've been doing recently And I'm going to talk about some of the things that are coming up some of the things that are actually important that we're working on Or are going to be working on the in the imminent future So some of the history This they're not going to be a lot of detail in this section It's just kind of to set the scene if you will So going back to 2000 or thereabouts Which is when kind of the modern packaging story starts Dist details was created and added to Python 2 as as a built-in feature for Python This was a bit of a watershed because it made two things a lot easier It meant that people didn't people who are compiling C modules for Python We're no longer just copying around make files that happen to work for somebody else or Trying to figure out how auto conf worked They were using a built-in facility all they had to do really was identify C files and say please make me a module and There was enough machinery built into Python at that point to build that and this was especially good for people who were say working on Linux because they had reasonable confidence that their thing would probably be built on Windows without them having a clue How that would work the other thing that just details brought along was a packaging system So that where previously we would build up arbitrary bundles of of files in in in a tar format And release them on to use net or somewhere on the one on a website or something like that Distitutes standardized that which meant that there was reasonable confidence that people could actually use the thing that you were creating So that was kind of nice, too Another thing that came around about the same time was a thing called the vaults of pinesis which was Like a lot of websites around back then it was just a collection of links loosely ordered It even had the good old back and forward buttons on on pages just for like random clicking around because that's what a lot of the Web was it was just random clicking around It had very little metadata built in and it mixed up links to tutorials with links to software So there were no tools that actually worked with the vaults of pinesis But it was an invaluable tool. You can't see it, but of course the little flame Picture up the top there that flickered, you know in true web 1.0 style so In order to try and Introduce some order to the chaos We created the Python package index Which was an an ordered well-defined set of metadata in a website that people could go to to find software for their Python projects That was done in around 2002 in 2004 We extended that website that that facility to allow uploading of packages And so it became a repository of software as well, and we also renamed it to the cheese shop Because at the time the Python in Python a project or pi pi Was also becoming quite popular and we had issues with people coming to sprints and saying is this the pi pi table? And I would say yeah sure But then they'd sit down and half an hour later. They'd realize they're at the wrong table So we now have people calling it pi pi, which I hate Cheese shop is the name of course. We lost the cheese shop name because the suit said that's not serious enough so no no cheese shop and another effort that was going on Around about the same time was an extension of the dish details idea about about packaging software So set up tools extends the basic features of district hills with adding dependencies It provided a tool called easy install which you use to install packages from a website and It introduced the egg format which took the basic bundling mechanism that district hills had and extended that with a few extra features unfortunately set up tools and easy and easy install were Controlled by one developer who wasn't didn't play very well with others and so we had pip and distribute came along as alternatives to those those tools Which were more collaborative? exercises they clean things up they organize things and they implemented a bunch of features that the community actually really wanted But couldn't get into the other tools a lot more cooperation Unfortunately, this meant that we had a bunch of different tools and users were very confused Not a good thing for the end users another thing that came along at the same time was continuous integration This is coming up to like the late 2000s continuous integration is awesome. It's a really good way of developing software unfortunately GitHub provided free to continuous integration tools and our single server was utterly swamped and Every effort we made to improve increased capacity was just met with more traffic and so In the late 2000s early, you know 2010 and 11 We were just migrating between different infrastructures trying to come up with something It was resilient in the face of just continuous integration constantly hammering and wanting files another thing that popped up more recently is There's a book that was written which had an example of how to publish your package to the cheese shop where you implemented nested list printing and So now I have a thing that I run every now and then that finds nested list printers on the cheese shop and deletes them The so I wrote the first implementation of the cheese shop and much of the rest of it with help The initial implementation wasn't supposed to last very long It was maybe supposed to last a few years tops until it got popular and somebody had come along and make something better It's still going and that's you know 15 years later It used HTTP basic or with no SSL It didn't have a built-in signing infrastructure We had the facility for people to upload signatures for the files are uploading, but there was no tool chain support for that Because if you've ever done any work with GPG Building tools using GPG can be quite challenging, especially on Windows so even with PG the GPG support in there. There's still a whole heap of attack vectors that we would just were oblivious of Well, not oblivious of but not taking into account Another thing that came up, of course, is the issue of Linux being something that's typically That you build a Linux system It's your server and you install some software on it and the server is happy and the software runs happy for developers You have the issue that you want to have your desktop And you also want to install various different bits of software on it to try them out or to try to work on different projects And so you have this conflict between system installed software and Python who want that we want to install a bunch of modules The packaging systems that we had easy install had no way of uninstalling modules PIP has a mechanism for uninstalling modules, but it wasn't very good and it got better So you end up with a very messy system Virtual end came along which was awesome And it provided the ability to have alternate ways of installing different packages of software So you could isolate things and that's really cool Another thing that came along was the ability to have user local installation of software So the till dot local directory which is used by different tools to different degrees Is fully supported by Python and you can install software in there and it will be just transparently used by Python Which is really cool Eventually it would be really great if this is the default for PIP installation of software Rather than installing to the system by default But that's a couple of deprecations down the track At the moment it's opt-in use the dash dash user switch to PIP And it'll install stuff to the till dot local directory Which is again a nice way of not polluting the system Even on a Mac, I'm a Mac user, sorry You still have that system user problem You do not want to install software on a Mac to the system Python Because Apple provides a system Python that is broken and you don't want to use it So you have to have the ability to use a different Python, different installations of Python And along this long story we also had a couple of alternatives Several alternatives pop up, a couple of which that have become quite popular ActiveState and Conda are different ways of doing Python packaging that provide a different story to users They have slightly different focuses ActiveState, their packaging system mostly supports their editor environment And it's nicely integrated, so it's a very nice user story Conda mostly supports scienticians doing their thing with their specific packages that they need Which can be quite troublesome to build for people who aren't developers So these things come along and that's great because we don't have to worry about the 20% that we're not catering for Somebody else is handling that story for us, which is awesome So that's kind of a canned history of where we've come from I'm not going to talk a little bit about what we've been doing very specifically in the last year Or maybe slightly longer about doing more immediate cleaning up Now that we're starting to get a bit organized And one of the ways that we're getting organized is we've got a cat herder or BDFL who's stepped up To try and get everyone working together or at least going in a sensible direction And that's Nick Coglan who's sitting just up here And the reason he stepped up was because Guido, who's the BDFL for Python Just doesn't care about packaging, which is perfectly fine by me It's not the most interesting thing So one of the most important things that happened there in that cleaning up process Apart from Nick stepping up and actually kicking it off and shepherding or herding Is that we've had the grand hug of set up tools and distribute and pip All coming together and being happy together and we've got some real movement So set up tools and distribute merged, so there is just set up tools now So removing all that confusion for end users or packaging users To figure out which one they should use, set up tools or distribute Pip and easy install haven't merged, but we've come out and said that pip is the tool that people should use And so easy install still exists, but the strong recommendation across the board is to use pip Another part of this coming together is the forming of the Python packaging authority Now Nick has talked about this previously, some are going to go over and over it But the basic idea is that we've brought together the people who are working in this packaging story All the different elements of it, we've tried to bring them together under the one umbrella So we have groups on Bitbucket and GitHub to sort of organize the software development We've got a domain at pypa.io where we host a bunch of web stuff We've got the pip virtual end set up tools, pypi, wheel, disklib and a bunch of other stuff All coming up underneath though either on Bitbucket or GitHub We even have now one of the efforts of the Linux distributions to kind of integrate in with this stuff Working on the same GitHub One of the big efforts that's come out of that is a consistent place for documenting packaging Which is the packaging.py.org packaging guide So instead of having a bunch of different blog posts and wiki pages And different things here and there and user manuals for different bits of software There is a single place to go now which tells you about how to do the various different things you need to do in Python packaging Either as someone who just wants to install something or as someone who wants to create a new package There's a GitHub repository that you can clone as the thing you should... A recommended GitHub clone that you can clone to start a new package that will then be easier to package up and share with the world The nice thing about the packaging guide is it's on GitHub as well so you can go to the GitHub interface and suggest an edit right there And we do get a lot of suggested edits which is really good It's quite solid Another thing that we've done more recently is the implementation of SSL across the Python package index To protect that link between the repository and the end user There was a quite obvious easy exploit demonstrated during a PyCon in the US A man in the middle attack And so that's harder to do now, it's not impossible and I'll come back to that in a little bit So implementing SSL was something we could do which was relatively straightforward on the website Unfortunately it also meant that we needed to boost the support for SSL in Python itself But that was done, there was enough momentum that we could actually get that done And some of that momentum came about with the RubyGems break in And so that's given us a stick that we can take around and hit people with and say we really need to get this stuff together So getting SSL in as well is good Another thing that we got was support for the stronger SSL into Python itself So it actually does certificate checking in Python which is something it didn't do But also now we have pip and virtual end for support in Python itself as well The pip support in Python means that we have a better known version of pip That people are going to start using that has these new security features And that's built in and it's available from day one for Python users Unless you use Ubuntu So the other thing that we've done more recently is continue to improve the infrastructure that the website runs on That the index runs on So we went from a single server hosted in the Netherlands to a couple of servers hosted in OSU in the US I think we've got four different nodes in Rackspace now which run like the core service And they've got a geographically distributed set of caches which have been donated by Fastly to handle the actual files being hit by these continuous integration tools And so the reliability of the service is significantly improved now over what it was That's neat, sorry I didn't read It kind of goes from one to the other Racks to racks Another thing that has come up is trying to clean up the distribution formats themselves And the wheel format is something that came up, this is not really new But it's something that's starting to be adopted now by people And the wheel format is a way of trying to clean up the bundle of stuff that is the thing that you're trying to distribute One of the issues we ran into with the previous distribution formats, like S-Dist, you need to build it Egg files, they can have all sorts of stuff in them and you can execute things The wheel format is about saying here's a blob of stuff that you can just copy and install it And really, really resisting that idea that there be any sort of execution that required to make that work So just cleaning up that whole story And I'll come back to the wheel format in a little bit and talk a little bit more about it Now I understand this picture is used a lot, but whatever We're also trying to work with Linux packages more closely And figure out what that story is between Python packages and Linux packages That whole thing about trying to move away from default installing to the system That's part of the story, but also there's some other things as well which I'll talk about in a little bit But that's an ongoing thing that's been going and I think it helps that our BDFL for packaging Is also a Red Hat employee who's got the people who do packaging You know, he's got them, there's a conversation going there PIP 6.0 has just been released, which is really nice It dropped the... PIP 1.5.6 was the previous version PIP 6.0 just dropped that one, we don't need that leading one digit So that's why we've gone 1.5 to 6 Some of the neat things that are in PIP 6.0 are you can have client-side TLS You can turn off TLS verification for specific trusted hosts Which is nice, so you can have your own self-signed certificates and say that's okay Local host isn't called an insecure host anymore, so that's nice You used to get warnings if you tried to do just HTTP to local host There's a whole bunch of really nice little security features in there The directory that PIP uses to build the software is now a randomised secure directory Rather than being a predictable place, so that's nice as well It also has its own auto update check built into it So it'll check periodically to see whether or not it should be updated And it'll give the user a little message saying, hey, there's a new version that should probably update to that And you can turn that off if you like And on the verbosity thing, the output from PIP is now far less verbose Much better organised There's even a bug that was removed, so if you ran PIP in parallel, you would get duplicate output So that's been fixed as well So there's a bunch of nice cleaning up of the output of PIP as well And I think if you're on a terminal that supports Unicode, it'll even do it slightly prettier So this release includes some of the initial PEP 440 work Which is still kind of a work in progress There's still a few edged stuff around PEP 440 And I'll come back to what PEP 440 is in a little bit But basically it's about trying to clean up the way we pass and assign semantics to version numbers And it's terribly exciting stuff, but there's a lot of ambiguities around this And so I've looked at cleaning that up PIP finally has support for site-wide configuration, which is nice And it also has support for operating system-specific configuration locations So previously it would just look in tilt slash dot PIP for the configuration It now looks in, on OS X it looks in the correct place Or the more likely place in a library application support directory Or in Windows it looks under something user path setting thing Anyway, so it looks in the place that's appropriate for the operating system And you can also have a PIP configuration specific to a virtual end as well So if you have a virtual end that is an employer-based virtual end As opposed to your personal project one Then you can point the employer-based one at their PIP mirror If that's something you need The download cache has gone, deprecated in favor of just built-in HTTP caching Just the natural progression of the libraries that PIP is built on Means that it has caching built in now Another thing is that if HTTP requests have failed They're actually retried automatically now, which is nice And there's a stack of other bug fixes and little improvements to PIP So on the subject of version identification The idea here is to try and standardize the myriad of different ways That tools were doing version identification And again, that assigning semantic meaning to the numbers That people were assigning to their packages So in short, it looks, it's basically that With a bunch of words The epoch segment is kind of a funny one Who's run into epochs on versions? Yeah, we've got a few, it's something I hadn't run into before This format shouldn't be surprising Although it's obviously written in a way that's not very human parsable But it shouldn't be surprising Really, it repeats the same semantic versioning systems That a lot of people are using already But what it's doing is saying that the tools that we are developing Understand this format And if you don't use this format, the tools are not going to understand How to deal with your packages' versioning It also formalizes the idea of having a public version And a private organization local version So a label that you assigned to say Well, I've taken that public package And I've had to make a few changes to it to work locally I've vended it for our organization And I'll attach an extra significance to the version label For that package And we'll put that in a local repository So the tools all understand how to deal with that There's a bunch of other considerations And this is where the words come in in the PEP Because everyone is a special snowflake So there's all sorts of stuff in there about case sensitivity Integer normalization, pre and post release specifiers So some people like to use pre Some people used to like p and some are rc or whatever There's variations on the various alphabetical components So b and beta Compatibility issues with other versioning schemes So very specifically how we handle people Who really like to specify dates as their versions Yeah, it also talks about ordering mechanisms And so it talks about ordering mechanisms But it also talks about how to deal with those In specifying package versions that you want to use So that again, so that we can standardize this Across all of the different tools that deal with python packaging So there's a set of different things And these are the versions specifiers that you find In your requirements.txt file or whatever tool I mean that's the most common But whatever tool you happen to be using to fetch And organize your python packages Just a little note The compatible release clause is something that Was relatively new to me It's kind of neat Who's familiar with compatible release clauses Yeah, not so many So the idea there is to say Look, I'm using 2.3, 4.3 That's the version I'm currently using But the creator of that has said That anything that starts with 2.4 is going to be compatible So the version specifier says That any version 2.4.3 or later As long as it's a 2.4 release So that's what the compatibility clause was saying So the wheel format I mentioned that in passing So the idea here is to As I think I alluded to Is to clean up the thing that is the bundle of software That's being installed To separate that concern of building a thing From installing the thing So the wheel is just a thing that's installed Somebody has to build the wheel Separate to it being installed Whereas at the moment We're all distributing source distributions So everybody has to be capable Of building those source distributions Which is both a complexity issue And also a time issue It just takes longer to install a source distribution Wheels are installed almost instantly Because it's just a copying files around The architecture of a Wheel file is It's basically a zip file With a bunch of files in it Which are copied to the file system And that's it Wheels don't support being imported directly As zip files at the moment But that might be added But it's not really something that's I don't think there's even a plan for it Yeah, it's not explicitly supported Whereas eggs That was something that eggs specifically supported So eggs are kind of like wheels Except there's a bunch of differences That I've already alluded to One of the most important one being That eggs had stuff in it That could be executed And wheels avoid that Except for one case Again, special snowflakes Yep Okay, so that's wheels Very few slides there Because they're such a simple format But the important thing is It's just making it easier For people to install your stuff So if you have the ability Please create wheels And upload them to the cheese shop So people can install your stuff Even if you're just shipping something That's pure Python Still create the wheel Because installing a wheel is so much simpler Linux wheels, though Become a tricky story So And the reason for this is that Almost no two Linux's are the same Obviously That's a very, very, very broad generalization But even Python itself Isn't necessarily the same Between two Linux's Whereas on Windows The set of pythons is smaller Python can be compiled in different forms But it can also be linked Against different libraries Python 2 was less easy to deal with In this case Because of ABI compatibility issues Some of them just around The Unicode implementations That were compiled in Python 3 cleans this up a lot It has more promises About ABI compatibility built into it And then of course there's the separate problem Which is that Linux's Aren't necessarily very compatible With each other Just the set of things that are installed Can be so much more variable Between different Linux's So the end result is that Wheels compiled on one Linux May not work on another one So there's a bunch of different solutions That have been proposed And there's a lot of thinking around How to solve this problem In fact there was a solution proposed Only about two weeks ago I think three weeks ago Which seemed like a really neat idea Unfortunately it lasted about two weeks Or even less Before somebody poked the ob... Two days Before somebody poked the obvious hole in it So if you have an interest in this Then I would highly... I would ask you to get involved in the discussion To try and sort out the Linux compatibility tagging thing For wheels So that Linux can have wheels Because until we solve this There's not really much point in us Supporting uploading of Linux wheels To the cheese shop Because the chances are That we'll just get a bunch of people Emailing me particularly Saying that the thing they downloaded is broken And yes I'm the administrator Still of the cheese shop So I get these support requests directly Yes so it's... It's not all doom and gloom We're pretty sure we can solve this Or at least come up with an 80 to 90% solution Which is actually pretty close to OS X It's... OS X still has the same problems Just not on quite as large a scale OS X developers have brew installed Or home brew installed Or Mac ports installed And the compatibility between those can vary So it's... Especially if you do something like Brew install open SSL force link Then you've got a wildly different version Of open SSL installed Which can break stuff So... It's something that we are pretty sure we can solve We just need more brains on the problem I think I've got... Yeah that's the answer Yeah okay So let me talk briefly about mirroring So mirroring was one of the things we came up with As a potential solution to the CI is hammering as a problem Well actually it came up kind of before then As a way of scaling things up And a formal mechanism for Creating mirrors was added to the cheese shop And that was all good Unfortunately it didn't really work out so well The mirrors were a bit uncontrolled And syncing was a real problem So the mirrors are just dead We've come up with a different way of solving The availability problem You can still create your own mirror So you can still set up a mirror Inside your own organization It's just that public mirrors Aren't as necessary or even as desired As they once were There's a tool called Bandersnatch Which is recommended through the packaging guide Which is the tool that you should use If you wish to set up a mirror inside your organization Yes so Bandersnatch, that's the thing to do And there's information in the packaging guide About how to set that up It's actually quite straightforward Another thing that people do with The cheese shop is proxy Their requests through a local proxy And the reasons for doing this are many and varied The reason I do it is that Occasionally I'm offline I don't have internet access And I still want to be able to install the packages That I need So if I run all of my requests through a proxy Those packages are available locally The proxy can say Well they don't have an internet connection Here's the last version that I retrieved And everything still works And there's a great tool called DevPy Which lets you set up a local caching proxy For your cheese shop accesses It's very easy to set up And that gives you a bunch of resilience against outages And that offline caching facility It has a whole heap of other features built in as well In particular you can set up An organization specific Or just a local personal repository That you can upload packages to And there's a bunch of different configurations That you can use to do that The most common configuration for DevPy Is just as a straight caching proxy Where this is the default setup that you get Where you point your pip command at the DevPy Which is the colorful box And it just transparently goes through And fetches stuff that it doesn't already have From the internet And it understands enough of the API of the cheese shop To do things relatively sensibly But if you're in an organization Where you have your own private packages That the organization is generating And indeed you might have those across multiple teams Then you can have an internal company index Which sits in front of the global Or the public cheese shop And packages can be fetched from that first And then if you have teams Which are working on development releases Then they can go up to development indexes Which sit in front of that company release index as well So you can have multiple layers here And it can get all very complex But this stuff is built in And it's actually reasonably easy to configure In DevPy If you want to know more about DevPy I gave a talk about it at Pycon.au last year And that's the link to it But now I need to talk a little bit about Where we're going from here So I assume everyone got their whole board This year Okay, so a big problem that we've got Is that with the history of the cheese shop As we started off as an index Of pointers to other people's stuff An index to pointers of web pages you could go to To get a piece of software And that history is still with us We still have to deal with these external packages So one of the problems we've got is How to improve the way we're dealing With these external packages People still have a need to have their package hosting Outside of the cheese shop for personal reasons For legal reasons, whatever So we have a PEP that's been in development For some time now It's PEP 470 And it's stuck in development hell To borrow a phrase from the film industry It needs a lot of extra thought And one of my key concerns As the guy who approves this PEP Once it's in a state that's good One of my key concerns is not breaking everything Or not breaking a bunch of stuff along the way So external packages And the support for them Is something we're still trying to solve We're also looking at the metadata That we're currently generating as package authors And figuring out how to... Well, the metadata set was basically designed About 15 years ago, well, 13 years ago So we've come a long way since then We've added some capabilities to things We've extended it in a few different ways Set up tools, added a few things to the basic metadata So there's an effort now to Have a look at the metadata that we've been generating And how we might clean that up We're also looking at moving away From having the metadata locked away Inside a Python file that you have to execute In order to get the metadata out So looking at storing it out in a separate static file So that tools can get at it And I'll come back to metadata in a little bit Because my slides are slightly in a funny order here Another big thing we're working on at the moment Is this continuing look at the security story Around the cheese shop And in particular, there's a thing called the update framework Which is a system that grew out of... It grew out of the Tor project As a way for them to securely update their software And what they've done is they've taken... The people who worked on that have taken that effort And formalized it as a paper, an academic paper And they've proposed a way for the cheese shop To integrate some of these security ideas Into what we're doing So we actually have two peps that have come out of that One of them is talking about securing just the link From the cheese shop to the end user So we're now in a situation where we have HTTPS Covering the link between the end user And the cheese shop Except not quite Because it actually secures the link between Fastly and the end user And then Fastly talks to the cheese shop So if Fastly is compromised Then our users are compromised And also anybody using a mirror is in the same situation So if the mirror that they're using is compromised Then they cannot trust their packages So the PEP 458 is about securing that connection Between the package that is uploaded to the cheese shop And the end user There's a whole bunch of complexity around this Involving multiple levels of signing And online and offline keys If you're interested in this I highly recommend that you have a look at the draft That is currently up online It is actively being worked on Although the number of edits Aren't necessarily changing the implementation proposed They're mostly cleaning up the language around it To describe it better Because again, I'm the guy who gets to approve this And I need to be able to understand it So this is about protecting us against Man in the middle of attacks Which we kind of did with HTTPS Until we brought Fastly in And now we've got the same problem again So the next problem we've got to solve Is a compromise of the cheese shop itself So somebody breaks in to the cheese shop servers What can we do to provide end users Some confidence that they're not going to be owned as well So PEP 480 is about allowing package authors To sign their packages directly Now wait a second I hear you say Well, I didn't actually So we already have GPG signing in the cheese shop Isn't that good enough? Well, as I already said previously GPG isn't the ideal tool It's not user friendly Especially on Windows What the PEP 480 approach is providing Is a significantly more user friendly approach Almost transparent to most users And yet providing the same level of confidence to them That the package that they are retrieving Hasn't been tampered with along the way And that's PEP 458 And is the same package that the author Intended to provide right back at the start And that's what PEP 480 is providing It's an opt in thing So for a package author who doesn't have that much of a Doesn't really care that much about that aspect of things They don't have to opt in to the PEP 480 stuff And explicitly sign their packages But another thing that it's doing is trying to make That step easier so more people do it Again, the GPG thing is a little bit more complex And we can talk about it after PIP is still being worked on It's constantly being worked on to make it more user friendly VirtualEnv is actually being rewritten at the moment Or at least there is a rewrite of VirtualEnv In work at the moment to clean it up Because again, it's a tool that's been around for a while And we've learned a bunch about how it can work We've got new facilities built into Python To make VirtualEnv's work a lot simpler So there's a lot of work that can be done there And it's being worked on right now From the ground up rewrite We've had a new version of the cheese shop itself In work for a number of years now And honest, we will get there one day We just need to find a little bit more time To finish it off If you are interested in websites And a cheese shop and all that jazz Come along and help I think we just need a few more hands Who are willing to dedicate the time To helping get us going And, yeah, so finally, well, yeah The Linux story is getting there So the conversation is still going on Between the Python packaging and the Linux packages The conversation around What we put into the packages in terms of metadata To make it easier to generate system packages System Linux packages from Python packages That's going on as well And it's part of the metadata revisioning That's going on at the moment With the hope that we can just say Automatically generate a Linux package From the Python package But that one, that needs more eyes And more brains on the problem Linux is a large problem That we need to... More people working on and trying to solve So if you're interested in any of this Then we all live at PyPA We're all a big, happy, huggy family these days And we welcome contributors So please come along Thank you Probably don't have time for questions We have a little bit of time for questions If anyone has questions Good evening I guess I'm interested in the How Python's packaging system As you're doing it there It's also looking at integrating With distro's packaging systems And is there... Is it making that easier? Is it a goal as well? Oh absolutely So yes, the idea with the current Efforts we're going through With looking at the metadata That we're creating when we create packages The way the packages are bundled So the wheel format stuff All of that It's not only trying to make things nicer for the end users But it's also trying to head towards That place where we can just Automatically generate Linux packages Where possible Yeah, it's very much a high priority Hello I wonder if there are any plans To introduce some additional quality control To the cheese shop Because it's scary how often I find packages That aren't licensed, don't build Classifiers are wrong Yeah, so we actually had A quality mechanism built in To the cheese shop For a couple of years A few years ago Unfortunately The people who created that Had some negative feedback So the system just went away What I would like to see Is for a third party website To come along, use the APIs we've got And provide quality Python quality dot com Or dot io whatever And have that information there That's why we have some issues with Are we officially saying that This package is not so good So we run into problems When we try and do that sort of thing If somebody was testing up a third party thing That would be brilliant The actual code That was created to do The quality metrics is still out there The project is still out there It's just not running And it was called Cheesecake Cheesecake Sorry, I was just making a note of the name Of that package One, is there any likelihood That the PSF would support The cost of running that one Because I actually kind of half built one And never put it anywhere So to immediately answer that Ask them That they don't buy it The other one is Now this is the third time I've seen this talk And the third time I've seen The final point left Instead of the other POSIX environments That do not have a problem When will we all begin to support FreeBSD and the rest That don't have a constant problem Of breaking everything every time You change the tiniest thing I think when somebody steps up And contributes it That's the short answer There's a lot of things In the Python packaging land That just needs somebody to And contribute There's not necessarily any There's no Stop energy that I see Against that sort of thing So yeah, it's just that Somebody hasn't done it We have time for one more short question Just to say thank you For your presentation today We have a small present to give you Thanks Please thank Richard