Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
nick is a cpython core developer and a nominated member of the pipes and software foundation he is the author or co-author of several accepted Python enhancement protocols including pep 343 which added the win statement and context managers to the language
he's also accepted a number of pips on ghido van Rossum's behalf since June 2011 after more than 12 years in the aerospace and defense sector nick has been working on internal tools for Red Hat and is now the development lead for Baker a full-stack
software integration and testing system Nick is here today to tell us that nobody expects the Python packaging Authority wien please give it up for Nick Coughlin nobody expects it except people who read the schedule oops so Keith wrote it yeah Russell already
went through most of this so I'm also the media fell delegate for packaging related pets which we'll get into more about what that means later so Python packaging is fine Python packaging is wonderful these are probably not the words most people would
use oops so we we actually get quite a common feedback on new people who are new to Python particularly coming from other languages and your languages like nodejs like going why is packaging so bad it would be easy to get defensive and saying oh it's fine
it's fine it's fine the problem is they're not wrong there's lots of things that are fundamentally broken in the way we do packaging in the Python community and so instead of saying oh no no no it's all fine we don't need to fix anything
instead what we realized it was important to do was say okay where are we now where do we really want to be what's stopping us for actually being being there and what can we do about it and so a lot of the things that are wrong in Python packaging just
a legacy of it being old the the core of the current packaging system was lay was laid when the dis utils commit was made in December 1998 Google Inc was incorporated in September 1998 so our packaging system is almost predates Google oddly enough the software
world has learned a lot about software distribution in the last 15 years and we haven't really taken advantage of a lot of that setup tools an easy install of dates from around 2004 which improves a lot of things but again still a couple of years before
Jason was standardized and pip distribute virtual anvil things from around 2007 to 2009 and again they improved a lot of things but still dis utils is there at the core still 15 years old still limiting us in a lot of ways still causing a lot of problems and
so the question then becomes that's the history that's how we got here so where do we want to go just because we've been doing it for 15 years doesn't make it a good idea and so where we'd really like to get to we'd like newcomers to
pass then to have a really clear packaging story easy to understand easy for them to get to started easy to know for them easy for them to know what they should be doing and then have more advanced options as things they can explore later if they hit the limits
eight of the of the basic stuff so we want it to be so we want it really clear what's the best advice we want it to be easy to get started we want the tools themselves to be fast reliable reasonably secure and I'll get more into that qualifier later
but the other thing we want is we don't want what we do to be a Python silo we want to be able to play well with others we want to integrate with the Linux distributions we want to integrate well with other backing new systems and so what I'll be doing
today is I'll just be going through how we want to how what we're doing to try and get to where we want to be so their first call clear authority of guidelines what is preventing us giving those guidelines today and this is actually one of the most
complex things because it's a people problem it some aspects of it relate specifically related to tools but predominantly related to people related to politics and the question of who gets to decide what those guidelines say what tools will they recommend
where will they be documented and how to users figure out that these actually are the official guidelines and so the core of the people problem was who can actually say yes to this stuff we had people wanting to do the work people want to say hey I have these
ideas for how to make things better can somebody please tell me how to make it official and so pison has a mechanism in place for the core language that is deciding this kind of thing which is the pious enhancement proposal process and that basically is the
way guido van rossum says yes to things now the problem with that is if it's a problem that Guido doesn't care about then it's really hard to getting interested and sometimes he'll say yes just so people stop bothering him about it and that's
the way packaging has historically gone because Guido just wanted the problem to go away the rest of the core developers me included just one of the problem to go away and so we said yes to things that we probably shouldn't have said yes to because they
just didn't work and so what was changed this time is I'm basically a lot more directly involved because I've had a lot more to do with packaging in the last couple of years since starting at Red Hat and I'm one of the ones now going hey this
is broken we need to do better and we had a couple of people coming in daniel health and donald stuffed wanting to work on a lot of stuff and the people developers and the setup tools developers again wanting to get involved and work on stuff and I basically
volunteered to say hey that's right let's have another go at this and I'll volunteer to be the one to say hey yes let's do that so these other guys are doing all the work the only thing I'm actually doing myself is writing one metadata
standard and that then becomes the linchpin that lets all the new tool the new versions of the tools interoperate on different things and so that basically gives us the power to say yes and makes lets lets us channel the energy of all the people involved in
productive directions such that will actually improve the ecosystem as a whole rather than people going off their separate ways and just creating more fractured communities and then Bridget Jones has also stepped up to to be the final decision-maker for the
stuff specifically related to the Python package index and that's employed us make some substantial improvements there that of that we'll get more into later one of the other key changes though is that the Python enhancement process - enhancement proposal
process has historically been targeted solely at the standard library and so every pep had to have had to be making a proposal about hey this is going to be in the standard library at some point and it turns out that's a fundamentally broken away of approaching
packaging problems because Python 2.7 is still the most widely used Python version Python 3.3 is catching up but it's not there yet and both of them are obviously far more heavily used then the not yet released Python 3.4 so a pep proposing changes to
Python 3.4 isn't really very interesting because nobody's using it so a packaging tool that only works with Python 3.4 which doesn't exist what's the point and historically we have tried to do packaging peps that way targeting the next version
[ ... ]
Nota: se han omitido las otras 3.769 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.