 Okay, hello everyone, my name is Petro Zharowski and this is Python buff there's gobi-document on gobi-debian.org with a agenda, but We can ignore it and talk about anything Debian Python related if you have questions remarks anything that can be improved in the Interpreter itself or mostly in helper tools so Speak up. There's a mic on each table, I guess so This is recorded and If you can then please use my So what's bothering you in related to Python It's pretty much so it's pretty much done. I just need someone to say that looks good. Let's go for it Which no one has done yet. I Don't think anyone else except me looks at it yet So I I've got a draft migration up on Alioth. I Can do a new one and then just need to go ahead. I Will take a look at let's say my package with packages. I know well and then I Will say whether it's okay or not That'll be great. Thanks. Okay But probably other people that should do the Yeah, should do check. Oh once a few people are happy. I think we probably find okay and then get DPM migration will follow to get GPP That's a good question Been switching up Repositories to get DPM or what? So for perhaps I did not do DPM. So, okay But I'm switching to PQ is still going to take PQ is something you can do locally It's not something that the repository needs to be formatted for when you use PQ I think it's going to change all your patch names, but that's fine because that's something you do when you edit the patch series Dimitri says you can keep the names yeah, and Get build package patch queue if inside they commit that it generates you add GBP Patch queue topic or name You can specify the exact name you want the patch to have such that if you generate that metadata name space Blah blah blah dot patch it will be blah blah blah dot patch when you export it okay And when you import it doesn't generate that I don't think it generates that by default But if you do add those magic lines inside the commit message it will become round trip safe In terms of patch names If there's something we can put in a GBP.com to make that happen by default we should be doing that I Would love to find out if there is such a con Um the related thing about get is branch names So I'm exported all the master branches as master Dep 10 says that should be Debbie and slash master or depth in some cases Debbie and slash Sid We should make a decision Anything that is not master is okay I think just avoid having master as the packaging branch because it may conflict with upstream like almost every person use master If we're using a source Tarbon flow rather than emerging from upstream get repo flow that doesn't matter But I guess people are free to use whatever flow they want Yeah, I prefer to have Tarbos only but Not so There probably should be exceptions if people really need the upstream branch but By default I think in the better way for us is to keep the Tarbal Yeah So The thing is if we want to not use master, we currently might using master from D4 DPMT. So then we must change DPMT Probably do we want to do that wholesale? That's going to be a breaking change on everyone is using the repository so we can have to coordinate it well I don't have experience with you So I will Just shut up for a moment. I'm not I don't have a strong opinion because I I'm not using PQ yet So I don't think using PQ really has anything to do with the branch name Just that we're doing big conversion. So let's get the branch name, right Yes, I'll need to do some work to make that happen. But yes Yeah, what does What does git build package with PQ use by default does it use I assume it's up to you We can configure that in the Debian Gbp Actually, no, I assume it uses master by default. I think default master is the default but you can configure it. Yes So by default Gbp will will Refuse to build in in the branch that is not described in Gbp.com, but you can also tell it to Not be annoyed by it and it's going to build so it's best not to specify it in Gbp.com. That's what One range has been doing on our packages Yes, it's option for Gbp which Jit ignore branch Which means it don't check if current branch matches that one in Gbp.com that's what you want it, right and It's not needed to be put in every package in Gbp.com You can have one global config and they can put this option and Doesn't matter then that sounds like something we should encourage our users to do then is anyone taking notes It was my goby pads tail. Okay. Let me reconnect then any other questions. No, we can talk about by to do and removing it from the archive so We probably should announce it to users somehow release notes that Removal of Python 2 which will happen at some point probably Not definitely not in Buster and probably not in bullseye But we should prepare for it so my idea is to My idea is to We already don't provide Python 2 binary package for packages for new Packages We are not actively removing the old ones yet, but Maybe we should consider it We definitely should Add a note about deprecating Python 2 in Buster's release notes, I think and Start removing Python 2 binary packages in bullseye, maybe or I Don't know if Buster is too soon Or should we at least those that don't have Reverse reverse dependencies we can start removing now, but I would not be in such a hurry For now, maybe Do you have different opinions? So during depth camp we had a well both About removing well getting rid of more and more Python 2 Dependencies but without the goal to remove Python 2 itself for Buster and we came up With well a lot of things to do And That resulted of us wanting to to have a mass bug report filing That was announced to Debian Python and Debian develop So there are one or two people who are against such a filing Both not members of the Python community or Python packaging community inside Debian So we will end up with more than three thousand bucks to file and We wrote down the different classes of bugs we intend to file in a wiki page That's wiki.debian.org sprints 2017 Python 3 Montreal So just saying we want to remove Python 2 doesn't work. We saw that During the last few years People if people are not moving or doing the conversion actively Nobody's doing that and it's still stand. So we don't move forward So so I would say we need these bug reports So we can measure how far we are away from Removing Python from the distro and Well, if If we can remove Python 2 for Buster, that's okay, but honestly, I don't think that's Doable because we still have applications not ported to Python 3 how about Removing as many Library packages as possible, but keeping the interpreter itself for now Even even when all packet Python 2 packages are removed the library once How about keeping the interpreter itself for one more release when the All other things are removed. I think it's too early to talk about that because we still have applications using the interpreter Right, so so if you want to remove Python 2 libraries, which are not used which are leaf packages then Yes If you want to to do that analysis on file bug reports about it, then please do it I would say that's at least worse having the information Yeah, because we don't have this information we speculate and we can't come to any conclusion So you're already during the sprint you already have a list of packages affected and only the bug reports are missing or Sorry, no, I didn't I did not do that analysis. So I maybe I can So we wanted to file bug reports for four classes so That these are packages providing a Python food binary package, but no Python 3 food binary package the second class is We wanted to file Reports for packages which use Python things, but not Python 3 things That means if we can use Python 3 things to build the documentation, we should do it There are cases What was it for autodoc where you import the The modules into the same process. So you still need to Be able to to build with with Python 2 if you have a Python 2 only module So and then we have some some binaries in in usr bin and So from my point of view it doesn't make sense to provide such binaries for both using both Python 2 and Python 3 so we should just drop these because Well, we have name conflicts there are several solutions currently How to make these binaries coexist either by appending the two or three or by using alternatives. So I Think that can go away and we should just use the binaries using Python 3 And maybe split Split out these binaries into a new Well, they've been binary package or just keep them in the Python 3 binary package and Sorry Then we have Applications still using Python 3 instead of Python 2 and So that would be packages which have a dependency on Python 2 but are not called Python dash foo itself and We should try to find out if these Are already ported to Python 3 or if they can be ported to Python 3 So these are the four four classes. I mean we could add the another class To to remove leave Python 2 only packages If they have Python 3 counterparts Maybe we should keep some Python 2 packages if they don't have Python 3 counterparts I Don't know. Yes. So that that's the So who of you are looking at other bug reports before you upload a Python package And fix these bug reports Yes Because I always check the list of bug reports and whether there's something to fix Because there was a concern that we found these Amount of bug reports and nobody closes them So, yeah But that's what back reports are for so I don't see a reason why not to This seems like a normal result of any mass bug filing. Yeah Like from my point of view, I think, you know, this is 2017. We should not have any user scripts Executing Python 2 in slash user bin Well, yeah, and and like to me, this should be like a wishlist lenitian in a couple of months time a Medium lenitian and then like a warning and then like an auto FTP master reject, you know Because like honestly, we don't want Python 2 anymore If we suggest this to Lammy, he'll probably make the lintian checks for us. So Oh Because lamp wanted to join the The buff last week, but couldn't do The good thing is that he wrote two or three lintian checks to help with these goals So you will find these as well on your favorite bug tracker or package tracker page So do we agree that such bug reports should be filed should we wait How long so we wait? Maybe start with a wishlist and then keep upgrading the priority Not sure about the libraries, but like for example anything that ships Scripts and executables and user bin or whatever. I think those need to go now like or probably like last year As in those are overdue Application works with Python 3 then definitely if it doesn't then even if it doesn't work Remove the application like people can install it from to shop if they want to I'm probably more progressive than most people You know, maybe it will If people will see that you will not be in Davian unless you are an Implication that uses Python 3 maybe that will finally start motivating people Like I was not removed such applications for now, okay So then there came up another question should be Yeah, what will happen with a Python executable so user bin Python And so and unless you kick both Scott and me from Debian Python defaults User bin Python will not point to Python 3 Unless I mean that Python 2.7 is removed from the archive Yeah, if it's really if it's If it's removed my idea is to have at least one Debian release without user bin Python simulink so that the System administrators that use Python 2.7 and upgrade from the previous release They probably will not remove Python 2.7 package. It will most probably work in the next release So let's keep the user bin Python Let's remove it and let administrator Re-add it if they want and then in the next release we can add it back pointing to Python 3 that's my idea so So I'm not sure about what you said So unless there is a Until there is a Python 2.7 package in Debian user bin Python simulink should not be changed. Okay. No, that's fine. That's fine So I think everybody agrees with that great However If we have So so Python upstream well expect to have a Python executable at least ignore upstream That's my that's what I say. So so last time when I was adding the Python 2.7 link Before the PEP was finalized I was told you have to have to follow upstream now you tell me I should not follow upstream Yeah, okay, so I In the meantime upstream change their mind because of no, well, they are they are going with the time by Debian stand still and I think In a few years nobody will understand why Debian doesn't have a Python executable and Nothing else. So I think we should prepare for the time when we will have a Python executable again Yeah, so we should start we we can start so if you if you disagree that much then you should get involved upstream because there's a new PEP talking about reintroducing a Python executable and I think working against the upstream community is just plain wrong So I made the proposal we should have at least a Python Debian release Without a Python executable before doing something else about the executable. So that would give users Hint while my scripts my local scripts. Yes. Just using Python don't work anymore So I have to adjust either by to moving to Python 2 or to Python 3 if the release without the same sim link is The same the first one without Python 2.7 then that's exactly what I am proposing One release without Sure, but but then we should well, we should not say We will never ship a Python We should never We should never we should we should not say we will never ship a Python binary again That's not what I am saying. Okay because It sounded like that all I meant is that Until we have Python 2.7. We should not change the sim link once we remove the Python 2.7 from the archive We should for one release remove the user been Python sim link as well then in the next release provided again pointing to Python 3 Yeah Can I interject from the audience a question? So I Really don't like the situation as a system administrator where if I have to reinstall a machine from scratch I won't get Python 2 and I'm expected to have Python 2 question mark in order to keep running programs Like I have a fleet of Python. I have a fleet of Debian say stretch machines I upgrade them all to Buster or let's say to next release if Python that's the one where Python 2 is gone I have Python 2 scripts. I'm still using them one of these machines has a disfail here I reinstall from a scratch this package is gone There's no way for me to get Python 2 other than taking out a dead from the old release and running deep package. I don't That feels like a weird place to be my my also concern in addition to that one is that it seems to me that you're happy to leave Machines intentionally insecure and vulnerable and running something huge as Python 2 and Leaving it on disk and not forcing removal of it simply because of convenience to keep local stuff running despite the fact that it's to me It's a security liability to even keep 2.7 on upgrades You know either remove it completely or keep providing it, you know, you cannot you cannot say it's not available for new installs And say that you don't support it Because clearly it will remain on disk for all the people who upgrade and then they are Effectively, but it's not in the archive. So we are not supporting it that the administrators that will not remove it Should know what they are doing But I would not force them into if they want an unsecure interpreter then that's their call. I would not try to force them into reinstalling Python from source or Rebuilding leaving packages on this is not something uncommon we do that and and and I think that If you do leave it on disk Then when you do switch Python to point to Python 3 you're back at the same problem that you wanted to avoid in the first place That's one. That's why we want one release without user in Python. So that administrators notice The thing is if you don't remove Python on upgrade people don't notice How about having we will not remove the interpreter, but just the sim link. So if administrators How about having How about having a Python 2 legacy package that would carry that sim link and Then like administer it's advice not to use it, but then if you really need it, then you can use it Knowing that it's wrong. I have this feeling that someone is going to be providing a supported Python 2.7 of some sorts and People are probably going to be running it But we also don't need to get into this discussion right now because it is still premature. Isn't it? We're not talking about removing libraries. We're talking about removing what happens when we remove the Python interpreter It's just I don't see any benefit in waiting for one release Because the sim link will remain on disk for a lot of people Why will it remain on the disk because the easiest thing for a sysadmin is to recreate the sim link That's a one liar And I think the thing that you're trying to avoid or to warn people or prevent things that When you do switch Python to point to Python 3 you're going to get the exact the same amount of breakage And waiting for one release only makes things complicated for us to make that change without actual any user benefit unfortunately So as in the the benefits of waiting for one release without a sim link Actually will create a lot of negativity that Debian doesn't ship Python And it will not actually gain any benefit in the upgrade case or the new install case So you want to break up you want to break the system of the user to just make sure that they know that we're not shipping it Yes, unfortunately, I think if they wanted to work they're going to make it work And breaking it on them making it really hard for them to make it work just pisses them off so You are living in a comfort zone with Python 2 because Python 2 doesn't didn't change for the last 10 years So Right, and I mean We ship new compilers we ship new perversions And so many local scripts should break with these changes So I think I don't want to special case Python at this point So do you want to have one Debian release without user been Python sim link or I Don't care that much about the once we remove Python 2.7. Yeah, I don't care about the server I think I think the benefit of running Python enter and That it launches something is better than running Python enter and it says command not found And I think having a release with command not found will be extremely scary to a lot of people I Think there are more system administrators that depend on the User been Python then users that type and don't use So for completeness there were some proposals on the Debian Python mailing list that We should do something if The user types Python and there's no Python interpreter available So that might be a shell shell alias Which looks is it an interactive invocation and then just point the user either to Python 3 or Even starting the Python 3 interpreter. So is the command not found package there Which is not installed by default in Debian So there are proposals to to work around that for the interactive case just Without saying is that if you are proposing to provide some kind of script that will detect if it's run inside a Terminal or as a shell script, and I don't think this is a good idea because there are lots of Applications that will slow down Yeah, no, I have just pushed a branch 10 seconds ago To Python mux that if you are running Python 3.5 will run So using lib Python and skip the exec and so it does very little checking It just checks is a tty zero or something like that and so in the common case your slowdown over User been Python actually being Python 3.5 is minimal So it links lib Python 3.5 it looks at what is the file? I'm running do I look like I'm interactive or does the file look like it's Plausibly Python 3 or does it have a shebang Python 3 which is all work that you're doing anyway If all that is true, it will just run py main out of lib Python 3.5 And so we can benchmark it, but I think that that's I'm gonna I would like to advocate More aggressively for that because I think that's the best solution I think that having a release where user been Python is missing is going to be weird for everyone having a release where Some people have user been Python on their Debian Buster systems because That's where our next version systems because That is what happened one upgrade and somebody else upgrades and then you have like people asking for help And I'm like I can't get Python to run your I'm like, what are you talking about? I run Python. I have the same version of Debian I think that's gonna be a very bizarre situation for everyone I think it's gonna be even more bizarre compared to what other upstream districts are doing I want to know if we feel comfortable with this approach And I also want to sort of pitch it at the other distros I think the other distros have sounded the red hat in particular sounded interested in we should do something with this multiplexer Yeah, and I mean but if we We already agreed that if there is a Python 2.7 package We should not change the assembly right? So once it's removed there is no need for any screen that detects if it's Meant to be run as Python 2 or 3 we can just provide a Python 3 the same link to Python 3 Correct and not wait a release. Yeah I mean multiplexer sounds fun. I was considering removing it for one release just to people to System administrators to notice that but if it's a problem, I mean for me, they will probably notice if if Their applications are run under Python 3 and break as well. So maybe it's there is no need to I mean If we today can upload something which when an interpreter launches a script which has she bang user been Python Raise a warning in the future. It will be ambiguous Please either use user been Python 2 or user been Python 3. Please make a choice now Because because you know a failure mode where you get interpreter not found is not nice Like from the kernel like you cannot exactly binary because the user been Python is missing That's not nice if you get an error message that print is not a function or I don't know what the keyword print is I think that's okay. I think people will understand what's happening That's something has to be done in interpreter. Yeah We talked about Because there was an easy way to replace all the shabangs At least for packages that use DH Python 2 from user been Python to user been Python 2 I can do that in DH Python. Yeah, and we packages are we okay to do that now For example It doesn't it makes no difference in Yeah, I don't know if there's a gain, but there's no downside so I can do that That would be useful because that will give a lot of hint to people as What I should do with my scripts if all the system scripts use user been Python 2 then maybe I should use the same Because people mimic what's happening in packages I should shut up So so then the question is if we if we now make our packages be Python 2 or Python 3 would then Something that is that is invoking the shebang with plain Python would that then say and please make a choice now Or would that say? This is going to switch over Unless you're prepared for this to switch and make Python 2 explicit So would that would those scripts be recommended to if they are if they are Python 3 Compatible and would they be recommended to say Python 3 anyway, or would they would it be okay for them to stay Python 3? So that's basically the question is what would the word wording of the warning be? When a script is run that is you that it has shebang user been Python Would it say and please make a choice now either say Python 2 or Python 3 What would it say if you're insisting on Python to make it say Python 2? I have a question for the room particular people who run mixed environments Is it useful to you or do you anticipate it being useful to you to write scripts that are compatible with both? Python 2 and Python 3 and can run on both rel 6 systems which have only Python 2 and Debian 11 systems that have only Python 3 is that a use case that we want to attempt to support or not Sorry Okay, I'll repeat it. Is it useful to have some mechanism to support running scripts on both Running Python 2 and Python 3 compatible scripts on both really old systems like rel 6 whether does not have a Python 3 or something or like Mac OS which does not have Python 3 and also on New Debian systems that only have a Python 3 or let's say new Ubuntu live CDs that only have a Python 3 and don't have a Python 2 is it worth supporting this Currently if we go the route of letting user been poised Python point to Python 3 in the future That will solve this problem at the expense of different problems, which is incompatibility I mean I had a joke proposal to have user been Python 2 or 3 as an interpreter she bang Sure, but we have about two minutes. So I don't know guys want to wrap it up. So I'm not sure about that Python 2 or 3 thing because if you Well, if you have simple script scripts, you You can convert these to Python 3 or Python 2 and there's no need to To run them under Python 2 even if if they work and if they work on Python 3 and and when you have more complex scripts You are adding third-party dependencies and then you have to to have Well these monies installed for for both and that becomes a very complicated Situation so so I'm not sure About that proposal so so we are almost out of time, but If you have any more questions Please don't hesitate to ask us at least when it comes to Python helpers you can contact me or Mattias if it's related to the interpreter and Thanks for coming and Thank you