 mentioned here And I suggest to do it before we go to the last point because That will take a while probably I guess we can start Actually, I yesterday I installed the Gobi package not Gobi infi note I don't know if that matters, but it worked for me. So first topic Python 3 support What can we do? What can you do? I was just gonna say that yeah, it's it if upstream supports it and It's really Usually very easy especially with PI build these days to just add the Python 3 support And actually it's a great opportunity to clean up the packaging of the of the package anyway because you can I can usually remove 20 lines of rules and you'll get Test suites yeah by default. Yeah, well, yeah, exactly and But the the things that you know, I find our bottlenecks, they're not huge bottlenecks, but their bottlenecks are when you have a stack of dependencies and you have to you know You have to get this one not only Ported to Python 3 but you got to get it through new before you can then you know work your way down the stack and That that's a little bit of it's a little bit of a Bottle mech especially for certain package package that all work together And I don't know that that's that's anything that we can do except maybe volunteer to also The new queue is not that's a problem right now. We have one of our team FTP master team so we probably can trick him into processing I won't actually say that he's volunteered to be pinged when we have that kind of situation So I think what we need is an overview of which packages have upstream Python 3 support But no Python 3 binary and do we have that? Well, wouldn't you add a big spreadsheet of that does that still exist somewhere? Well So the spreadsheet does exist, but it's kind of limited in the sense of It was really focused on trying to get rid of Python 3 from the default images from server and then desktop and then Actually mobile was first and then server and then desktop because they were just more tractable So there's not really an overall one and the other problem with that is that pi pi The cheese shop is not always up to date all the metadata is not always up to date So when somebody releases a new version of the package that has Python 3 support It's and you can't always tell just by going to the cheese shop and looking at the metadata So I don't know what we can do other than try to be As opportunistic as possible Are there any Python 3 packages in Ubuntu that are not yet in the game? There's a few there's some There are some obscure soap packages which are not I Can't imagine that actually people want to use them But they're used for like launchpad or something crazy like that So I had to pour it a handful of them That were only in Ubuntu, but almost everything is and I'm really trying to be very careful to Make sure that everything is Backported into Debian, you know done in Debian first and then we can sync sync it back up into Ubuntu But you mentioned pi pi and we could fairly easily write a script that goes through all the Python packages in the archive Looks at pi pi and sees if they claim Python 3 support That's that will probably give us an overview of pack of really low-hanging fruit to work on As a package maintainer you're probably all gonna shout at me now But I think this is probably a real thing most package maintainers feel if I maintain a silly little library That's only I'm using and I'm not using from Python 3. I Don't add a Python 3. I often don't add a Python 3 package because it's pain. It's gonna have to go through new It's gonna let's it's gonna Sure, no I Do it, but it's a whole lot of extra work for something I know someone no one's going to use Can we start with the DPMT packages? They're all in our repo and we can work without Any we should just do them all yes So can somebody write a script that checks which packages actually can be ported to Python 3 because upstream supports it and Do any One can commit to that. I Was just saying whoever whoever said it in Gabby can you just add some action items and I certainly would Be willing to help with that I Have a question which is not about Python 3 support Yesterday I had the lindian warning on a package of mine that says don't use pi support And so I asked around how do you maintain Python packages this week? And it told me Python Python 2 and now you talk about pi build Is there going to is it like only one way to do it at some point and is there a promise that I learned that and not shoot Myself in the head in six months. Yeah DH Python 2 is the one way to do it right now all other helpers were either deprecated Or removed from archive Python central is already removed and no Other package is depending on that. It's using all of them all that we're using Python central we're already converted to DH Python 2 and Python support is deprecated and Actually a lot of packages were already converted and We just need some time to convert from the other ones Pi build is orthogonal to DH Python 2. Yeah, I build is like a DH wrapper that builds for Python 2 and 3 and pi there are actually few tools but Each of them does something different DH Python 2 is taking care of Python 2 packages The H Python 3 is taking care of Python 3 related Packages the H pi pi is taking care of pi pi packages So each Python major Python version has its own tool, but they actually do the same and I Separated them because we separate the Python 2 and Python 3 stack anyway So and at the beginning the DH Python 2 was written in the in Python 2 right now They all written in Python 3, but it doesn't matter much What matters is there's only one Helper tool which is not deprecated right now for each Python version. So you it's Pretty safe to say that The H Python 2 is the only helper that currently Is should be used and will be used in future and would it be supported by Python STDep at any time soon It already is. Oh, so STDep has been updated now. Yeah It uses STDep is using the short Debian rules on file which uses the with statement and if you Add with Python 2 it will actually run DH Python 2 and that's what STDep generates So you are if you are using STDep you are already using DH Python 2 It doesn't in Debian yet, but there's new upstream release that I didn't package yet, which Tries to generate Python 3 packages as well if it's described but described correctly in in PIPI This conversation makes me think maybe the wiki needs updating to reflect The content of that conversation Because I had a colleague at work who was looking to build some Python packages and he said well I found all these pages telling you I like three different ways to do it. So maybe we should Fix the wiki so it says you just this is the one way to do it Can you point us to this wiki page where which still describes and yes So always and then if you go to update it because we probably have too many Yeah, I mean like all wikis right it can use some gardening But I was I spent a fair bit of time going through wiki debian org slash capital P Python and trying to make sure that like there's it points to the library style guide which while there are many different ways of doing it is I would say a strongly opinionated page about One good way of doing it That includes both Python 2 and Python 3 and then there's another page that has this is a similar thing for Python applications, which has some different issues than Python libraries So if you find some pages that have Other suggestions definitely let us know because they I think they should be relegated to more like interesting historical facts Regarding page and three I think what I'm not sure for you guys but for me the biggest trouble is extreme support for on some key libraries On some I don't have myself the Enough skills to do the work for upstream It be maybe some some guys like you how are better than I I think so so Currently my biggest blocker is Python mem cache T if that one works with Python 3 then I have a bunch of like of other dependencies that will just Have Python 3 support So I guess that there's some other maintainers that have the same concern and Would it work if we identified those libraries? Which are the libraries that are looking for you for example? Memcache sounds like it's probably a very easy library because the protocol is very simple So some if you came up with a list of blocking packages like that. I'm sure there are people who could help The other thing I would suggest is that there's a mailing list called I think it's Python porting I might be on Python.org, but I don't remember but that's probably the place to go that's sort of You know if you want to connect with Python developers larger than just the Debian project Like if you have upstreams that you really want to get ported go there And and that's a good place to talk with other Python developers And you might be able to you know convince somebody to help upstream get where they need to go But I think I think upstream doesn't have support either have to go to upstream where you have to go to sort of go to the larger Community to help push that along Sorry So it's only about packaging the what's in get rebook a package that the kid It's more complicated in that there are there's a The web stream for version two doesn't have support and then there's two or three folks for Python three. It's complicated my case is probably not very Common, but I have a upstream which only supports Python 3 in the default bit so I Was pushing to Get all my reverse put dependencies updated with it's not possible State WX widgets, it's not ported anyway so the question is how we Still be it Python you know as a Stopgap methods to dependencies which are not reported, but it's a big hack and the problem is when I am allowed to drop the Python to package or not and when Actually planning to do it After this release, but if some some Python policies has no doubt do it and Continuous it bring it. I'm good. I would say if no one's using a library. It's safe to drop it You can up to cash our our defense your package and The problem is that the reverse depends are actually reverse suggests and reverse recommends so All of them are Reverse suggests and reverse recommends only so the problem is that for for doing the Python to version I need a code hack to have it the same thing twice and And I'm not sure what to support it because I would start anyone who is using this library for LibreOffice Has to support Python to be anyway because LibreOffice is only shipping the Python 3 version. I Would start with Reporting bugs that this package will go away soon. And that's what I did. Oh great We want the next thing So for Python 3 just to summarize we we need a document or a list of packages that we should focus on and We create I will help you bury with that and maybe we can Create as many Python 3 packages because before releasing Jesse as we can because Backporting to to wheezy should not be a problem because it in case package uses DH Python because All the needed Backports are already in wheezy. So Okay, so we will create a list of Packages It's down at the bottom. Okay, great. So we can move to the next topic If I might well This might be a different topic, but one of the things that I want to do and I haven't had time yet is to try to actually get rid of Python 2 in the default install and I think there's one or two blocking blocker packages. If I remember WBTS, I think needs to be ported That's related to to soap, right? Yeah. Yeah, exactly. The soap is so probably was this new library The forecast soap, yeah, I think yeah, I haven't had time to look at it So I don't know how realistic that is for Jesse probably not very but Maybe for plus one, you know, we can currently for when one of my packages have support for Python 2 and 3 and Chips something in user bin Then I use update alternatives to provide both things Is it the view that by default I should the view of the team that I should use Python 3 with higher priority If I or you I would ship Python 3 only Script so just ship if you have a script just ship it in the Python 3 package So that it will be easier for us to move to the Python 3 data Because if it doesn't matter if the script uses Python 2 or Python 3 just use Python 3 Then I don't think there's needs to use alternatives or things like that. I would just go to Python 3 Well, I'm walking the microphone over. I'll just say that there's only a couple of packages that Really have to have two and three supports like no is is one of them and a few things like that If it doesn't care just just ship the Python 3 version Well, I guess my question was if anyone has Come across a good way to help upgrade users in that situation because Right now there's packages where there's a script in you know Python food and if you add Python 3 support you're gonna have Python food Python 3 food and If you move the script to Python 3 food that user on upgrade isn't gonna have the script anymore Yeah, I I've come into that situation so like for example talks is one I did recently and There's a Python 2 there's a Python talks package and a Python 3 talks package and then I had I created Just a talks package and that contains the user bin thing So I think in the case where you have something that's both an application in a library It's in the long term. It's better to split those up so that you have the Python dash one is just the Python 2 library The Python 3 dash one is just the Python 3 library. Then you have another binary package that You have to be a little creative with the name. Maybe you can just name it after the source source package name or Whatever, but that's the thing that should include the User bin script and then that can just be Python 3 but that will work only for new packages somebody already installed Python dash And FTP masters might say no because your package has one file in it actually I Sponsored a package a few weeks ago that had exactly that problem Well, it wasn't a problem, but there was only one script in binary package and FTP masters accepted that so They often do but sometimes they don't and of course it should of course it should have at least two right, which is the man page If there's a good reason for example additional dependencies in this third binary package, then I'm sure FTP Masters will accept that Do we actually think Python 2 is going away anytime soon? I mean I talked to I talked to people who? write Python rather than Maintain packages a lot of them are showing no signs of moving to Python 3 yet It's not we are just starting to support it at work I mean write code that might work with it. No intention of using it It will not go away anytime soon that It doesn't stop us from moving forward to Python 3 until 2020 Python 2 is one of the best programming languages out there because they guarantee no API breaks I'll just say I Highly encourage people to at least start writing new code That if all your dependencies are there write it in Python 3 and you will not be sorry because it's such a better Language than Python 2. There's no question about it. I can say that unequivocally unequivocally and in fact Every new new stuff that I write is is Python 3 and I don't miss I feel like I'm in the andrethal when I have to go back to writing Python 2 so Python 2 will never go away probably for a very long time because there's just too much stuff out there But I think all new stuff should be written in Python. Yeah It has really some nice really nice features And at some point Upstream will stop will only have security updates for Python 2 those will probably go on for a very long time But at some point, you know, it's just it's just numbers, right? There's gonna be fewer and fewer upstream Python 2 developers who even care about it. So, you know I think I think if you can't do it yet plan for it and Start laying the groundwork because at some point you're gonna want to be in Python 3 so next item Which is Python support yeah, so can we do more in order to Remove Python support even before releasing Jesse or I mean the Python support package itself will have to stay in Jesse because To make the upgrades easier, but can we limit? Amount of packages that depend on Python support. Can we is it worth our time to? Do we have a lintian check for this? Yes, we have I think I at least I I think I Created a patch for lintian and send that but I'm not sure if because that's definitely the first step if not then DH by support Prince a warning every time it's invoked I think in the warning which DH by support invokes there's a link to the wiki page with all the bullet points that are needed in order to convert to DH Python 2 If lintian tag doesn't so there is a lintian tag And I think 150 packages have it right now how many downs from 250 in September in In Debian Python modules team or no in the whole archive so What can we do to encourage people to convert to DH Python 2 before Jesse? We cannot do that because It needs to be in Jesse in order to do that upgrades Smooth it actually the package with Python support package provides some scripts that are used in in maintain our scripts of older packages, so it has to Has to stay in Jesse, but we could remove the DH Python The binary that gets called during the build process though I think release managers would not be happy We first probably need to get over you how many packages we are talking about anyway How far do we have to get before we do a mass bug filing on these packages? Sounds good So maybe we should start by migrating the DPMT packages and then see where we go from here I wonder is it Does it is it's sensible to prevent somehow to prevent new packages from Or I guess not nothing new is going to use Python support, but maybe that goes to your question whether we can actually Hobble, but yeah, exactly hobble it so that upgrades work, but nothing new can be built with it We have to convert all the packages currently using it first Would it work to just ask the ftp master to reject any new upload with Python support So that every new upload would need to be converting the package There's a lintian tag already right we can ask ftp masters to reject every package that triggers this lintium warning or your You don't want to you don't want to break RC bug fix uploads and that kind of thing and you can't really do that before having Fight bugs and provided batches. That's not nice So first step will be convert all DPMT packages. That's what we have to do first Yeah So if anyone wants to work on that I'm willing to sponsor any Uploads So just email me or ping me or on IRC It's a good task for Newcomers maybe at least for DPMT packages nobody will complain if you are afraid of that If we killed everyone who'll complain already Next topic Stefano, what can we do to help you with pipe pipe? I haven't even started yet I actually I wanted to have something ready before they've come but I've been busy I Could use extra maintainers on pie pie. I feel a bit like I don't want to be the only person working on it It's a crazy complicated package to be nice if I had some other people Pie pie 3 is now officially releasing. So yes, we should do it the What are the questions we can share this packages with CPython 3 I think It should work the complication to be C extensions But you shouldn't be using C extensions with pie pie. So maybe we can avoid that one. I Have seen a lot of libraries now when they're trying to support pie pie. They're using CFFI So if they continue to do that, we should be okay We just need some dependencies that say There's no sane way to structure the structure dependencies in a Python 3 library package So that it'll work with CPython 3 or pie pie 3 Because Either it should depend on one of the two or what should depend on one or the other But then if you have the one installed it won't work If we'll use that This packages from Python 3 then we probably have to mark such packages I don't know as provides pie pie something or Because right now all the pie pie all the libraries that that support pie pie have new binary packages I actually kind of forced you to do that because I created a simple json But we had to do it that way because we didn't have pep3127 in I think The pie share directories in Python 2.7. I mean only for Python 3 by pie 3 Yeah, yeah I'm sorry in Python 2 we couldn't in Python 3 we can Don't know if we should but we certainly can that was the point of pie shared so you should probably try and do it And I was just gonna ask what what about Like the rules file too, right don't we need to add you know with pie pie 3 to Yeah, everything You'll need it with Python 3. Oh, you don't need a new binary package. I was gonna say you also need a package. Of course, you don't And the HPI Pibles gonna have to learn to run tests for Python 3 Yeah, but it's not a problem to create the HPI by free and which will yeah, but I'm wondering what what it needs