Re: MBF for deprecating Python2 usage
Steve Langasek writes: > FWIW I don't share Ben's concern about this being a "backwards > incompatible" change (who is relying on the precise contents of the > banner when running 'python' interactively?!). That's not a backward incompatibility anyone would seriously rely on, and I don't have that concern. The backward incompatibility I'm concerned about is: to have ‘python’, which today invokes Python 2 and some uncountable number of scripts rely on, change on a near-to-medium future upgrade to instead invoke the backward-incompatible Python 3 hence breaking those scripts. Merely noting a change in the interactive prompt's banner is, I agree, inconsequential by comparison. So that's not the objection. -- \“All opinions are not equal. Some are a very great deal more | `\ robust, sophisticated, and well supported in logic and argument | _o__) than others.” —Douglas Adams | Ben Finney
Re: MBF for deprecating Python2 usage
On Mon, Aug 07, 2017 at 08:11:40PM -0700, Diane Trout wrote: > > What I am opposing is the suggestion to install, in the near to > > medium > > term, a command of exactly the same name that has subtly similar but > > incompatible behaviour, when that behaviour *already* has a command – > > ‘python3’ – that is widely used by those who need it. > my problem with that plan is all of the printed documentation saying to > learn python, type "python". > At the very least there needs to a usr/bin/python that prints > instructions about what you should run. FWIW I don't share Ben's concern about this being a "backwards incompatible" change (who is relying on the precise contents of the banner when running 'python' interactively?!). But I am concerned about possible implementation strategies here. exec() is a very expensive syscall, and python is a frequently used interpreter. If this were implemented as a wrapper that checked isatty(), printed a banner, and then re-execed the real python, that could have a measurable performance impact on some applications. There is a reason /usr/bin/python, /usr/bin/gcc, etc. are always symlinks to the real interpreter on Debian, not wrapper scripts - other distributions have tried to do this as a wrapper script and the result wasn't pretty. Avoiding the performance hit would require that any changes to the banner be made in the python source itself. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: MBF for deprecating Python2 usage
On Aug 7, 2017, at 20:52, Ben Finney wrote: > > So IMO the conservative assumption is that they expect Debian to provide > the stability it is famous for, and not to break the behaviour of > commands unnecessarily. There’s another dimension to that too: it’s people who expect no changes to the command called /usr/bin/python *and* want to track the latest and greatest Debian releases. Maybe that changes the equation and maybe not. Certainly any large organization with tons of Python 2 laying around is going to be much more conservative about upgrading their entire distro than individual developers who just use unstable and get whatever today’s snapshot looks like. And to reiterate, I’m not arguing that /usr/bin/python change today or even at the end of Pycon 2020 when 2.7 is officially EOL’d. I’m saying that it *will* change some day and that we should plan that change, if for no other reason than to set the expectations of exactly those folks who are not part of this conversation. Cheers, -Barry signature.asc Description: Message signed with OpenPGP
Re: MBF for deprecating Python2 usage
Diane Trout writes: > On Tue, 2017-08-08 at 13:24 +1000, Ben Finney wrote: > > > > Those people, not party [to] this conversation, have reasonable > > expectation that such breakage will not happen without very good > > reason. > > Good reason would entail, as an example, that there is no better > > alternative. > > Why not ask? Ask whom? Because the issue is about the expectations of those who *don't want* to be bothered by technical discussions like this, asking those few who make themselves available for such questions will not resolve the issue. At best, we would have a collection of anecdotes and no idea how representative they are of those who choose not to be contactable (but still expect Debian to avoid breaking things unnecessarily). At worst, we would have a collection of anecdotes that would be a strong temptation for *falsely assuming* they represent the silent majority. Barry, earlier in this thread, was correct when he pointed out that, by the nature of the issue, we *can't* know with confidence what the majority of people expect about this change. So IMO the conservative assumption is that they expect Debian to provide the stability it is famous for, and not to break the behaviour of commands unnecessarily. -- \ “Some people have a problem, and they think “I know, I'll use | `\ Perl!”. Now they have some number of problems but they're not | _o__) sure whether it's a string or an integer.” —Benno Rice, 2011 | Ben Finney
Re: MBF for deprecating Python2 usage
On Tue, 2017-08-08 at 13:24 +1000, Ben Finney wrote: > > Those people, not party ot this conversation, have reasonable > expectation that such breakage will not happen without very good > reason. > Good reason would entail, as an example, that there is no better > alternative. > Why not ask? I know people in training groups like software carpentry? Does anyone know sites with large python deployments? I'd love to know what Apple is going to do about this issue. Also if we do come up with a migration it should happen at a release and be clearly reported in the release notes. Diane
Re: MBF for deprecating Python2 usage
Diane Trout writes: > my problem with that plan is all of the printed documentation saying > to learn python, type "python". I agree that's a problem. I don't agree that making a backward incompatible breakage is justified by widespread documentation giving bad advice. -- \ “There are no chaplains in foxholes.” —Sergeant Justin | `\ Griffith, 2011-07-27 | _o__) | Ben Finney
Re: MBF for deprecating Python2 usage
Diane Trout writes: > Personally, I'm ready for python to point to python3 now. I appreciate that. In many of my hours I even concur. Both of us can have that, for our own personal environment. That doesn't answer the question of changing the behaviour of the *default* ‘python’ command installed by Debian packages, for people who have not asked for this breaking change. Those people, not party ot this conversation, have reasonable expectation that such breakage will not happen without very good reason. Good reason would entail, as an example, that there is no better alternative. The use cases provided in favour of “make an incompatible change in what the ‘python’ command does, by default” so far do not meet that standard. People who *actively want* ‘python’ to mean Python 3 can set up their environment that way today, without affecting others who have not asked for anything to change. So the desires of those people – and I can even count myself one of them! – should weigh less than those who expect the stability promised by Debian. > Python has been remarkably good at avoiding breakage, but I've seen > other scripting languages have serious incompatibilities with far less > warning. That is not an argument for changes that break default behaviour. > It might be useful to add an option to the interpreter where if a > python script is launched without a usr/bin/python2 or usr/bin/python3 > header it reports a deprecation warning (either to console or syslog) > so it's easier to find programs that still need updating. That sounds good to me. -- \ “I was stopped by the police for speeding; they said ‘Don't you | `\ know the speed limit is 55 miles an hour?’ I said ‘Yeah I know, | _o__) but I wasn't going to be out that long.’” —Steven Wright | Ben Finney
Re: MBF for deprecating Python2 usage
> What I am opposing is the suggestion to install, in the near to > medium > term, a command of exactly the same name that has subtly similar but > incompatible behaviour, when that behaviour *already* has a command – > ‘python3’ – that is widely used by those who need it. > my problem with that plan is all of the printed documentation saying to learn python, type "python". At the very least there needs to a usr/bin/python that prints instructions about what you should run.
Re: MBF for deprecating Python2 usage
> What tearing need is there to change what the command ‘python’ does, > in > a backward-incompatible way? Personally, I'm ready for python to point to python3 now. I'm tired of writing python 2/3 compatible code because someone _might_ launch a script with "python my_python3_script.py instead of ./my_python3_script.py Python has been remarkably good at avoiding breakage, but I've seen other scripting languages have serious incompatibilities with far less warning. For example R packages need to be recompiled for point release updates. Some perl scripts we inherited broke somewhere between perl 5.8 and 5.12. Users have tools like virtualenv or conda to deal with the incompatibilities. It might be useful to add an option to the interpreter where if a python script is launched without a usr/bin/python2 or usr/bin/python3 header it reports a deprecation warning (either to console or syslog) so it's easier to find programs that still need updating. Diane
Re: MBF for deprecating Python2 usage
Geoffrey Thomas writes: > We will not indefinitely provide a /usr/bin/python that runs Python 2; > we probably will do so for at most one more stable release. I'm fine with removing the ‘python’ command, because that command means Python 2 and Python 2 is going away. What I am opposing is the suggestion to install, in the near to medium term, a command of exactly the same name that has subtly similar but incompatible behaviour, when that behaviour *already* has a command – ‘python3’ – that is widely used by those who need it. -- \ “From the moment I picked your book up until I laid it down I | `\was convulsed with laughter. Someday I intend reading it.” | _o__)—Groucho Marx | Ben Finney
Re: MBF for deprecating Python2 usage
Barry Warsaw writes: > On Aug 7, 2017, at 18:28, Ben Finney wrote: > > > That day [when we know that the vast majority of scripts in the wild > > no longer expect Python 2 when invoking the ‘python’ command] might > > never come, in which case the ‘python’ command will forever mean > > Python 2. That is, I'm saying, better than breaking that command in > > the near or medium future. > > I wonder if you’ll say the same thing in 2030 when Python 2.7 is 10 > years dead, can literally cannot be built on any then-modern Debian, > let alone Linux distro? Why do you wonder that, in the context of this proposal? That proposal is the context of my statement above. In the context of the proposal now before us, to change the behaviour of the ‘python’ command in the near-to-medium term, it seems irrelevant to wonder what I'll say on the matter in 2030. Of course, I'm open to Python 2 dwindling into the past; it is inevitable as the years go by. But in 2020 that won't be the case, and we should be very conservative about declaring it to be the case because – as you point out – even in 2020 we cannot be confident that we'll know what the vast majority of scripts out there expect. > Sure, today. And tomorrow. And many tomorrows until at least 2020. > Then I think we’ll be having very different conversations about it. > Anybody who will still be running Python 2.7 code will have some > difficult choices to make. 1) port to Python 3; 2) run old versions of > distros that still have Python 2.7 around and live with the > unsupported nature of it; 3) roll their own Python 2.7s; 4) pay some > commercial vendors to keep their stuff alive and secure. I see no good reason to make that job *more difficult* by wantonly changing what interpreter is invoked with the ‘python’ command. Especially because it isn't even something needed for Python 3 to flourish. What tearing need is there to change what the command ‘python’ does, in a backward-incompatible way? We already have a ‘python3’ command. Scripts written today must explicitly choose ‘python3’ to get that version of the language. Learners learning today must explicitly ask for Python version 3. > IMHO, there will absolutely be a day when it makes no sense to point > /usr/bin/python to Python 2. We agree on that fact. There is some disagreement about how many people, whose voices are not part of this conversation, can be dismissed before that day arrives. And when they can reasonably be dismissed. -- \ “We demand rigidly defined areas of doubt and uncertainty!” | `\—Vroomfondel, _The Hitch-Hiker's Guide To The Galaxy_, Douglas | _o__)Adams | Ben Finney
Re: MBF for deprecating Python2 usage
On Tue, 8 Aug 2017, Ben Finney wrote: The issue is: Invoking ‘python’ today gets an interpereter, Python 2, that will work with some code and not others. It should not tomorrow invoke an incompatible interpreter without *knowing* that the vast majority of scripts in the wild no longer expect Python 2 to come from that command. That day might never come, in which case the ‘python’ command will forever mean Python 2. That is, I'm saying, better than breaking that command in the near or medium future. I'm saying it's a bad idea for ‘python’ tomorrow to get an incompatible intepreter that won't run the same Python code. That interpreter is named ‘python3’ and should never be installed as ‘python’, because ‘python’ is a command that many scripts expect to invoke Python 2. This conflates the role of the interactive Python interpreter (which is what Diane was referring to) and a script interpreter. #!/usr/bin/python and `python -c` are ABI referring to Python 2, yes, and can't start running Python 3 any more than /lib/libc.so.5 can start being glibc. But there's no reason this should prevent typing "python" from giving you a Python 3 interpreter. Since I think it hasn't been linked recently on this list, I'll re-link this project, which separates the two roles: https://github.com/geofft/pythonmux https://ldpreload.com/blog/usr-bin-python-23 Keep in mind that we do intend to break the ability for /usr/bin/python to run Python 2 code in less than three years (unless we're interested in providing security support for Python 2 when it's dead upstream, which I hope nobody wants to do). We will not indefinitely provide a /usr/bin/python that runs Python 2; we probably will do so for at most one more stable release. The only question is whether it should break by giving you an error message (either ENOENT or something printed on stderr), or break by trying to run the code as Python 3. -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Re: MBF for deprecating Python2 usage
On Aug 7, 2017, at 18:28, Ben Finney wrote: > The issue is: Invoking ‘python’ today gets an interpereter, Python 2, > that will work with some code and not others. It should not tomorrow > invoke an incompatible interpreter without *knowing* that the vast > majority of scripts in the wild no longer expect Python 2 to come from > that command. That’s unknowable. We have no idea what people do with any package of Debian outside of the archive. We can’t even quantify what “vast” means. So under the above definition, you’re right, that day will never come. > That day might never come, in which case the ‘python’ command will > forever mean Python 2. That is, I'm saying, better than breaking that > command in the near or medium future. I wonder if you’ll say the same thing in 2030 when Python 2.7 is 10 years dead, can literally cannot be built on any then-modern Debian, let alone Linux distro? That’s not hyperbole; one of the current upstream exceptions to the 2.7 branch is to adapt to newer build systems and library versions. That will stop in 2020, but of course everything else will continue to evolve. It might even come sooner. Once Python 2.7 is EOL’d, it won’t even get source releases, and may not even get security releases. If folks want to keep it alive, it’ll take active downstream resources to maintain. People may pay for commercial support from RedHat, Canonical, and others, but how much will volunteers want to keep it secure and working? I can remember when ‘python’ meant Python 1.5.2. So that name doesn’t have to be tied to a specific major version. > I'm saying it's a bad idea for ‘python’ tomorrow to get an incompatible > intepreter that won't run the same Python code. That interpreter is > named ‘python3’ and should never be installed as ‘python’, because > ‘python’ is a command that many scripts expect to invoke Python 2. Sure, today. And tomorrow. And many tomorrows until at least 2020. Then I think we’ll be having very different conversations about it. Anybody who will still be running Python 2.7 code will have some difficult choices to make. 1) port to Python 3; 2) run old versions of distros that still have Python 2.7 around and live with the unsupported nature of it; 3) roll their own Python 2.7s; 4) pay some commercial vendors to keep their stuff alive and secure. IMHO, there will absolutely be a day when it makes no sense to point /usr/bin/python to Python 2. Cheers, -Barry signature.asc Description: Message signed with OpenPGP
Re: MBF for deprecating Python2 usage
Diane Trout writes: > My suggestion was "the startup banner should print what command to run > to get Python 2." Thanks for the suggestion. I think it's a bad idea. > I was thinking of the case of the end-user trying to follow a Python > tutorial. They'd still need to exit and run the python2 command if they > wanted 2. That's not the issue. The issue is: Invoking ‘python’ today gets an interpereter, Python 2, that will work with some code and not others. It should not tomorrow invoke an incompatible interpreter without *knowing* that the vast majority of scripts in the wild no longer expect Python 2 to come from that command. That day might never come, in which case the ‘python’ command will forever mean Python 2. That is, I'm saying, better than breaking that command in the near or medium future. I'm saying it's a bad idea for ‘python’ tomorrow to get an incompatible intepreter that won't run the same Python code. That interpreter is named ‘python3’ and should never be installed as ‘python’, because ‘python’ is a command that many scripts expect to invoke Python 2. -- \ “Reality must take precedence over public relations, for nature | `\ cannot be fooled.” —Richard P. Feynman, _Rogers' Commission | _o__) Report into the Challenger Crash_, 1986-06 | Ben Finney
Re: MBF for deprecating Python2 usage
> I disagree, it's a bad idea to actively take steps to make the same > command invoke *incompatible* programs depending on the time and > host. My suggestion was "the startup banner should print what command to run to get Python 2." I was thinking of the case of the end-user trying to follow a Python tutorial. They'd still need to exit and run the python2 command if they wanted 2. Diane
Re: MBF for deprecating Python2 usage
Barry Warsaw writes: > On Aug 7, 2017, at 14:52, Diane Trout wrote: > > Perhaps when launching via the command "python" the interpreter could > > hint python2 was available? Something like: > > > > $ python > > Python 3.5.4rc1 (default, Jul 25 2017, 08:53:34) > > [GCC 6.4.0 20170704] on linux > > Type "python2" for Python 2.7.13 > > Type "help", "copyright", "credits" or "license" for more information. > > Good idea Diane! I disagree, it's a bad idea to actively take steps to make the same command invoke *incompatible* programs depending on the time and host. (good sigmonster; have a cookie.) -- \ “I've always wanted to be somebody, but I see now that I should | `\ have been more specific.” —Jane Wagner, via Lily Tomlin | _o__) | Ben Finney
Re: a few quick questions on gbp pq workflow
On August 7, 2017 5:37:34 PM EDT, Diane Trout wrote: > >> >> Why would you need to repack a tarball just because it contains >> prebuilt docs (non-DFSG-free licensed documentation aside)? I'm all > >I've occasionally repacked a tarball because upstream included minified >jquery or mathjax. > >Diane Those are sourceless binary blobs, so repacking for that is exactly correct. Scott K
Re: MBF for deprecating Python2 usage
On Fri, 4 Aug 2017, Scott Kitterman wrote: If the primary concern is what happens when a user types "python", then can we address that in command-not-found and leave /usr/bin/python out of it? Debian doesn't ship command-not-found by default. One other approach here would be to have /usr/bin/python exec python3 if it's run interactively -- that is, if isatty(0) -- and print an error message and exit otherwise. I don't think it is too bad to print an error message instead of failing the exec, since that's equivalent to what happens if you're missing a shared library or something: the exec succeeds, but the dynamic loader prints an error and exits nonzero. Ship this /usr/bin/python with python3-minimal, and have the python-minimal package divert it and replace it with the current /usr/bin/python (a symlink to python2.7). This way we can build systems with Python 3 only that behave reasonably, but also allow doing `apt-get install python` to cause /usr/bin/python to start working again. However, I feel like another reason to care about /usr/bin/python is so that sysadmins responsible for multiple platforms can continue writing #!/usr/bin/python (or #!/usr/bin/env python) scripts and use the same script on all their machines. If I can't do this and need platform-specific scripts, I might as well use some other language or ship compiled binaries. Keeping Python viable for this use case is a large part of why I originally proposed pythonmux: I can write scripts that declare that they're polyglot Python 2/3 and work on both Python 2-only and Python 3-only systems, but a Python 2 script using #!/usr/bin/python will give me an error (as it should!) if there's no Python 2 installed on the machine. Last time I checked (2015), entirely reasonable versions of RHEL and macOS both shipped only Python 2 and not Python 3. Is it likely to be the case that all UNIXy OSes within security support in 2019 or 2020 will have a /usr/bin/python3 (preferably 3.3+)? If so, that's a viable option. I just want my best migration path from #!/usr/bin/python to not involve rewriting my scripts in Go. -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Re: MBF for deprecating Python2 usage
On Aug 7, 2017, at 14:52, Diane Trout wrote: > Perhaps when launching via the command "python" the interpreter could > hint python2 was available? Something like: > > $ python > Python 3.5.4rc1 (default, Jul 25 2017, 08:53:34) > [GCC 6.4.0 20170704] on linux > Type "python2" for Python 2.7.13 > Type "help", "copyright", "credits" or "license" for more information. Good idea Diane! -Barry signature.asc Description: Message signed with OpenPGP
Re: a few quick questions on gbp pq workflow
> > Why would you need to repack a tarball just because it contains > prebuilt docs (non-DFSG-free licensed documentation aside)? I'm all I've occasionally repacked a tarball because upstream included minified jquery or mathjax. Diane signature.asc Description: This is a digitally signed message part
Re: MBF for deprecating Python2 usage
> * Plan for a date at which /usr/bin/python will point to Python 3. I > know that’s the most controversial bit, but I do think that as time > goes on and we’re past 2020, it will be the choice that gives our > users the best experience. I agree the default should change. Perhaps when launching via the command "python" the interpreter could hint python2 was available? Something like: $ python Python 3.5.4rc1 (default, Jul 25 2017, 08:53:34) [GCC 6.4.0 20170704] on linux Type "python2" for Python 2.7.13 Type "help", "copyright", "credits" or "license" for more information. >>> Diane signature.asc Description: This is a digitally signed message part
Re: a few quick questions on gbp pq workflow
On Aug 6, 2017, at 11:11, Ondrej Novy wrote: > It's not always possible/simple/nice to use sdist, because it contains > prebuild docs. And I don't like to do +dfsg rebuild just for removing docs. > Sometimes sdists doesn't contain tests. I will also generally prefer the PyPI tarballs for the packages I help maintain. There’s good tooling for that and the tarballs are usually fine. If not, and it’s fairly easy to DFSG them (e.g. via d/copyrights or some such), then I’ll go that route. So far I haven’t had to pull things in from upstream git although once in a while I’ll just grab a file if needed. -Barry signature.asc Description: Message signed with OpenPGP
Re: Request to join DPMT
[Muri Nicanor, 2017-07-25] > i hereby request to join the debian python modules team. I want to > maintain the ansi python module [0] as part of the python modules team. > i've read and accepted both the DPMT policy [1] and the git packaging > guidelines [2]. > My username on alioth is muri-guest. welcome in the team! (and sorry for the delay) :) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: PGP signature
Re: a few quick questions on gbp pq workflow
On Sun, Aug 6, 2017 at 2:53 PM, Jeremy Stanley wrote: > Why would you need to repack a tarball just because it contains > prebuilt docs (non-DFSG-free licensed documentation aside)? I'd suggest removing prebuilt files should happen in both the upstream VCS and tarballs, failing that then at `debian/rules clean` and `debian/rules build` time should be enough for Debian's purposes. -- bye, pabs https://wiki.debian.org/PaulWise
