Re: Sorry, I ment pyrlp
On 08-Feb-2024, Andreas Tille wrote: > Please read the text below with s/apprise/pyrlp/ in mind. > The bug in question is #1056442. Ah, okay. To avoid further confusion, can I ask that you start again with a reply to that bug report? -- \ “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 signature.asc Description: PGP signature
Re: apprise fails its autopkg tests with Python 3.12
Howdy Andreas, On 07-Feb-2024, Andreas Tille wrote: > Hi Ben, > > I noticed that apprise version 0.5.1-4 has a bug since its autopkgtest > fails with Python3.12. I'd happily fix packages in Debian Python Team > but your package is not team maintained. Do you have any reason for > this? The package metadata for ‘apprise’ tells me its maintainer is: Maintainer: Debian Python Team http://deb.debian.org/debian/pool/main/a/apprise/apprise_1.7.2-1.dsc> so I think you might have the information mixed up? You are talking about “version 0.5.1-4”, so maybe you are referring to a different package? -- \ “Speech is human, silence is divine, yet also brutish and dead: | `\ therefore we must learn both arts.” —Thomas Carlyle, 1830 | _o__) | Ben Finney signature.asc Description: PGP signature
Re: Binary package contains no Python dependencies, how to convince ‘dh_python3’ to detect them?
Piotr Ożarowski writes: > gandi-cli name suggests it's not providing public module and thus no > "public" requires.txt. If you want dh_python3 to read dependencies from > a random file - make sure dh_python3 knows which one it should use: > > override_dh_python3: > dh_python3 --requires path/to/file_with_deps.txt That doesn't appear to help. I have instrumented the ‘override_dh_python3’ actions temporarily to emit the content of the generated ‘requires.txt’ for the package, so it can be seen in the build output. The package build run emits this output: = running egg_info […] writing requirements to gandi.cli.egg-info/requires.txt […] make[1]: Entering directory '/<>' cat gandi.cli.egg-info/requires.txt IPy click>=3.1 pyyaml requests setuptools [test] coverage nose tox dh_python3 \ --package gandi-cli \ --requires gandi.cli.egg-info/requires.txt \ debian/gandi-cli/usr/share/gandi-cli/ […] = (When I got the name wrong in earlier runs, ‘dh_python3’ emitted a warning “cannot find requirements file”. So the fact there is no error above, suggests that in the above run it is reading the correct file.) Yet the resulting binary package does not contain any of the corresponding dependencies. They are all in ‘/usr/share/dh-python/dist/cpython3_fallback’: = $ for dist in setuptools pyyaml click requests IPy ; do grep -i "^$dist\>" /usr/share/dh-python/dist/cpython3_fallback ; done setuptools python3-pkg-resources PyYAML python3-yaml click python3-click requests python3-requests IPy python3-ipy = So why is ‘dh_python3’ not adding them to the binary package dependencies? -- \“To me, boxing is like a ballet, except there's no music, no | `\ choreography, and the dancers hit each other.” —Jack Handey | _o__) | Ben Finney
Re: Command to query “Python versions that are installed *with* standard library”
Dmitry Shachnev writes: > I usually use py3versions --supported and make the autopkgtest depend > on python3-all. Thank you, I had forgotten that AutoPkgTest dependencies are declared separately from the build dependencies. That works fine. -- \ “The long-term solution to mountains of waste is not more | `\ landfill sites but fewer shopping centres.” —Clive Hamilton, | _o__)_Affluenza_, 2005 | Ben Finney
Re: Command to query “Python versions that are installed *with* standard library”
Matthias Klose writes: > On 24.01.19 00:16, Ben Finney wrote: > > What command, hopefully as simple as ‘py3versions --installed’, can > > be used in AutoPkgTest to interrogate *only* those Python versions > > on the local machine that have their standard library installed? > > we currently can't do that, until python3.6 gets removed. Can you explain that connection? What is it about Python <= 3.6 that prevents interrogating the installed versions in the way I've described? -- \ “He was the mildest-mannered man / That ever scuttled ship or | `\ cut a throat.” —“Lord” George Gordon Noel Byron, _Don Juan_ | _o__) | Ben Finney
Command to query “Python versions that are installed *with* standard library”
Howdy all, What is a ‘py3versions’ (or alternative) command that can be run in AutoPkgTest, to query the Python versions that are installed on this machine *with* their standard library? The ‘pythonX.Y-minimal’ packages can be installed *without* standard library, but will still appear in the ‘py3versions --installed’ output. This means it's possible to have an AutoPkgTest test that attempts to run a module for all the ‘py3versions --installed’ versions, then fail because an import of a standard library module fails. What command, hopefully as simple as ‘py3versions --installed’, can be used in AutoPkgTest to interrogate *only* those Python versions on the local machine that have their standard library installed? -- \ “Friendship is born at that moment when one person says to | `\another, ‘What! You too? I thought I was the only one!’” —C.S. | _o__)Lewis | Ben Finney
Re: Safest way to set python3 as default for `python`
Bastian Venthur writes: > sorry if this question has been asked before. What is the currently > recommended way to make `python` point to `python3`? I'd like to have > it set on a system default level if possible. At a system default level, in Debian, the command ‘python’ (if it is installed) invokes the default Python 2 interpreter. Based on existing discussions I am confident there will not be a recommendation for a ‘python’ command to invoke anything except the default Python 2 interpreter, until long after Debian ceases support for Python 2 — and there is no current plan to drop Python 2 support in Debian. If you want a ‘python’ command at the system default level with different behaviour from that today, that's going against recommendations so I think you won't find a recommended way to have different behaviour. To have a command with custom behaviour, the recommendation is the general one: put an executable file at ‘/usr/local/bin/python’ with whatever behaviour you want. -- \ “But Marge, what if we chose the wrong religion? Each week we | `\ just make God madder and madder.” —Homer, _The Simpsons_ | _o__) | Ben Finney
Binary package contains no Python dependencies, how to convince ‘dh_python3’ to detect them?
Howdy all,
The Debian package ‘gandi-cli’ is building with none of the Python
library dependencies detected, so the “Depends” field contains none of
the required Python library packages. Why isn't ‘dh_python3’ reading the
dependencies from ‘requires.txt’?
When I install the upstream source, it creates the ‘requires.txt’ file
correctly. That file contains PyPI distribution names that should
already map to the correct Debian packages:
=
IPy
click>=3.1
pyyaml
requests
setuptools
…
=
Why is the ‘dh_python3’ run ignoring those, and expanding
“${python3:Depends}” to the empty set? How can I convince ‘dh_python3’
to correctly read the generated ‘requires.txt’?
--
\ “Pinky, are you pondering what I'm pondering?” “Well, I think |
`\ so, Brain, but ‘apply North Pole’ to what?” —_Pinky and The |
_o__) Brain_ |
Ben Finney
How to convince ‘dh_python3’ to handle ‘/usr/lib/python3.7/dist-packages/foo.egg-info/’ correctly?
Howdy all, The ‘python-coverage’ source package has some special handling of build and install rules. How can I convince the packaging tools to correctly handle ‘/usr/lib/python3.7/dist-packages/foo.egg-info/’? This was brought to my attention by the recent addition of the Lintian tag “python-module-in-wrong-location”: W: python3-coverage: python-module-in-wrong-location usr/lib/python3.7/dist-packages/coverage-4.5.1.egg-info/ usr/lib/python3/dist-packages/coverage-4.5.1.egg-info/ N: N:The package installs a Python module or debug information for a Python N:module in the wrong location for the given version of Python. N: N:dh_python3 can be used to fix this for Python 3 modules. N: N:Refer to Debian Python Policy section 2.5 (Module Path) and N:https://bugs.debian.org/576012 for details. N: N:Severity: normal, Certainty: possible N: N:Check: files, Type: binary, udeb N: W: python3-coverage: python-module-in-wrong-location usr/lib/python3.7/dist-packages/coverage-4.5.1.egg-info/entry_points.txt usr/lib/python3/dist-packages/coverage-4.5.1.egg-info/entry_points.txt Which particular of those files are right or wrong, according to the Debian Python Policy §2.5? * usr/lib/python3.7/dist-packages/coverage-4.5.1.egg-info/ * usr/lib/python3/dist-packages/coverage-4.5.1.egg-info/ * usr/lib/python3.7/dist-packages/coverage-4.5.1.egg-info/entry_points.txt * usr/lib/python3/dist-packages/coverage-4.5.1.egg-info/entry_points.txt How should I change the package's ‘debian/rules’ to conform to Debian Python Policy §2.5? -- \“I went to the hardware store and bought some used paint. It | `\ was in the shape of a house.” —Steven Wright | _o__) | Ben Finney
Re: Stepping down from python-defaults maintenance
Scott Kitterman writes: > I've removed myself from Uploaders in git for both python-defaults and > python3-defaults. Thank you for your work on Python in Debian! And especially for knowing (and announcing) when you need to change that commitment. -- \“A life spent making mistakes is not only most honorable but | `\ more useful than a life spent doing nothing.” —anonymous | _o__) | Ben Finney
Re: Could somebody change the alioth documentation, have a buster roadmap and know what's missing to move to python 3 entirely.
Ondrej Novy writes: > do I understand you correctly that there is no default Python in > Debian? :) :-) Hopefully a little polite repetition will help the point become clearer, though Andrey said it plainly in the initial response. Shirish, now that we've established there is no “default Python” in Debian, you may want to know that there *is* a concept of the default interpreter for *a specific Python major version*. You can ask the Debian system. First choose which Python major version (currently Python 2 or Python 3) you want, then run the command to ask what interpreter command to use: $ pyversions --default # What is the name of the default Python 2 interpreter command? python2.7 $ py3version --default # What is the name of the default Python 3 interpreter command? python3.6 Note that you can *only* ask about the default within a specific Python major version. Each of those commands is installed by a completely separate Python environment, and neither of them care about the other: $ dpkg --search $(which pyversions py3versions) python-minimal: /usr/bin/pyversions python3-minimal: /usr/bin/py3versions The ‘pyversions’ command asks *only* about Python 2. The ‘py3versions’ commandasks *only* about Python 3. The answer you get for “default interpreter” depends which Python major version you choose to interrogate; there's no default choice. -- \ “If you pick up a starving dog and make him prosperous, he will | `\ not bite you. This is the principal difference between a dog | _o__)and a man.” —Mark Twain, _Pudd'n'head Wilson_ | Ben Finney
Re: Could somebody change the alioth documentation, have a buster roadmap and know what's missing to move to python 3 entirely.
shirish शिरीष writes: > On 06/06/2018, shirish शिरीष wrote: > > I have also been trying to understand which packages/modules are > > remaining for python 3 to be the default-python There is no “default Python” in Debian. Python 2 and Python 3 are separate run-time systems, and are provided by different packages. > > $ apt-cache policy python The ‘python’ package is always Python 2. To find the default version of Python 3, you want the ‘python3’ package. > I just read Andrey's mail at > https://lists.debian.org/debian-python/2018/06/msg00024.html . Please > CC me if somebody replies. Please subscribe to the forum in order to participate. > Maybe it would have been better to say that right now python gives > > $ python --version > Python 2.7.15 Yes. The ‘/usr/bin/python’ program is the Python 2 interpreter. There are no plans yet for that to change. The ‘/usr/bin/python2’ program is the Python 2 interpreter, and always will be. The ‘/usr/bin/python3’ program is the Python 3 interpreter, and always will be. There is no command in Debian for “the default Python”, because Python 2 and Python 3 are separate run-time systems that are not fully compatible. By using one of the above commands, you are explicitly declaring which Python run-time system to use. > To be more precise, I meant to know if 'Bullseye' i.e Debian 11 would > have python 3.0 as default or not. Bullseye will have both Python 2 and Python 3 available to install. I know of no plan to remove either of them in Bullseye. There is no “default Python” in Debian. To run a Python interpreter, you choose which major version you want to run; they are not meant to be compatible, and (as you pointed out) they are both in common use. So there is no default. I hope that helps clarify the issue. -- \ “Come on, if your religion is so vulnerable that a little bit | `\ of disrespect is going to bring it down, it's not worth | _o__) believing in, frankly.” —Terry Gilliam, 2005-01-18 | Ben Finney
Re: hangups
Diane Trout writes: > I built the package so most of the python code is in a python3-hangups > module but the executable is in its own package. If they're separate Debian packages, then each can have a different value for Section, as needed. > (one could use the API for other hangouts applications) The Debian package for the library should have “Section: python”. The Debian package for the application should have a section appropriate for its primary use. Perhaps “Section: comms”, though other values might make better sense. -- \ “A poet more than thirty years old is simply an overgrown | `\ child.” —Henry L. Mencken | _o__) | Ben Finney
Re: Remove wiki version of the python policy?
Joseph Herlant writes: > Hi, > > On Mon, May 14, 2018, 10:01 PM Ben Finney wrote: > > > Joseph, do you mean simply replacing the article content with a “now > > the policy is in the packaging manuals” external link? > > Yes, that's what I meant, sorry for the confusion. Okay. Yes, that sounds fine to me. Hopefully just pointing (not redirecting) to the canonical location will be enough to gradually teach search engines the correct answer :-) -- \ “I would rather be exposed to the inconveniences attending too | `\ much liberty than those attending too small a degree of it.” | _o__) —Thomas Jefferson, 1791-12-23 | Ben Finney
Re: Remove wiki version of the python policy?
Scott Kitterman writes: > On Monday, May 14, 2018 10:55:36 AM Joseph Herlant wrote: > > Hi guys, > > > > I noticed that https://wiki.debian.org/Python/Policy is full of > > obsolete ways to do. > > Is it worth updating it or should I just remove everything there and > > redirect to https://www.debian.org/doc/packaging-manuals/python-policy/ > > ? > > I think it can go. I don't see how a “redirect” (which I understand to be automatic, not controlled by the visitor) to a URL outside the wiki would be good. Joseph, do you mean simply replacing the article content with a “now the policy is in the packaging manuals” external link? -- \“The whole area of [treating source code as intellectual | `\property] is almost assuring a customer that you are not going | _o__) to do any innovation in the future.” —Gary Barnett | Ben Finney
Re: Removal of easy_install
Scott Talbert writes: > Installing the egg means that all the wxpython4.0 files are installed > under: > /usr/lib/python2.7/dist-packages/wxPython-4.0.1-py2.7-linux-amd64.egg > > Thus, any program or user who does an 'import wx' will get the > wxpython3.0 module and if instead the wxpython4.0 module is desired, > the user must manually insert the above path into sys.path or > PYTHONPATH. That seems, based on the above description, to just arbitrarily declare one version to be the default, and the other needs manual override by the user. If that's an accurate description of the effect you want, then you don't need to do a special ‘easy_install’ usage, nor an Egg install. You can instead install to a different location using the normal tools. See the ‘pybuild(1)’ manual page on how to specify installation locations when installing the Python library. That would not need anything different from the Debian package tools, and you are then left in the same situation: the user needs to specify a different import search path to choose the different library. -- \ “By instructing students how to learn, unlearn, and relearn, a | `\ powerful new dimension can be added to education.” —Alvin | _o__) Toffler, _Future Shock_, 1970 | Ben Finney
Re: Removal of easy_install
Scott Talbert writes: > The source package in question is wxpython4.0. The reason I use > easy_install is for installing the python2 version of the module as an > egg. Okay, so from that I understand that the Debian package is not invoking ‘easy_install’ to fetch files from the network. >From what I remember, it is surprisingly difficult to convince ‘easy_install’ that it should never access the network, even when you think you're only performing local operations. Probably it's best to test this in a virtual machine isolated from the network, to be sure it succeeds. > The reason I do this is because wxpython3.0 occupies the 'namespace' > for the wx module for python2. In other words, both wxpython3.0 and > wxpython4.0 have a 'wx' module for python2. In order to avoid a > conflict, I install the wxpython4.0 version as an egg. How does that avoid the conflict — that is, what is the effect of installing the egg such that a namespace conflict is avoided? I ask because it is likely that today's Python has a better way of achieving the effect you're wanting, so that ‘easy_install’ is not needed. -- \“If we ruin the Earth, there is no place else to go. This is | `\not a disposable world, and we are not yet able to re-engineer | _o__) other planets.” —Carl Sagan, _Cosmos_, 1980 | Ben Finney
Re: Removal of easy_install
Scott Talbert writes: > About a month ago, Matthias removed easy_install from setuptools. I > have sent him a few mails and bugs asking about it, but I haven't > heard anything back. Anyone know why he did it? I have a package > that currently FTBFS because of it. :( Why does a source package *build* need to use ‘easy_install’? The source package should not need any network access to build, all the source should be in Debian source packages that are fetched before the build begins. Which package is the one that's failing to build now? -- \ “I prayed for twenty years but received no answer until I | `\ prayed with my legs.” —Frederick Douglass, escaped slave | _o__) | Ben Finney
Re: How to package my python module ?
慕冬亮 writes: > thanks for your tips. (To participate in email discussions, please don't top-post. Instead, learn to interleave your replies in response to the text to which you are responding. See this article for more https://en.wikipedia.org/wiki/Posting_style#Interleaved_style>. This message I'm posting is an example of how to do that.) > For now, I have submitted all the debian metadata files to [my Github > repo](https://github.com/mudongliang/youdao-python). The Debian Project has Git hosting for packaging work. You should maintain your packaging files in a VCS repository at https://salsa.debian.org/>. This will make it easier for other Debian Project members to collaborate with you. > […] > Finally I got two files: > youdao-python_1.1.0_all.deb, youdao-python_1.1.0_amd64.changes > > What should I do now? Upload the Debian source package to the Mentors package repository, then report an RFS (Request For Sponsor) bug report for the package. Read https://mentors.debian.net/intro-maintainers> for how to do these. -- \ “… one of the main causes of the fall of the Roman Empire was | `\that, lacking zero, they had no way to indicate successful | _o__) termination of their C programs.” —Robert Firth | Ben Finney
Re: How to package my python module ?
Georg Faerber writes: > On 18-03-16 17:16:23, 慕冬亮 wrote: > > I need to find one sponsor to upload my package to the Debian > > software repository(for now I don't have the privilege); > > It might need some time up until you become a DM to be able to upload > packages on your own, but in general, the above is correct. Before then, as you can read in the introductory document https://mentors.debian.net/intro-maintainers>, you can publish to the Mentors repository for review by mentors. That is the whole purpose of the Mentors package repository :-) -- \“Politics is not the art of the possible. It consists in | `\ choosing between the disastrous and the unpalatable.” —John | _o__)Kenneth Galbraith, 1962-03-02 | Ben Finney
Re: How to package my python module ?
慕冬亮 writes: > I am sure I would like to become to a package maintainer of the Debian > package. It's my honor. And I am a big fan of Debian System. I have > been exploring the Debian World in four to five years. Great! This forum is good for discussions specific to packaging Python in Debian. To learn Debian packaging, you will also want to subscribe to the Mentors forum https://lists.debian.org/debian-mentors/> which is specific for teaching people to become Debian maintainers. -- \“If you go parachuting, and your parachute doesn't open, and | `\you friends are all watching you fall, I think a funny gag | _o__) would be to pretend you were swimming.” —Jack Handey | Ben Finney
Re: How to package my python module ?
慕冬亮 writes: > I am very glad to get your response. But for your link, I encounter > "Internal error 404" :( Sorry about that! I typed the wrong URL, the correct URL is https://mentors.debian.net/intro-maintainers>. Meanwhile, can you confirm you are wanting to become a package maintainer of the Debian package for the Python library? -- \ “If we could change ourselves, the tendencies in the world | `\ would also change.” —Mohandas K. Gandhi, _Collected Works_, 1913 | _o__) | Ben Finney
Re: How to package my python module ?
慕冬亮 writes: > If someone could give some tips to package this python module, I will > appreciate it. > > P.S. I don't know whether this is right mailing list to ask this > question. Welcome. This forum is to discuss the packaging of Python works, to become part of the Debian operating system. If you are intending to maintain a package indefinitely in the Debian operating system, then this is the right forum :-) To learn how to package software as part of Debian, start with https://mentors.debian.net/intro>. -- \ “We now have access to so much information that we can find | `\ support for any prejudice or opinion.” —David Suzuki, 2008-06-27 | _o__) | Ben Finney
Re: Where to put docs of a -doc package for python 2 + 3 modules?
Ghislain Vaillant writes: > Definitely [do not name the documentation package ‘python3-foo-doc’], > indeed. The python- prefixes in python-foo and python-foo-doc are not > exactly equivalent. The former usage refers to the Python 2 > interpreter, the latter refers to Python *the language*. Yes, that's how I understand the distinction. Thank you for expressing that. > It's unfortunate our naming convention did not explicitly separate > between both as Arch packages do, whereby `python` is used for source > package and `python2` for binary packages targeting CPython 2.x. Yes. Another point: The name of the documentation package should not depend on whether there is a Python 2 library package. So, the presence or absence of ‘python-foo’ should not change the name of ‘python-foo-doc’. > Imo, we should just make it clear in policy that source packages > should be named `foo` or `python-foo`, and corresponding doc packages > should be named `foo-doc` or `python-foo-doc`. +1. -- \ "Those who will not reason, are bigots, those who cannot, are | `\fools, and those who dare not, are slaves." —“Lord” George | _o__) Gordon Noel Byron | Ben Finney
Re: /usr/bin/python2 in shebangs?
Piotr Ożarowski writes: > I plan to prepare new dh-python upload soon and hence a question about > a bit controversial change: should dh_python2 (as we discussed during > last DebConf's Python BoF) replace /usr/bin/python shebangs with > /usr/bin/python2? +1, explicit is better than implicit. -- \ “Our task must be to free ourselves from our prison by widening | `\our circle of compassion to embrace all humanity and the whole | _o__) of nature in its beauty.” —Albert Einstein | Ben Finney
Re: pycharm package in debian
Andrey Rahmatullin writes: > On Sun, Oct 01, 2017 at 06:38:03PM +0200, W. Martin Borgert wrote: > > PS: Is there maybe something broken with the quoting function of > > your MUA? I cannot differentiate between text written by you and > > quoted text. There is no '> ' or whatever... > That's how text parts of text+html mails often look like. It is a recent breakage on GMail: the text body is broken (quoted text is indistinguishable from non-quoted text). As I don't use GMail I don't know what the author can do to correct this. Those using GMail should engage with their support team to get this fixed for all users. Until then, use a different client for composing messages. -- \ “As soon as we abandon our own reason, and are content to rely | `\ upon authority, there is no end to our troubles.” —Bertrand | _o__) Russell, _Unpopular Essays_, 1950 | Ben Finney
Re: pycharm package in debian
Ghislain Vaillant writes: > All 3 means of installation (Jetbrain's app, snap and potentially apt) > are one-liners for the end-user. So, ease-of-use is hardly a > compelling argument. That's not the argument I made. I am satying that there are people who are not in the set of people who will install Snap or Flatpak or etc., because it's too much hassle to know whether it is free software or whether it will work correctly with the rest of the system. Getting the work as free software in Debian opens up the package for installation by those people. I count myself among them. I say this to counter the idea that there is a set of “users of this software package” that is not affected by whether the software is in Debian. That is false, and indeed getting the package maintained in Debian is a way to *increase* the potential members of that set. So, I don't find the “would users of this software package care about it being in Debian” query not compelling, because it makes a false assumption about the relationship. -- \“If we ruin the Earth, there is no place else to go. This is | `\not a disposable world, and we are not yet able to re-engineer | _o__) other planets.” —Carl Sagan, _Cosmos_, 1980 | Ben Finney
Re: pycharm package in debian
Ghislain Vaillant writes: > Don't get me wrong, I understand the rationales from a DFSG > perspective. I am just questioning whether users of this particular > piece of software would particularly care. The same could be asked of many user-facing packages in Debian. Your question, though, makes an incorrect assumption: that “users of this particular piece of software” is a group whose membership is unaffected by having the package in Debian. On the contrary. Take me as a counter-example. I am not a user of this particular piece of software, because I have little interest in judging for myself the hundreds of user-facing applications on my system. If it were in Debian I can then take all the assurance that brings about freedom and maintenance, and I may indeed consider using this particular piece of software where otherwise I would not. So, one important reason to package a work in Debian is to *increase* the set of people who can easily install and use it. -- \ “Pinky, are you pondering what I'm pondering?” “Uh, I think so | `\ Brain, but this time, you wear the tutu.” —_Pinky and The Brain_ | _o__) | Ben Finney
Re: Scaling back for now
Barry Warsaw writes: > After the events of April, I've realized that I have a lot less time, > and to be frankly honest, motivation for contributing to Debian right > now. So I'm scaling back, but not retiring. (I don't know what “the events of April” is meant to refer to; if someone can enlighten me – probably in private, or just a pointer to existing discussions I can read – I'd appreciate that.) Thank you, Barry, for recognising when it's time to scale back your involvement, and responsibly handing over authority to continue work. -- \ “Don't worry about what anybody else is going to do. The best | `\ way to predict the future is to invent it.” —Alan Kay | _o__) | Ben Finney
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
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
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
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
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
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: python3 for pysrs
Sandro Knauß writes: > I'm currently porting pysrs to python3 and sofar I got all tests > running for python2 and python3 *yeah*. Congratulations! > But the porting was mostly adding encode()/ decode() to many parts of > the module. And I'm unsure, if the API is now in a good shape, or if > it is mostly unusable for users This is work you're doing in collaboration with the ‘pysrs’ upstream developers, right? You are aiming to get users to test this, and get it into a release, before doing any of this in Debian. Is that correct? I think that porting a work to Python 3 is not appropriate for a Debian patch. That should be done only in a maintained upstream work; maybe a fork, but certainly not just a patch on the released upstream work for Python 2 only. -- \“Madness is rare in individuals, but in groups, parties, | `\nations and ages it is the rule.” —Friedrich Nietzsche | _o__) | Ben Finney
Consistent location for library documentation
Howdy all, Where is the best location for library documentation of a Debian Python library package? Debian Policy §12.3 says: […] installing the documentation into the documentation directory of the main package is preferred since it is independent of the packaging method and will be easier for users to find. This is clear enough where a library package ‘libfoo’ is the main package. The documentation package ‘libfoo-doc’ can install the documentation to ‘/usr/share/doc/libfoo/’. With the split in Python runtime systems, though, there is commonly not a single “main package”. Typically there are two, ‘python3-foo’ and ‘python-foo’. The documentation package ‘python-foo-doc’ then has no one obvious place to install the documentation: * Installing to ‘/usr/share/doc/python-foo-doc/’ is discouraged by the above Policy section. I agree that is not necessarily an obvious place for a user to look for ‘python3-foo’ documentation. * Installing to ‘/usr/share/doc/python-foo/’ or ‘/usr/share/doc/python3-foo/’ is incorrect if the corresponding library package is not installed. Compounding this is the fact we are (rightly, IMO) moving toward Python 3 as the primary runtime, and discouraging new Python 2 packages. Is ‘python3-foo’ then the “main package” by the Policy statement above? A symlink could be used, from ‘/usr/share/doc/libfoo-doc’ to ‘/usr/share/doc/libfoo’. But that still runs into the problem of *which* package should be assumed. And if the documentation package *only* is installed, where should it install its documentation and symlinks? How should this be done to allow the library packages to later be installed without changing the documentation location? I have looked at various documentation and can't see good guidance for a “one obvious way” to resolve this. There is varying practice among packages, and anyway just because some package does it a particular way doesn't mean I should copy that without knowing whether it's a good idea. What to do? -- \ “I put contact lenses in my dog's eyes. They had little | `\ pictures of cats on them. Then I took one out and he ran around | _o__) in circles.” —Steven Wright | Ben Finney
Re: Fwd: next version of csvkit
Brian May writes: > I just noticed that Ubuntu plan to drop Python 2.7 completely - from > default installs at least That's a pretty important modifier! Ubuntu does not yet plan to drop Python 2.7 completely. Rather, the current plan is to ensure no *dependencies on* Python 2.7 in the default installs. It's the reverse dependencies that are being targeted; not Python 2.7 itself. So, similar to what we Debian Python folk are striving to do: no plan to drop Python 2.7, instead working on the reverse dependencies. -- \“Absurdity, n. A statement or belief manifestly inconsistent | `\with one's own opinion.” —Ambrose Bierce, _The Devil's | _o__) Dictionary_, 1906 | Ben Finney
Re: What should Debian do about Python 2? (was Re: next version of csvkit)
Brian May writes: > It is perhaps worth noting that Django 2.0 is due to be released in > December: > > https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ Yes. More directly, Django 1.11 is planned to be the final Python-2-compatible release. From the above URL: As a final heads up, Django 1.11 is likely to be the last version to support Python 2.7 as it will be supported until the end of Python 2 upstream support in 2020. -- \ “It's my belief we developed language because of our deep inner | `\ need to complain.” —Jane Wagner, via Lily Tomlin | _o__) | Ben Finney
Re: how to convert ython module into deb package
Ángel Luis writes: > I am trying to package |numpy 1.12.1| into deb package. The creation of a Debian package is — quite deliberately — not an automated process [0]. There are many human decisions to be made, in order to work well with the rest of Debian, and to conform with Debian Policy. > How can I generate a debian package from python module? The general answer is: This is the work of a maintainer, so learn how to do that https://mentors.debian.net/intro-maintainers>. The specific answer for NumPy is: Use the existing packages https://packages.debian.org/source/sid/python-numpy> and/or collaborate with the existing maintainers. [0] Of course, there are many tools to help with those small steps that are mechanical and *can* be automated. But these do not by any measure automate the “start with upstream work, end with Debian package” process. -- \ 德不孤、必有鄰。 (The virtuous are not abandoned, | `\ they shall surely have neighbours.) | _o__)—孔夫子 Confucius (551 BCE – 479 BCE) | Ben Finney
Re: GnuPG signatures on PyPI: why so few?
Brian May writes: > Maybe there is some way of turning signatures on by default, so I don't > have to remember for every upload, if so, I haven't been able to work it > out yet however. I don't know how it should be done using the currently-recommended Twine tool. For Distutils, the ‘upload’ command has a ‘--sign’ option https://docs.python.org/3.1/distutils/uploading.html> to specify the distribution should be GnuPG signed, and the ‘--identity’ option specifies which GnuPG identity from your keyring should sign the distribution. To set an option default for Setuptools commands, you put it in the ‘setup.cfg’ file. So, in the code base's ‘setup.cfg’: [upload] # Sign distributions, and upload the signing public key? sign = true # Which GnuPG identity to use for signing? identity = christ...@example.org -- \ “Probably the earliest flyswatters were nothing more than some | `\sort of striking surface attached to the end of a long stick.” | _o__) —Jack Handey | Ben Finney
GnuPG signatures on PyPI: why so few?
Howdy all, What prospects are there for PyPI to have GnuPG-signed packages by default? Debian's UScan has the ability to find, download, and verify the GnuPG signature for a package source release. Lintian will remind the maintainer if a Debian source package is not taking advantage of this. However, this only works if upstream releases are actually accompanied by a valid GnuPG signature each time. The PyPI infrastructure supports this; why isn't it more widely encouraged? This thread from 2016 has a possible answer: while you can use GPG as is to verify that yes, "Donald Stufft" signed a particular package, you cannot use it to determine if "Donald Stufft" is *allowed* to sign for that package, a valid signature from me on the requests project should be just as invalid as an invalid signature from anyone on the requests project. The only namespacing provided by GPG itself is "trusted key" vs "not trusted key". […] I am aware of a single tool anywhere that actively supports verifying the signatures that people upload to PyPI, and that is Debian's uscan program. […] All in all, I think that there is not a whole lot of point to having this feature in PyPI, it is predicated a bunch of invalid assumptions (as detailed above) and I do not believe end users are actually even using the keys that are being uploaded. […] Thus, I would like to remove this feature from PyPI […]. https://mail.python.org/pipermail/distutils-sig/2016-May/028933.html> The thread has some discussion, and Barry Warsaw makes the case for Debian's use for signed releases. The last (?) post in the thread has a kind of interim conclusion: My main concern when implementing this is how to communicate it to users […]. [A move that gives the impression] "we're getting rid of this thing that only kinda works now in favor of something amazing that doesn't exist yet" is just not a popular move. https://mail.python.org/pipermail/distutils-sig/2016-May/028946.html> In response to polite requests for signed releases, some upstream maintainers are now pointing to that thread and closing bug reports as “won't fix”. What prospect is there in the Python community to get signed upstream releases become the obvious norm? -- \ “It is the fundamental duty of the citizen to resist and to | `\ restrain the violence of the state.” —Noam Chomsky, 1971 | _o__) | Ben Finney
Re: Backport of python-lockfile and suggested team maintenance
Andreas Tille writes: > In your last mail you agreed that team maintenance would acceptable To clarify: I've not agreed with that. Rather, I've agreed with your position that the practice of a team as maintainer is sensible, and I've said the practice of an individual as maintainer is sensible. A particular package can't be both of those at once, of course. But both are common practice in Debian, and both are sensible. So, a decision of which to choose can't be based only on “option X is sensible”, because that doesn't argue *against* other options. What I've been confused by is the conflation of “team as maintainer is sensible”, which I agree with, and some implicit assumption of “individual as maintainer is *not* sensible”, which I don't agree with. I haven't got an answer from you on whether that's your position, so I don't even know what argument you're presenting. > Thanks for considering I've tried :-) but haven't even seen any reason presented to change the package maintenance from what it is now. I'd consider it if that were presented. As for the Git commits you've made for backports: I remain open to considering a pull request from any published Git repo at your choice of host. -- \ “The great thing about science is we can test our ideas.… But | `\ until we do, until we have data, it is just one more proposal.” | _o__) —Darren Saunders, 2015-12-02 | Ben Finney
Re: Backport of python-lockfile and suggested team maintenance
My bafflement at the particulars of your complaint have not been resolved, Andreas. I can only think you're confused about ‘python-lockfile’; much of your latest message just doesn't match the facts. Andreas Tille writes: > You decided to use github instead of git.debian.org. Is your complaint that the Debian packaging for ‘python-lockfile’ is on GitHub? This is the first time it's been raised in this thread. If so, please look to the VCS-Git and VCS-Browser fields for the package; that assertion isn't true. > IMHO that is not following good practice for Debian team maintenance As you have pointed out, the package is not currently team maintained, so “good practice for Debian team maintenance” doesn't bear on the issues you've expressed for this package. This thread started with your polite request (thank you!) that the package *should* become team maintained, and we don't even seem to have got to addressing that yet :-) > since [hosting at GitHub] makes contributions (admitedly slightly!) > harder. Agreed – I think the barriers are significant – which is one reason the packaging is not hosted at GitHub. > > As a maintainer of the package, I remain open to pull requests. > > The pull request would force me to create my own clone on Github Since the Debian packaging work is not hosted at GitHub, no that would not be necessary. Even if it were hosted at GitHub, that assertion is not true: Git can pull from *any* published repository. I've already pointed out that two published repositories can share full change information *without* being hosted at the same provider. Even one hosted in a Debian developer's personal Alioth space works fine https://wiki.debian.org/Alioth/Git#Personal_Git_repositories>. So, I'm open to pull requests (whether created with ‘git request-pull’ or otherwise) from a published repository that I can point Git to. Nothing about this requires anyone to host a repository at the same provider. > > Are you now expressing the separate position that you consider it > > *not* sensible to name an individual as package maintainer? On what > > basis? I would still like an answer to this, because I must admit I am now baffled as to what your complaint is and on what you base it. Does it help address your complaint that I've hopefully cleared up some incorrect assumptions? I hope so. If you'd like to discuss on OFTC my nick is ‘bignose’. -- \ “If I held you any closer I would be on the other side of you.” | `\ —Groucho Marx | _o__) | Ben Finney
Re: Backport of python-lockfile and suggested team maintenance
Andreas Tille writes: > However, if maintainers decide from deriving what several people > consider good practice of team maintenance and put extra work on me > (like creating an extra public repository) I'm not willing to do this. I'm sorry to say that I am not clear on what that sentence means; I got lost around “decide from deriving”. The distributed nature of Git – choosing how to share commits between repositories – is a core feature, and allows collaboration without requiring access to the same filesystem. As a maintainer of the package, I remain open to pull requests. > There was a longish discussion on Debian Project[1] and my reading of > it was that named person maintenance is not the prefered way. You have said that you “consider it sensible” to maintain a package within DPMT, and I have no objection to that position. The discussion thread you point to has many opinions, some of them in support of nominating a team as package maintainer. I have no objection to that position. Are you now expressing the separate position that you consider it *not* sensible to name an individual as package maintainer? On what basis? In the discussion thread you point to, I don't see anything to support that. -- \ “[H]ow deep can a truth be — indeed, how true can it be — if it | `\ is not built from facts?” —Kathryn Schulz, 2015-10-19 | _o__) | Ben Finney
Re: Backport of python-lockfile and suggested team maintenance
Andreas Tille writes: > I would have loved to commit the changes to some team Git repository > but you are using a repository outside git.debian.org. Fortunately, Git is a distributed VCS; we can share changes between repositories with all information preserved. If you also publish your repository, you can ‘git request-pull’ to the package maintainer address and I can see about getting them in. > I'd consider it sensible if you would consider maintaining the package > inside DPMT and the corresponding repository which enables easier > contributions to the package. I'm glad that there are multiple sensible options: the maintainer can be a named person, the maintainer can be a team. I consider either of those sensible. -- \“None can love freedom heartily, but good men; the rest love | `\ not freedom, but license.” —John Milton | _o__) | Ben Finney
Re: Naming convention for -doc package
Ghislain Vaillant writes: > So given your criteria above, you would choose: > > - python3-pytestqt > - python-pytestqt-doc > > Am I correct? That allows a future ‘python4-pytestqt’ to use the same documentation. So far, the overwhelming pattern is that upstream's documentation does not come in separate versions for different Python platforms. It's the same Py.test QT documentation, regardless of Python version. The corresponding Debian packages of documentation should not be named by any Python version, either. > Is everyone happy with that? I am. -- \ “Smoking cures weight problems. Eventually.” —Steven Wright | `\ | _o__) | Ben Finney
Re: Bug#836710: dput: Handle ‘setuptools’ specially to work around circular dependency
Control: reassign -1 dput
Control: found -1 dput/0.10.3
Control: found -1 dput/0.11.0
Control: tags -1 + help
On 17-Dec-2016, Ben Finney wrote:
> On 15-Dec-2016, Matthias Klose wrote:
> > In the past we needed that [split into ‘python-pkg-resources’ and
> > ‘python-setuptools’ binary packages] to be able to build packages
> > without setuptools but using pkg_resources.
>
> Yes, that's exactly my purpose for depending on
> ‘python-pkg-resources’. What are you saying has changed? As far as I
> can tell there is still the need to have ‘pkg_resources’ available
> separately.
I haven't had an explanation of what is different now, so I'm casting
to the Debian Python community for help.
Please keep bug#836710 in the correspondence so that I can track the
discussion.
Other unresolved questions:
> The ‘dh-python’ suite is currently detecting dependencies from the
> Distutils information; the binary package has only
> “${python:Depends}” which is then populated automatically. Is this
> perhaps a bug in that detection? What should I describe to the
> ‘dh-python’ maintainer?
On 19-Dec-2016, Ben Finney wrote:
> On 15-Dec-2016, Matthias Klose wrote:
> > On 15.12.2016 21:01, Ben Finney wrote:
> > > The ‘setuptools’ library *is* needed to build the package. Are
> > > you saying that it does not belong in the ‘install_requires’
> > > list?
> >
> > my understanding is that the exception is raised when people try
> > to run dput without having python-setuptools installed.
>
> Okay. Is there a better way to represent the build dependency on
> ‘setuptools’, without falsely declaring that it's needed for
> run-time use?
>
> > so yes, for the debian context, you should remove it from the
> > ‘install_requires’ list and make sure that python-pkg-resources
> > ends up in the package's Depends.
>
> How do you suggest that should be achieved, without special handling
> for ‘pkg_resources’ only? I would much prefer that dependencies are
> automatically discovered from the build system's declarations.
I'd appreciate help with understanding what needs to be done, and how
the tools should be configured to do it automatically.
--
\ “Pinky, are you pondering what I'm pondering?” “I think so, |
`\ Brain, but why does a forklift have to be so big if all it does |
_o__) is lift forks?” —_Pinky and The Brain_ |
Ben Finney
signature.asc
Description: PGP signature
Re: Python 4 and ‘python3’
Barry Warsaw writes: > AFAIK, there is *no* official declaration (e.g. from Guido or the > mythical Python 4 release manager) about this either way. In support of your position, Guido van Rossum has informally implied version “3.10” is feasible for a future Python 3 https://twitter.com/gvanrossum/status/583346987925278720>. I had thought GvR expressed a distaste for Semantic Versioning but can't find it now. So, yes, my panic is lessened :-) > I predict that when the time comes, it'll generate a gigathread's > worth of discussion, 3 or 4 competing PEPs, and then Guido will just > pronounce. Hopefully, informed by reasoned argument about consequences, more than aesthetic preferences of a small group (I'm still sore about the process evidenced in the Python VCS decisions, so don't wholly trust this will be better). -- \“With Lisp or Forth, a master programmer has unlimited power | `\ and expressiveness. With Python, even a regular guy can reach | _o__) for the stars.” —Raymond Hettinger | Ben Finney
Re: Python 4 and ‘python3’
Barry Warsaw writes: > On Nov 02, 2016, at 01:57 PM, Ben Finney wrote: > > >Certainly the command ‘python3’ should only ever point to the Python > >3 interpreter. > > > >If upstream ever releases a “Python 4” but expects the interpreter > >for that to also be named ‘python3’, I think we can declare upstream > >to be directly courting user pain, and secede on behalf of our users. > > I wouldn't at all be surprised if /usr/bin/python is reclaimed for > some future post-Python2-demise Python 4 interpreter. It might even be > a good thing since I'm not sure I'd want a /usr/bin/python4. What about a Python 4.0 that is just “the release that comes after 3.9”? http://www.curiousefficiency.org/posts/2014/08/python-4000.html> Such a “Python 4.0” release would inevitably be referred to as Python 4, and inevitably will be considered *not the same* as ‘/usr/bin/python3’. That's what I'm saying is pointless user confusion: do we use ‘/usr/bin/python3’ for the interpreter? Do we use ‘/usr/bin/python4’? Why, if they're deliberately compatible interpreters — indeed, they may be the *same* interpreter? Such a thoroughly, and persistently, confusing state of affairs is entirely avoidable (just use Semantic Versioning, don't name it “4.0” until it's backward-incompatible with all “3.xx”). I had thought that was the sane and prevailing attitude of the Python release managers. But the above post implies that pointless confusion will be directly courted, merely because of some aesthetic objection to a two-digit component in the version string. > Not that I'm expecting Python 4 any time soon […] At the current rate of Python releases, it's not very far in the future before the Python release managers must decide what the version string for “the release that comes after 3.9” will be. Is there anyone seriously courting the idea that “Python 4.0 is part of the Python 3 line”? I would hope not, yet the above post implies it. Can that be quashed decisively? -- \“If you go parachuting, and your parachute doesn't open, and | `\you friends are all watching you fall, I think a funny gag | _o__) would be to pretend you were swimming.” —Jack Handey | Ben Finney
Python 4 and ‘python3’ (was: /usr/bin/python2 shebangs)
Donald Stufft writes: > /usr/bin/python3 being Python 4.x is a bit weird though Seriously? Who is proposing that? > and it’s likely that Python 4.x is not going to be another break the > world release. Certainly the command ‘python3’ should only ever point to the Python 3 interpreter. If upstream ever releases a “Python 4” but expects the interpreter for that to also be named ‘python3’, I think we can declare upstream to be directly courting user pain, and secede on behalf of our users. -- \“[It's] best to confuse only one issue at a time.” —Brian W. | `\ Kernighan, Dennis M. Ritchie, _The C programming language_, 1988 | _o__) | Ben Finney
Re: Derive package dependencies from Setuptools declarations
Piotr Ożarowski writes:
> this one worked perfectly fine for me (tested with dh_python2 1.2014-2)
> so I assumed you pointed us to a wrong example
What do you mean by “worked perfectly”? Remember that the problem I'm
encountering is that the package builds successfully, but with
‘${python:Depends}’ containing none of the dependencies declared in the
Setuptools script.
The Setuptools script definitely sets ‘install_requires’ in the ‘setup’
call:
=
$ dget -x
https://mentors.debian.net/debian/pool/main/m/mullvad-client/mullvad-client_60+dfsg.1-1.dsc
dget: retrieving
https://mentors.debian.net/debian/pool/main/m/mullvad-client/mullvad-client_60+dfsg.1-1.dsc
[…]
dpkg-source: info: extracting mullvad-client in mullvad-client-60+dfsg.1
[…]
$ cd mullvad-client-60+dfsg.1/
$ python2 -c "
import setuptools
def report_install_requires(**kwargs):
print(kwargs['install_requires'])
setuptools.setup = report_install_requires
import setup
"
['appdirs', 'ipaddr', 'netifaces', 'psutil', 'wxPython']
=
So that should be what ‘dh-python’ needs to infer dependencies for the
‘${python:Depends}’, yes?
That's not what happens though:
=
$ cat debian/control
[…]
Package: mullvad-client
Architecture: all
Depends:
python-pkg-resources,
python,
openvpn,
resolvconf,
${python:Depends},
${misc:Depends}
[…]
$ dpkg-buildpackage -A
[…]
dpkg-deb: building package 'mullvad-client' in
'../mullvad-client_60+dfsg.1-1_all.deb'.
[…]
$ dpkg-deb --info ../mullvad-client_60+dfsg.1-1_all.deb
[…]
Depends: python-pkg-resources, python, openvpn, resolvconf
[…]
=
Note that the “Depends” field has replaced ‘${python:Depends}’ with
nothing, where I would expect all the corresponding packages to satisfy
‘install_requires’ from Setuptools.
So that's the problem: Setuptools gets packages named in
‘install_requires’, yet ‘dh_python2’ is not using that for Debian
package dependencies in the ‘${python:Depends}’ substitution.
Do you get different behaviour from building that package?
How am I meant to tell ‘dh_python2’ to replace the ‘${python:Depends}’
with what the upstream Setuptools script declares are its dependencies?
--
\ “Generally speaking, the errors in religion are dangerous; |
`\those in philosophy only ridiculous.” —David Hume, _A Treatise |
_o__) of Human Nature_, 1739 |
Ben Finney
Re: Derive package dependencies from Setuptools declarations
Piotr Ożarowski writes: > [Ben Finney, 2016-10-15] > > How can I convince ‘dh-python’ to derive package dependencies from the > > Setuptools ‘install_requires’ declaration? > > by dh-python you mean dh_python3, right? In this case, ‘dh_python2’. Would you expect that to be different? > > How can I convince ‘dh-python’ to derive Debian package dependencies > > from the Setuptools ‘install_requires’ declaration? For example, > > can you point me to a source package where dh_python3 *doesn't* do that > already? I don't know why, but you snipped the sentence where I give an example: Ben Finney wrote: > How can I convince ‘dh-python’ to derive Debian package dependencies > from the Setuptools ‘install_requires’ declaration? For example, > https://mentors.debian.net/debian/pool/main/m/mullvad-client/mullvad-client_60+dfsg.1-1.dsc> > declares dependencies that ‘dh_python2’ does not detect; the resulting > binary has none of the Python dependent packages declared. -- \ “Dyslexia means never having to say that you're ysror.” | `\—anonymous | _o__) | Ben Finney
Derive package dependencies from Setuptools declarations
Howdy all, How can I convince ‘dh-python’ to derive package dependencies from the Setuptools ‘install_requires’ declaration? The Pip requirements tend to be tightly restrictive, because Pip is not a distribution system but rather a deployment system. So those requirements tend not to be good candidates for Debian's versioned dependencies. The Setuptools ‘install_requires’ declaration is a better candidate for this, since it is metadata for the *distribution* (not deployment); this better matches Debian's purposes for package dependencies. See https://caremad.io/posts/2013/07/setup-vs-requirement/> for a discussion of these complementary and different purposes. How can I convince ‘dh-python’ to derive Debian package dependencies from the Setuptools ‘install_requires’ declaration? For example, https://mentors.debian.net/debian/pool/main/m/mullvad-client/mullvad-client_60+dfsg.1-1.dsc> declares dependencies that ‘dh_python2’ does not detect; the resulting binary has none of the Python dependent packages declared. -- \ “Capitalism has destroyed our belief in any effective power but | `\ that of self interest backed by force.” —George Bernard Shaw | _o__) | Ben Finney
Re: python debug packages
Vincent Bernat writes: > The page seems up-to-date It makes no reference to why ‘foo-dbgsym’ is not enough, so the reader doesn't have any guidance on which practice overrules the other. > and already explains why Python is different (presence of a debug > interpreter) As I said, that doesn't explain it. Please consider that someone reading those instructions may have no more sophisticated idea of debug symbol packages than “I heard that they are done automatically now, so I'll just rely on that”. So this: > and that the -dbg package contains the symbols for the regular > extensions as well as the unstripped extensions for the debug > interpreter. doesn't address the confusion, I think. -- \“If you go parachuting, and your parachute doesn't open, and | `\you friends are all watching you fall, I think a funny gag | _o__) would be to pretend you were swimming.” —Jack Handey | Ben Finney
Re: python debug packages
Iustin Pop writes: > Reading > https://wiki.debian.org/Python/LibraryStyleGuide#Building_python_-dbg_packages, > there is some hints to this The introduction of ‘foo-dbgsym’ automatic generated packages makes me quite sure those instructions are obsolete. But perhaps they are not? > but it's not clear that only automatic debug packages work for Python > packages. Would it make sense to update the wiki page and say "don't > migrate to dbgsym packages as Python needs debug extensions and not > only debug symbols"? Reading that reference again, I am not much wiser. It does not reference ‘foo-dbgsym’ packages so the reader doesn't know which instructions are to be followed. Could someone who understands *why* ‘foo-dbgsym’ is not sufficient, please update the wiki page to be explicit about what is special to Python and under what specific circumstances we still need ‘foo-dbg’ packages. -- \“With Lisp or Forth, a master programmer has unlimited power | `\ and expressiveness. With Python, even a regular guy can reach | _o__) for the stars.” —Raymond Hettinger | Ben Finney
Upstream build system, Sphinx autodoc, Python import path
Howdy all, What advice can we give to upstream for their build system, so that in a Debian build environment the Sphinx ‘autodoc’ can import upstream's code modules? Our wiki page on Library Style Guide advises the Debian packaging override the Python import path: If you need to build the Sphinx documentation (usually from .rst or .md files), add: override_dh_auto_build: dh_auto_build PYTHONPATH=. sphinx-build -N -bhtml docs/ build/html # HTML generator PYTHONPATH=. sphinx-build -N -bman docs/ build/man # Manpage generator https://wiki.debian.org/Python/LibraryStyleGuide#Sphinx_documentation> This is surely not ideal, though. Better would be to not need ‘PYTHONPATH’ override at all, and just call the build program. What information do our build tools look for, and what variables are set, when running upstream's build system? What can we advise to upstream so their build system will work correctly in our build environment *without* that override in every Sphinx-using package? -- \ “For a sentimentalist is simply one who desires to have the | `\luxury of an emotion without paying for it.” —Oscar Wilde, _De | _o__) Profundis_, 1897 | Ben Finney
Re: how to build sphinx doc when there is extension
PICCA Frederic-Emmanuel writes: > > how about doing it outside pybuild? Do you really need to build it for > > each interpreter / version? > > > It is a sort of unit test during the build that auto-doc works for all > versions of the interpreter. You're only installing one version of the documentation, though. Correct? If so, this package is not a good place to do the test you describe. > th eunit test is > try to import all the modules provided by a packages. That isn't a good fit for “build the documentation”. It also does not explain why you try to do it with every interpreter. > Is there something whcih can be automatise at the autodep8 level for > python ? You can start with the tests I have in ‘python-coverage’ https://sources.debian.net/src/python-coverage/4.2%2Bdfsg.1-1/debian/tests/> which allows you to specify the module names to test. -- \ “Education is learning what you didn't even know you didn't | `\ know.” —Daniel J. Boorstin, historian, 1914–2004 | _o__) | Ben Finney
Re: Building a module and an application package from one source
Sebastian Humenda writes: > I want to repackage GladTeX (it used to be Perl and has been rewritten > in Python). Thank you for working on this package for Debian. > GladTeX comes with a module and an command-line application. Pybuild > copies all files into the package defined first in debian/control and > I am not sure how to separate the module from the application. Is the “command-line application” just a single program file, which imports the library and does its stuff? If so, that file should be installed to the right place (‘/usr/bin/foo’ probably) by the build system. You then configure ‘dh_install’ to install that file specifically to the ‘foo’ binary package. Then you use ‘dh_python3’ to package the Python 3 library to its binary package. -- \ “He that loveth father or mother more than me is not worthy of | `\me: and he that loveth son or daughter more than me is not | _o__)worthy of me.” —Jesus, as quoted in Matthew 10:37 | Ben Finney
Re: Help for Python mock test suite needed
Andreas Tille writes: > Yes, this is what I guessed from the log. However, how can I find out > why exactly the command is not called? That seems to be a question to take up with the upstream developer, or just normal Python debugging. Unless I'm misunderstanding, this doesn't appear to be a problem specific to a Debian build environment, so I would guess it fails even when simply running the test suite in a normal development environment. So you can use the full power of your development environment to hunt the problem: an interactive debugging session, etc. Use your Python skills :-) -- \ “Broken promises don't upset me. I just think, why did they | `\ believe me?” —Jack Handey | _o__) | Ben Finney
Re: Help for Python mock test suite needed
Andreas Tille writes: > https://paste.debian.net/789238/ That appears to be a simple failure when the test suite is run. The assertions, as reported, are in the ‘test_srst2’ module: = […] File "test_srst2.py", line 213, in test_run_bowtie_with_defaults run_mock.assert_called_once_with(expected_bowtie2_command) File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 947, in assert_called_once_with raise AssertionError(msg) AssertionError: Expected 'run_command' to be called once. Called 0 times. […] File "test_srst2.py", line 180, in test_run_bowtie_with_overide run_mock.assert_called_once_with(expected_bowtie2_command) File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 947, in assert_called_once_with raise AssertionError(msg) AssertionError: Expected 'run_command' to be called once. Called 0 times. = The tracebacks tell you what test case functions are emitting failures: File "test_srst2.py", line 213, in test_run_bowtie_with_defaults File "test_srst2.py", line 180, in test_run_bowtie_with_overide Within those test case functions you can see the exact command that was expected to be run. The assertion is that ‘srst2.run_command’ is expected to be called (with specific arguments), but is not called, hence the assertion fails. -- \ “Don't be afraid of missing opportunities. Behind every failure | `\ is an opportunity somebody wishes they had missed.” —Jane | _o__) Wagner, via Lily Tomlin | Ben Finney
Re: BTS bot in #debian-python IRC channel
Barry Warsaw writes: > On Aug 13, 2016, at 10:48 PM, Ondrej Novy wrote: > > >I would like to add BTS bot to IRC channel #debian-python with same > >notifications (uploads, bug reports) as in #debian-devel-changes > >filtered to maintainer/uploaders: > > I don't *think* I'd mind getting these notifications in irc, but I > guess I won't know for sure until it happens. Would it be a good idea to first have it running in an analogous channel, ‘#debian-python-changes’? -- \ “You can never entirely stop being what you once were. That's | `\ why it's important to be the right person today, and not put it | _o__) off until tomorrow.” —Larry Wall | Ben Finney
Re: Help for Python mock test suite needed
Andreas Tille writes: > Hi Scott, > > On Sat, Aug 13, 2016 at 12:41:42PM -0400, Scott Kitterman wrote: > > > > > > > > Any more complete hint from a possibly bowtie2 user would be helpful > > > > > > > > Andreas. > > > > > > > > [1] svn://anonscm.debian.org/debian-med/trunk/packages/srst2/trunk/ > > > > A link to a build log showing the test failure might be helpful. > > There is no such link. You could make one: * Build the package using Sbuild (you are doing this already to ensure the build works cleanly, right?) * Take the output from the Sbuild run. * Paste that file on http://paste.debian.net/>. * Reply here with the link to that complete build log. This is an essential tool of collaborating on packaging: Ensure your builds are initiated in their entirety with a single command, and all output is captured for later inspect. This is why it's important to use Sbuild or something equivalent. -- \ “Science embraces facts and debates opinion; religion embraces | `\opinion and debates the facts.” —Tom Heehler, _The Well-Spoken | _o__) Thesaurus_ | Ben Finney
Re: Package name for github.com/miguelgrinberg/python-socketio
Luke Yeager writes: > The policy manual says the package name should be "python-socketio" > since I want to create a python2 package that provides the "socketio" > module. > > But that name is already taken by this project: > https://github.com/abourget/gevent-socketio Yes, this is a problem with the current Debian Python policy: it assumes distribution authors will not collide on package names. I don't have an answer, though I will point out that whatever the solution is, it will be incompatible with the current Debian Python policy for at least one of those packages. We need to discuss the problem and find a general solution that accepts the reality that upstream authors sometimes don't check whether the Python package name is already taken. -- \“I was once walking through the forest alone and a tree fell | `\ right in front of me, and I didn't hear it.” —Steven Wright | _o__) | Ben Finney
Re: Python program as a command-line program
Barry Warsaw writes: > On Jun 23, 2016, at 11:17 AM, Ben Finney wrote: > > >There isn't, AFAIK, anything portable that I can write in the shebang > >to turn a command invocation of ‘./foo/bar.py’ into ‘python3 -m > >foo.bar’. > > Why not just have a file that contains only? > > exec python3 -m foo.bar Because that's not something I can write in the shebang of an existing Python file, and expect it to work as I move around the directory that contains the file. There's no obvious way to tell the kernel (via the shebang line in the Python file) how to execute this file via a Python interpreter, without hitting the failure scenarios documented in PEP 366. This is unlike Perl. Heck, it's unlike Make and Awk and Sed. The case I'm making is that Python breaks the “put the interpreter command in the shebang, and it'll work” criterion for Python to be called a Unix scripting language. -- \ “I am amazed, O Wall, that you have not collapsed and fallen, | `\since you must bear the tedious stupidities of so many | _o__) scrawlers.” —anonymous graffiti, Pompeii, 79 CE | Ben Finney
Re: Best practice for adding python3 version to existing module with helper programs?
Neil Muller writes: > I'm working on packaging the latest version of sqlobject, which adds > supprt for python 3, and I'm unsure of how best to handle the helper > applications that ship as part of the package. The helper applications > will work with both python2 and python3, so it's not clear to me how > to apply the advice given in [1], and I'd ideally want the helper > programs available regardless of which version of the module is > installed. What is the purpose of the helper applications? Is there a significant use case for “I want specifically the Python 2 version of this application”? If not, I would advise making only the Python 3 applications available, in a separate binary package (and put it it “Section: database”) which describes the purpose without mentioning Python versions. -- \ “Roll dice!” “Why?” “Shut up! I don't need your fucking | `\ *input*, I need you to roll dice!” —Luke Crane, demonstrating | _o__) his refined approach to play testing, 2009 | Ben Finney
Python program as a command-line program (was: Python package providing both modules and an app)
Barry Warsaw writes: > On Jun 22, 2016, at 11:25 AM, Ben Finney wrote: > > >There is a compounding tendency to disparage ‘python3 ./foo/bar.py’, > >[…]. I wish this trend could be effectively reversed, because IMO > >this is a serious impediment to considering Python a good choice for > >command-line scripting. > > Sorry, I don't quite understand the above. Do you mean that you would > rather use `python3 ./foo/bar.py` more often and `python3 -m foo.bar` > less often? When ‘./foo/bar.py’ has a shebang of ‘#! /usr/bin/python3’, and I invoke that path as a command, the Unix shebang semantics turn that into ‘/usr/bin/python3 ./foo/bar.py’. Python will run the file as the main module. But invoking it that way runs into the nastiness and constraints described in PEP 366 (primarily, relative imports break). There isn't, AFAIK, anything portable that I can write in the shebang to turn a command invocation of ‘./foo/bar.py’ into ‘python3 -m foo.bar’. So yes, I expect Unix shebang semantics to work, and the fact that design decisions in Python's import mechanism defeat that mode is an impediment to using Python for writing command-line programs. -- \ “Dvorak users of the world flgkd!” —Kirsten Chevalier, | `\rec.humor.oracle.d | _o__) | Ben Finney
Re: Python package providing both modules and an app
Hugo Lefeuvre writes: > The entry point is generated by 'setup.py install_scripts', which is > executed by pybuild after files specified in *.install have been > installed (correct me if I'm wrong). I haven't demonstrated for this case, but I would be surprised if that's how it behaves. To my mind the ‘setup.py install’ command (and hence the ‘… install_scripts’ command) should be part of the ‘dh build’ sequence. Again, someone should correct me if I'm wrong. -- \ “Holy polar ice sheet, Batman!” —Robin | `\ | _o__) | Ben Finney
Re: Python package providing both modules and an app
Hugo Lefeuvre writes: > I'm currently packaging python-slugify[0], a Python application for > slugifying unicode strings. Thank you for considering the issues and asking for advice. > Like here[1] upstream decided to write everything as a python module > with an entry script placed in /usr/bin that calls main(). So we can > consider python-slugify as both an application and a library. This seems to be more common now that command-line invocation is becoming even more discouraged. When the upstream documentation recommends ‘python3 -m foo.bar’ as the primary means of invoking the command line functionality, that really blurs the line between command-line application versus library. There is a compounding tendency to disparage ‘python3 ./foo/bar.py’, which is subject to weird hacks and incomplete workarounds like https://www.python.org/dev/peps/pep-0366/>. I wish this trend could be effectively reversed, because IMO this is a serious impediment to considering Python a good choice for command-line scripting. But this is all a digression, my apologies. > The package is originally requested as a Python module[2] and it seems > clear to me that the whole thing is only useful as a library I don't understand this statement. If it is *only* useful as a library, why install the command-line entry point? > Everything is working well. However, I'm not really satisfied by the way I > solved the problem in debian/rules[4]. Does anybody know a better way > of doing that ? Why not install the command by using the configuration files for ‘dh_install(1)’; that is, specify in ‘debian/slugify.install’ the files to install. -- \ “If you can do no good, at least do no harm.” —_Slapstick_, | `\ Kurt Vonnegut | _o__) | Ben Finney
Re: pep8 renamed to pycodestyle
Barry Warsaw writes: > You might be aware that the upstream pep8 package has been renamed to > pycodestyle. Both the command line and imports have changed, although > not in a backward compatible way unfortunately[1]. Ah, Python. We love you, but please grow a proper API versioning system :-/ > There's a new upstream flake8 which I'm preparing in git-dpm, but it > will be blocked until we decide what to do about the Debian pep8 > package. (I hope the upstream ‘flake8’ now defaults to conforming with PEP 8, instead of having default checks that contradict it.) > I think we eventually want to rename Source:pep8 to > Source:pycodestyle, as well as Package:pep8, Package:python-pep8, and > Package:python3-pep8. I suppose we could at least keep the source > package name unchanged and transition to the new binary package names. My understanding is that renaming a source package is rather more disruptive than renaming a binary package, is that right? If so, I would recommend: * Go ahead and transition the binary package names with the usual mechanisms https://wiki.debian.org/PackageTransition>: * Keep the old names as a transition package until after Debian Stretch is released. * Have the new binary packages declare Replaces and Conflicts relationships with the appropriate version specification of the old names. * Maybe even schedule the transition with the release team https://wiki.debian.org/Teams/ReleaseTeam/Transitions>, to allow co-ordination of dependent packages. * Since you've determined the command-line interfaces are not compatible, the new commands should not be alternatives for the old. * As a separate matter, figure out how best to rename the source package to better correspond with the new name upstream. This could take an arbitrarily long time; IMO while it is desirable to rename the source package, there's no tearing need yet. -- \ “Come on, if your religion is so vulnerable that a little bit | `\ of disrespect is going to bring it down, it's not worth | _o__) believing in, frankly.” —Terry Gilliam, 2005-01-18 | Ben Finney
Build fails: Architecture: all, no ‘python3-dev’, but ‘setup.py’ expects it
Howdy all,
I am experiencing a build failure on a Python 3 package [0].
The package has “Architecture: all”, and should not need any
architecture-specific build tools. The package builds no Python
extensions.
I assume (and Lintian agrees) that such a package should not have
“Build-Depends: python3-dev”.
Yet when I try to build the package using a clean up-to-date Sid chroot,
it fails:
=
dh binary --with bash-completion,python3 --buildsystem=pybuild
dh_testroot -O--buildsystem=pybuild
dh_prep -O--buildsystem=pybuild
dh_auto_install -O--buildsystem=pybuild
I: pybuild base:184: /usr/bin/python3 setup.py install --root
/build/xkcdpass-1.6.3/debian/xkcdpass
running install
error: invalid Python installation: unable to open
/usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/Makefile (No such file or
directory)
E: pybuild pybuild:274: install: plugin distutils failed with: exit code=1:
/usr/bin/python3 setup.py install --root /build/xkcdpass-1.6.3/debian/xkcdpass
dh_auto_install: pybuild --install -i python{version} -p 3.5 --dest-dir
/build/xkcdpass-1.6.3/debian/xkcdpass returned exit code 13
debian/rules:35: recipe for target 'binary' failed
make: *** [binary] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
=
Why is that architecture-specific build tool being specified for an
“Architecture: all” build system?
When I amend the package and specify “Build-Depends: python3-dev”, the
build succeeds but Lintian (correctly) reports
“build-depends-on-python-dev-with-no-arch-any”.
What is broken here? How can I find out?
[0] ‘xkcdpass’, I am packaging upstream version “1.6.3”.
--
\ “Faith is the determination to remain ignorant in the face of |
`\ all evidence that you are ignorant.” —Shaun Mason |
_o__) |
Ben Finney
Re: pypy pakages
Stefano Rivera writes: > I think we're all kind of waiting for PyPy 3, so that we don't have to > bring up an entire stack of packages (that few people are going to > use). That's one thing I'm waiting for. Another thing is that many upstream packages don't bother declaring support for PyPy (heck, too many packages don't bother declaring what Python they support at all). I'm reluctant to assert that upstream's code supports PyPy if upstream doesn't assert that. > Otherwise, I'm not convinced that a large pypy stack in Debian is > really useful right now. Practically, I expect most pypy users to be > virtualenv-heavy. That is something Debian can play an important role in counteracting, I believe. (Provided we can actually support the packages, of course.) -- \ “The great thing about science is we can test our ideas.… But | `\ until we do, until we have data, it is just one more proposal.” | _o__) —Darren Saunders, 2015-12-02 | Ben Finney
Source distribution is for building from source (was: Test suite in github but missing from pypi tarballs)
Fred Drake writes: > My reaction is really about the comment that source packages are in > PyPI "for pip". You definitely understand that it's broader than that, > but careful language is important to avoid confusing someone new, > leading to poor understanding across the community. > > Some of us still see pip as a youngling upstart. :-) And regardless of Pip's age, source distributions are definitely of interest beyond that narrow use case. Not everything in the VCS repository belongs in the Python source distribution, and publishing the source distribution at PyPI signals “this is the source for the purposes of building the distribution”. The larger point is: Getting the source, building from source, and installing the result — are all distinct steps that each need to be considered. The source distribution may also be a viable input for Pip, but that is not its only widespread use. It remains the correct input for “build from source”. > Which is why I don't consider slavish use of "git archive" (or similar > from some other VCS) to be valuable. +1. The VCS is for potential developers of the code bse. The source distribution is for people who want to build from source. Those are always distinct use cases. -- \ “Come on Milhouse, there’s no such thing as a soul! It’s just | `\ something they made up to scare kids, like the Boogie Man or | _o__) Michael Jackson.” —Bart, _The Simpsons_ | Ben Finney
Re: Properly splitting Python "-doc" packages
Tiago Ilieve writes: > Ok. As this seems to be considered very wrong, I've separated the > package[1], between "bootstrap-vz" and "python-bootstrap-vz". The > first one contains binaries/man pages/etc. and the later contains the > library with everything packaged by Pybuild. Is there really a need for this separation? If the Python modules are installed to an application-private directory, then by definition they will not be publicly importable. So the Python libraries don't make much sense as a separately installable package. Why not simply have the application package also contain the private Python libraries it needs? For an example of how I've done this, see my ongoing refactor of ‘dput’ https://notabug.org/bignose/dput/src/packaging-upgrade/debian>. The pacakging uses Pybuild to manage the Python libraries and installs them to an application-private location. There is no separate Python library package, because ‘dput’ is the only binary package that would use them and it just installs them itself. -- \“A right is not what someone gives you; it's what no one can | `\ take from you.” —Ramsey Clark | _o__) | Ben Finney
Re: Compiled bytecode installed, because test suite was run
Piotr Ożarowski writes:
> [Ben Finney, 2016-04-13]
> > One complication may have been that the directory name to which the
> > library was installed (with the “--install-lib” option) does not
> > contain the Debian package name.
>
> […] By changing --install-lib you modified destination directory
> anyway (and you should point dh_python3 to the same dir - it doesn't
> know about pybuild's existence)
I'm not invoking ‘dh_python3’ directly, I am telling ‘dh’ to do it:
dh $@ --with python3 --buildsystem=pybuild
To my mind that should cause Pybuild to tell ‘dh-python3’ everything it
needs to know, because I've configured Pybuild:
package_share_dir = /usr/share/${PACKAGE_NAME}
export PYBUILD_INSTALL_ARGS ?= \
--install-lib=${package_share_dir}/ \
--install-scripts=${package_share_dir}/
So with Pybuild configured correctly, that should mean I don't need to
also fiddle manually with ‘dh_python3’. Yes?
--
\ “Capitalism has destroyed our belief in any effective power but |
`\ that of self interest backed by force.” —George Bernard Shaw |
_o__) |
Ben Finney
Re: Compiled bytecode installed, because test suite was run
Piotr Ożarowski writes:
> [Ben Finney, 2016-04-12]
> > * Pybuild runs the upstream test suite
> > * which imports the Python packages
> > * which creates the compiled bytecode files
> > * which remain in the package directories
> > * which are scooped up by Pybuild for installation
>
> * which should be removed by dh_python3
How does ‘dh_python3’ know to do that? Are there settings I should look
at to tell ‘dh_python3’ what to do when it misses some files?
> > * which leads to Lintian correctly complaining
> > “package-installs-python-pycache-dir”.
> >
> > How do I convince Pybuild to run the tests as part of the package build
> > (as normal), but clean up the compiled files *after* the tests and
> > *before* gathering the installed files?
>
> does your package name start with python3- or do you have
> ${python3:Depends} in Depends?
The problem is no longer occurring, because I have tweaked some of the
directories and package names around.
One complication may have been that the directory name to which the
library was installed (with the “--install-lib” option) does not contain
the Debian package name.
When I change that, it works; I don't know why.
The documentation for ‘PYBUILD_NAME’ and ‘PYBUILD_DESTDIR’ don't help me
to understand what is happening when things go wrong. The latter,
especially, makes no sense to me and the man page doesn't help me know
what effect setting that variable will have.
--
\ “Geeks like to think that they can ignore politics. You can |
`\leave politics alone, but politics won't leave you alone.” |
_o__) —Richard M. Stallman, 2002-07-26 |
Ben Finney
Re: Compiled bytecode installed, because test suite was run
Piotr Ożarowski writes:
> does your package name start with python3- or do you have
> ${python3:Depends} in Depends?
Both, yes. The “Depends” field contains “${python3:Depends}”.
Is there anything I can do to diagnose this more precisely? Some part of
the ‘sbuild’ output?
--
\ “[I]t is impossible for anyone to begin to learn that which he |
`\thinks he already knows.” —Epictetus, _Discourses_ |
_o__) |
Ben Finney
Compiled bytecode installed, because test suite was run
Howdy all, I am packaging a code base, which has a test suite. The compiled byte code from the test suite run, is being collected when Pybuild discovers the resulting Python packages. As far as I can determine, these steps are occurring: * Pybuild runs the upstream test suite * which imports the Python packages * which creates the compiled bytecode files * which remain in the package directories * which are scooped up by Pybuild for installation * which leads to Lintian correctly complaining “package-installs-python-pycache-dir”. How do I convince Pybuild to run the tests as part of the package build (as normal), but clean up the compiled files *after* the tests and *before* gathering the installed files? -- \ “The great thing about science is we can test our ideas.… But | `\ until we do, until we have data, it is just one more proposal.” | _o__) —Darren Saunders, 2015-12-02 | Ben Finney
Re: Upstream has split a package in two -> new Debian package?
Christoph Mathys writes: > I'm the package maintainer of mercurial-keyring, a keyring extension > for mercurial. Thank you for maintaining this in Debian. > Upstream has split some of the functionality of mercurial-keyring into > a separate python library and pip package (mercurial_extension_utils). That seems to imply there will be separate releases and versions for ‘mercurial_extension_utils’. Is that correct? > Do I need to create and upload a new package for this library? Or is > there another way? If the source is managed and released separately, with distinct release schedule and versions, yes there should be separate Debian packages for that. -- \ “If nature has made any one thing less susceptible than all | `\others of exclusive property, it is the action of the thinking | _o__) power called an idea” —Thomas Jefferson, 1813-08-13 | Ben Finney
Re: egg-info executable files
Brian May writes: > Anybody here seen this before? > > W: python3-apscheduler: executable-not-elf-or-script > usr/lib/python3/dist-packages/APScheduler-3.0.5.egg-info/PKG-INFO > W: python3-apscheduler: executable-not-elf-or-script > usr/lib/python3/dist-packages/APScheduler-3.0.5.egg-info/requires.txt > W: python3-apscheduler: executable-not-elf-or-script > usr/lib/python3/dist-packages/APScheduler-3.0.5.egg-info/top_level.txt > W: python3-apscheduler: executable-not-elf-or-script ... use > --no-tag-display-limit to see all (or pipe to a file/program) > W: python-apscheduler: executable-not-elf-or-script > usr/lib/python2.7/dist-packages/APScheduler-3.0.5.egg-info/requires.txt > W: python-apscheduler: executable-not-elf-or-script > usr/lib/python2.7/dist-packages/APScheduler-3.0.5.egg-info/entry_points.txt > W: python-apscheduler: executable-not-elf-or-script > usr/lib/python2.7/dist-packages/APScheduler-3.0.5.egg-info/dependency_links.txt > W: python-apscheduler: executable-not-elf-or-script ... use > --no-tag-display-limit to see all (or pipe to a file/program) > > setuptools seems to want to make these files executable for some > reason, Possibly they have the executable permission in the upstream source tarball? This is a common symptom of files from MS Windows systems. Solution: convince upstream to build the tarball better, and/or re-pack it to fix the permissions. -- \ “He that would make his own liberty secure must guard even his | `\ enemy from oppression.” —Thomas Paine | _o__) | Ben Finney
Re: running tests against installed version of package
Brian May writes: > Ben Finney writes: > > > As another check, you can test the resulting URL with a ‘git clone’ to a > > temporary target directory. > > It doesn't seem to like me today: Alioth is not responding at all, for me at the moment. And not just for me: http://downforeveryoneorjustme.com/alioth.debian.org> You'll need to do the test when Alioth can actually pass the test :-) -- \ “If you were going to shoot a mime, would you use a silencer?” | `\—Steven Wright | _o__) | Ben Finney
Re: running tests against installed version of package
Brian May writes: > Ben Finney writes: > > > The “git:” URL method is not encrypted. You should specify the encrypted > > “https:” method in the “VCS-Git” field > > So just to double check, this should solve that right? > > sed 's=git://anonscm.debian.org/=https://anonscm.debian.org/git/=' > */debian/control That looks right to me, for the case you presented. I make no promises for what will result on other texts :-) > ...I notice a number of packages I maintain have this problem and I > really want to make sure I get this right first time! As another check, you can test the resulting URL with a ‘git clone’ to a temporary target directory. -- \ “A child of five could understand this. Fetch me a child of | `\ five.” —Groucho Marx | _o__) | Ben Finney
Re: running tests against installed version of package
Brian May writes: > Vcs-Git: git://anonscm.debian.org/python-modules/packages/apscheduler.git > Vcs-Browser: > https://anonscm.debian.org/cgit/python-modules/packages/apscheduler.git The “git:” URL method is not encrypted. You should specify the encrypted “https:” method in the “VCS-Git” field: Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/apscheduler.git -- \ “That's all very good in practice, but how does it work in | `\ *theory*?” —anonymous | _o__) | Ben Finney
Re: Autopkgtest smoke test for Python libraries
Yaroslav Halchenko writes: > sorry if I came late to the discussion and missing the point, but > pybuild/dh-python already has some tests discovery mechanisms Have another read of the thread: this is not about running the upstream test suite. It is about making a standard “smoke test”, i.e. a simple “is this package actually installed?” test. Now that the code exists and seems to be meeting with approval, I'd like it to be part of an appropriate Debhelper step or some other equivalent “add this to the package while building it” hook. -- \ “Immorality: The morality of those who are having a better | `\ time.” —Henry L. Mencken | _o__) | Ben Finney
Re: Autopkgtest smoke test for Python libraries
Martin Pitt writes: > Thanks to Matthias for pointing this out to me. I try to reply > in-thread. Please keep CC:ing me as I'm not subscribed. Done. > > The goal is to perform a simple “smoke test” to verify the correct > > installation of the Python libraries from the Debian packages, for all > > relevant Python interpreters. > > > > A secondary goal is to have the actual smoke test code be re-usable, > > possibly incorporated into a standard Debian Python packager toolkit. > > Very nice! There's precedent for Perl, Ruby and DKMS packages which > have a fairly standard way to run the upstream test suite. For Python > there are some conventions, like "./setup.py test" or running > nosetests, maybe it's worth experimenting with those after getting the > initial "import works" smoketest in place. I'll limit this work to just a smoke test, whatever that comes to mean through consensus here. As discussed elsewhere in this thread, I think running upstream's test suite is beyond the scope of this simple smoke test. The autopkgtest framework will allow adding more tests if someone else wants to add them. > The "generate" script [from ‘autodep8’] could iterate over all binary > packages of the source and pick out the python-* or the python3-* > ones, respectively. Thanks, I will look into that. > > These scripts are very simple, but not simple enough that I was > > comfortable stuffing them directly into the ‘debian/tests/control’ > > file. Is that a shortcoming of the Autopkgtest specification? > > Not sure what you mean with "shortcoming", you can put arbitrary shell > code into Test-Command:. It becomes very messy when there are more than a line or so; and the test becomes anonymous in the build output. That led me to add the extra indirection layer of some simple named programs; but I'd prefer if that indirection layer could be removed while keeping the test names and clean look of the code. > That seems like an excellent starting point indeed. Thanks for the positive feedback. This belongs IMO in an existing “build Debian packages for Python” tool. As it stands, I'll need to manually add a bundle of files to every Python package I maintain. Who can recommend a way to make this a more automated part of the Debian Python package build workflow? -- \ “I have always wished for my computer to be as easy to use as | `\ my telephone; my wish has come true because I can no longer | _o__) figure out how to use my telephone.” —Bjarne Stroustrup | Ben Finney
Autopkgtest smoke test for Python libraries
Howdy all,
I am experimenting with Autopkgtest[0] for Python library packages.
Perhaps others can use what I've made and/or make suggestions for
improvement.
The ‘python-lockfile’ Debian packaging VCS now has a smoke test suite
https://alioth.debian.org/scm/loggerhead/collab-maint/pkg-python-lockfile/trunk/files/head:/debian/tests/>.
The goal is to perform a simple “smoke test” to verify the correct
installation of the Python libraries from the Debian packages, for all
relevant Python interpreters.
A secondary goal is to have the actual smoke test code be re-usable,
possibly incorporated into a standard Debian Python packager toolkit.
* debian/tests/control
Specifies two tests to run, ‘smoke-python2’ and ‘smoke-python3’.
The dependencies explicitly specify the Python 2 and Python 3 library
modules respectively. Can this be automated better?
* debian/tests/smoke-python2, debian/tests/smoke-python3
These are Bash programs that just run a Python module under every
available Python interpreter.
Running ‘py{,3}versions -i’ gets all the installed Python
interpreters. Can this fail, e.g. can the set of interpreters be
different from what interpreters the package was built for?
These scripts are very simple, but not simple enough that I was
comfortable stuffing them directly into the ‘debian/tests/control’
file. Is that a shortcoming of the Autopkgtest specification?
* debian/tests/smoke_test.py
A module that runs a simple suite of smoke tests: emit the interpreter
description, fetch the Python distribution of the installed library
and emit that, import the modules and emit those.
Implemented as a command-line program so that the distribution name,
and the set of module names, are specified by the caller. This
hopefully makes ‘smoke_test.py’ reuseable for many Python library
packages.
Does this module meet your idea of a simple “smoke test” for Python
library packages? Should it do more?
Is there interest in getting this work into one of the Debian packaging
tookits for Python packages? How should that be done?
[0] Doesn't seem to have a coherent website or documentation index. Try
http://packaging.ubuntu.com/html/auto-pkg-test.html>.
--
\ “The Vatican is not a state.… a state must have territory. This |
`\ is a palace with gardens, about as big as an average golf |
_o__) course.” —Geoffrey Robertson, 2010-09-18 |
Ben Finney
Re: Python Policy: Things to consider for Stretch
Scott Kitterman writes: > On Tuesday, February 02, 2016 06:44:57 AM Ben Finney wrote: > > Ben Finney writes: > > > * Address all the language around Python 2 versus Python 3 versus > > > Python general, and re-order or re-word to focus *primarily* on > > > Python 3, with Python 2 treated as the still-supported legacy > > > system. > > I've merged these changes. I have a little bit of adjustment I want to > do on top of it, but this helps a lot. Thanks, You're welcome, and thank you for working to get this in. -- \“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: Python Policy: Things to consider for Stretch
Ben Finney writes: > * Address all the language around Python 2 versus Python 3 versus > Python general, and re-order or re-word to focus *primarily* on Python > 3, with Python 2 treated as the still-supported legacy system. > > I'm maintaining a Bazaar branch for this, feel free to get it:: > > $ mkdir python.benfinney/ && cd python.benfinney/ > $ bzr branch --bind > http://vcs.whitetree.org/bzr/public/debian/python/python-defaults-debian/devel/ Ben Finney writes: > Thank you, Scott! I'll proceed with the semantic changes that promote > Python 3 to the primary position. Those changes are now in the above branch. The summary of changes from the commit messages: $ bzr log --log-format line --revision ancestor:.. 430: Ben Finney 2016-02-02 Re-phrase version distinctions to make Python 3 primary. 429: Ben Finney 2016-02-01 When only Python 2 is specified, just use literal “2” major version. 428: Ben Finney 2016-02-01 Use Python 3 examples where appropriate. 427: Ben Finney 2016-01-31 Refine some grammar and punctuation. 426: Ben Finney 2016-01-31 Distinguish “Python” the unversioned system versus “Python 2”. 425: Ben Finney 2016-01-30 [merge] Merge from ‘python-defaults-debian’ mainline. Also attached to this message as a Bazaar patch bundle. # Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: ben+deb...@benfinney.id.au-20160201192807-\ # 7ux9dchggw9s8znh # target_branch: bzr+ssh://bzr.debian.org/bzr/pkg-python/python-\ # defaults-debian/ # testament_sha1: 6a28ebdd010851ced1dfe1087d61b9a1dbded494 # timestamp: 2016-02-02 06:36:06 +1100 # base_revision_id: sc...@kitterman.com-20160129221800-\ # kkxuexf3v28q9ro0 # # Begin patch === modified file 'debian/python-policy.sgml' --- debian/python-policy.sgml revid:sc...@kitterman.com-20160129221800-kkxuexf3v28q9ro0 +++ debian/python-policy.sgml revid:ben+deb...@benfinney.id.au-20160201192807-7ux9dchggw9s8znh @@ -84,10 +84,12 @@ On the move to Python 3 - Debian currently supports two Python stacks, one for Python 2 - and one for Python 3. The long term goal for Debian is to + Debian currently supports two Python stacks, one for Python 3 + and one for Python 2. The long term goal for Debian is to reduce this to one stack, dropping the Python 2 stack at some time. + + https://www.python.org/dev/peps/pep-0404/"; name="PEP 404"> states that no more major Python 2 releases are planned, although the latest released minor version 2.7 @@ -112,10 +114,10 @@ - Python libraries should be always packaged for Python 3 - if supported. Python 2 libraries should be packaged, if - applications found in the reverse dependencies are not - yet supported by Python 3. + Python libraries, if they support Python 3, should be always + packaged for Python 3. If an application supports only Python + 2, the Python libraries for that application should also be + packaged for Python 2. @@ -133,12 +135,12 @@ Versions - At any given time, the binary package python - will represent the current default Debian Python version. The - binary package python3 will represent the - current Debian Python 3 version. As far as is reasonable, Python - and Python 3 should be treated as separate runtime systems with - minimal interdependencies. + At any given time, the binary package python3 + will represent the current default Debian Python 3 version; the + binary package python will represent the + current default Debian Python 2 version. As far as is reasonable, + Python 3 and Python 2 should be treated as separate runtime + systems with minimal interdependencies. In some cases, Python policy explicitly references Python helper @@ -150,15 +152,17 @@ It is a design goal to fully specify required interfaces and functions in policy for Python 3 and to avoid enshrining specific implementation details in policy. Except as noted, policy for - Python 3 is the same as Python with the addition of the version - number as needed to distinguish them. - - - The default Debian Python version should always be the latest - stable upstream version that can be fully integrated in Debian. + Python 2 is the same as Python 3 with the exception of the + different major version number as needed to distinguish them. + + + The default Debian Python version, for each of Python 3 and Python + 2, should always be the latest stable upstream version that can be + fully integrated in Debian. + + There may be newer supported or unsupported versions included in - the Debian if they are not fully integrated for a particular - release. + Debian if they are not fully integrated for a particular release. Apart from the default version, legacy versions of Python or beta @
Re: Python Policy: Things to consider for Stretch
Scott Kitterman writes: > On Tuesday, January 26, 2016 04:46:19 PM Ben Finney wrote: > ... > > Once these non-semantic changes are accepted I will begin work on > > the second stage of semantic changes. > ... > > OK. Those are all accepted. Thank you, Scott! I'll proceed with the semantic changes that promote Python 3 to the primary position. > Barry Warsaw had done some changes in the -whl section so I made an > attempt at merging what the two of you had done. That attempt clobbered my earlier changes in that area. I'll restore them and preserve Barry's intention. I should have some more changes to present in a day or two. -- \ “The best mind-altering drug is truth.” —Jane Wagner, via Lily | `\Tomlin | _o__) | Ben Finney
Re: Python Policy: Things to consider for Stretch
Scott Kitterman writes: > I should be able to get it reviewed and merged no later than Saturday > (probably Friday). Much appreciated, thanks for the response. -- \“When I was a baby I kept a diary. Recently I was re-reading | `\ it, it said ‘Day 1: Still tired from the move. Day 2: Everybody | _o__) talks to me like I'm an idiot.’” —Steven Wright | Ben Finney
Re: Python Policy: Things to consider for Stretch
Dmitry Shachnev writes: > On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote: > > I'm planning to provide changes in two bundles: > > > > * Go through the whole document and tidy it up for consistency, > > source style, markup, and language style. This should not change > > the meaning of anything, but will change the wording of numerous > > passages. > > > > My proposal for that is attached here as a Bazaar change bundle. > > Thanks for your work here, your changes look nice to me! Thank you. Are you in a position to do me the favour of merging the bundle into the repository ‘pkg-python/python-defaults-debian/’ at Alioth? -- \ “Money is always to be found when men are to be sent to the | `\ frontiers to be destroyed: when the object is to preserve them, | _o__) it is no longer so.” —Voltaire, _Dictionnaire Philosophique_ | Ben Finney
Re: Python Policy: Things to consider for Stretch
Ben Finney writes: > I'm planning to provide changes in two bundles: > > * Go through the whole document and tidy it up for consistency, source > style, markup, and language style. This should not change the meaning > of anything, but will change the wording of numerous passages. > > My proposal for that is attached here as a Bazaar change bundle. > > * Address all the language around Python 2 versus Python 3 versus Python > general, and re-order or re-word to focus *primarily* on Python 3, > with Python 2 treated as the still-supported legacy system. > > Once these non-semantic changes are accepted I will begin work on the > second stage of semantic changes. That last sentence isn't very clear. What I intended to imply is: The first stage is done and all its changes are in the branch, the second stage I haven't yet started. The set of revision in the “r411–r424” patch bundle is all intended to be non-semantic changes, and once they're accepted I'll begin on the second, semantic-changing, stage of work. -- \“I don't accept the currently fashionable assertion that any | `\ view is automatically as worthy of respect as any equal and | _o__) opposite view.” —Douglas Adams | Ben Finney
Re: Python Policy: Things to consider for Stretch
Ben Finney writes: > Scott Kitterman writes: > > > At this point I think internal consistency is probably more > > important, so if someone wants to go through and make all the > > python's that should be python2, etc then please send in a patch. > > I'll take that on. I'm planning to provide changes in two bundles: * Go through the whole document and tidy it up for consistency, source style, markup, and language style. This should not change the meaning of anything, but will change the wording of numerous passages. My proposal for that is attached here as a Bazaar change bundle. * Address all the language around Python 2 versus Python 3 versus Python general, and re-order or re-word to focus *primarily* on Python 3, with Python 2 treated as the still-supported legacy system. Once these non-semantic changes are accepted I will begin work on the second stage of semantic changes. I'm maintaining a Bazaar branch for this, feel free to get it:: $ mkdir python.benfinney/ && cd python.benfinney/ $ bzr branch --bind http://vcs.whitetree.org/bzr/public/debian/python/python-defaults-debian/devel/ Currently the log of changes since the ‘pkg-python’ repository (as included in the attached change bundle) looks like:: $ cd devel/ $ bzr log --log-format line --revision ancestor:.. 424: Ben Finney 2016-01-26 Clarify what text is literal names. 423: Ben Finney 2016-01-26 Update copyright notice. 422: Ben Finney 2016-01-26 Refine markup for a compact list. 421: Ben Finney 2016-01-26 Clarify what names are filesystem paths. 420: Ben Finney 2016-01-26 Clarify what names are Debian packages. 419: Ben Finney 2016-01-26 Specify GPLv2 documents explicitly. 418: Ben Finney 2016-01-26 Update external URLs to be current, and use HTTPS. 417: Ben Finney 2016-01-25 Use consistent terminology for “distribution”, “version”, “release”. 416: Ben Finney 2016-01-25 Avoid literal ‘<’ and ‘>’, use SGML character entities. 415: Ben Finney 2016-01-25 Distinguish “Python” the system versus “python” the command. 414: Ben Finney 2016-01-25 Add myself to the document's authors. 413: Ben Finney 2016-01-25 Correct whitespace to conform to Policy style. 412: Ben Finney 2016-01-25 Add editor hints to match Debian Policy text style. 411: Scott Kitterman 2016-01-24 Python policy updates (draft) for Stretch DO NOT UPLOAD YET:wq # Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: ben+deb...@benfinney.id.au-20160126051103-\ # 3zbuoy0u0vp14w5d # target_branch: bzr+ssh://bzr.debian.org/bzr/pkg-python/python-\ # defaults-debian/ # testament_sha1: 765dacf10bafece44db129db818e74a4d0814c0e # timestamp: 2016-01-26 16:43:48 +1100 # source_branch: http://vcs.whitetree.org/bzr/public/debian/python\ # /python-defaults-debian/devel/ # base_revision_id: sc...@kitterman.com-20160124060119-\ # e07prikr3oa8bkbn # # Begin patch === modified file 'debian/python-policy.sgml' --- debian/python-policy.sgml revid:sc...@kitterman.com-20160124060119-e07prikr3oa8bkbn +++ debian/python-policy.sgml revid:ben+deb...@benfinney.id.au-20160126051103-3zbuoy0u0vp14w5d @@ -17,24 +17,28 @@ fli...@debian.org -Josselin Mouette + Josselin Mouette j...@debian.org -Joe Wreschnig + Joe Wreschnig pi...@debian.org -Loïc Minier + Loïc Minier l...@debian.org -Scott Kitterman + Scott Kitterman sc...@kitterman.com -Barry Warsaw - ba...@debian.org + Barry Warsaw + ba...@debian.org + + + Ben Finney + ben+deb...@benfinney.id.au version 0.10.1.0 @@ -46,7 +50,7 @@ - Copyright © 1999—2014 Software in the Public Interest + Copyright © 1999–2016 Software in the Public Interest This manual is free software; you can redistribute it and/or @@ -61,11 +65,11 @@ the GNU General Public License for more details. - A copy of the GNU General Public License is available as - /usr/share/common-licences/GPL in the Debian GNU/Linux - distribution or on the World Wide Web at - http://www.gnu.org/copyleft/gpl.html"; - name="The GNU General Public License">. + A copy of the GNU General Public License version 2 is available as + /usr/share/common-licences/GPL-2 in the Debian + GNU/Linux system, or on the World Wide Web at + https://www.gnu.org/licenses/old-licenses/gpl-2.0.html"; + name="GNU General Public License, version 2">. You can also obtain it by writing to the @@ -83,12 +87,12 @@ Debian currently supports two Python stacks, one for Python 2 and one for Python 3. The long term goal for Debian is to reduce this to one stack, dropping the Python 2 stack at some - time. - http://legacy.python.org/dev/peps/pep-0404/"; + time. + htt
Re: Python Policy: Things to consider for Stretch
Scott Kitterman writes:
> On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote:
> > Found it; the source document is ‘python-policy.sgml’ in the source
> > VCS for ‘python3’. Currently that's a Bazaar repository at
> > .
>
> That's correct.
Hmm, apparently I've got the wrong thing. I've got changes from you,
most recently 2016-01-11; followed by later changes as recent as
2016-01-18:
=
$ bzr info
Repository checkout (format: 2a)
Location:
repository checkout root:
/home/bignose/Projects/debian/python3/python3-defaults-debian/trunk
checkout of branch:
bzr+ssh://bzr.debian.org/bzr/pkg-python/python3-defaults-debian/
[…]
$ bzr log --log-format=line --limit 3
340: Matthias Klose 2016-01-18 - drop python3.4 from the defaults
339: Matthias Klose 2016-01-17 * Drop Python 3.4 as a supported python3 version.
338: Scott Kitterman 2016-01-11 {3.5.1-1} Upload to unstable
=
But the ‘debian/python-policy.sgml’ document has a version:
=
$ grep '' debian/python-policy.sgml
version 0.4.1.0
=
which doesn't match what you showed (containing “version 0.10.1.0”) at
http://kitterman.com/debian/python-policy.new-from-old.diff.html>.
What am I missing? Is there a different repository or branch I need to
use?
--
\ “Capitalism has destroyed our belief in any effective power but |
`\ that of self interest backed by force.” —George Bernard Shaw |
_o__) |
Ben Finney
Re: Python Policy: Things to consider for Stretch
Ben Finney writes: > Where is the Git (I assume?) repository you're using for VCS of this > policy document? Found it; the source document is ‘python-policy.sgml’ in the source VCS for ‘python3’. Currently that's a Bazaar repository at . -- \ “The entertainment industry calls DRM "security" software, | `\ because it makes them secure from their customers.” —Cory | _o__) Doctorow, 2014-02-05 | Ben Finney
Re: Python Policy: Things to consider for Stretch
Scott Kitterman writes: > I've taken a run through the current Python Policy to see where I > think it needs to be updated for Stretch. The updates largely fall > into four categories: […] This is great to see, thank you Scott. Where is the Git (I assume?) repository you're using for VCS of this policy document? > This is just my opinion on stuff I found. I'm interested in feedback > on how these changes look and what else ought to be considered I like what I see (modulo other discussions in this thread). One small nit: the examples of what is included versus excluded of the “scope” of a Python version reference. It used to say: as it seems reasonable to provide them. (Note: For the scope of this document, Python versions are synonymous to feature releases, i.e. Python 2.7 and 2.7.1 are sub-minor versions of the same Python version 2.7, but Python 2.6 and 2.7 are indeed different versions.) The contrast “2.7 and 2.7.1 are […] the same Python version 2.7”, with “2.6 and 2.7 are […] different versions”, uses version “2.7” in both parts. I think it's important to the example that an *identical* version is in *both* arms of that contrast, to be clear what is being distinguished. So in the re-write I'd advise again using an identical version in both parts: as it seems reasonable to provide them. (Note: For the scope of this document, Python versions are synonymous to feature releases, i.e. Python 3.5 and 3.5.1 are sub-minor versions of the same Python version 3.5, but Python 3.4 and 3.5 are indeed different versions.) If I can know where to access the VCS repository I can make a patch for that, if you like. -- \ “Come on, if your religion is so vulnerable that a little bit | `\ of disrespect is going to bring it down, it's not worth | _o__) believing in, frankly.” —Terry Gilliam, 2005-01-18 | Ben Finney
Re: Python Policy: Things to consider for Stretch
Scott Kitterman writes: > I don't particularly agree, but if that's correct, then there's a > large amount of change needed throughout the policy. These certainly > aren't the only places this comes up. Yes, that's likely because when the Debian Python policy was initially drafted, there was no Python 3 anywhere close to entering Debian. So “Python” and “Python 2” were less ambiguously conflated at that time. Now that Python 2 and Python 3 are both commonly (and correctly) referred to as “Python”, we need to take more care using the terms for what we mean. > Ambiguous or not, I think the policy is mostly consistent in using > python and python3 vice python2 and python3. Well that's another dimension of confusion :-) The term “python2” and “python3” are named of commands, more than the names of languages. I think you're right that this needs a general clean-up through the policy document, to consistently use: * “python2” to refer to that command only; * “python3” to refer to that command only; * “python” to refer to that command (and I'd suggest deprecating it where feasible); * “Python 2” referring exclusively to that language version 2.x and no other versions of that language; * “Python 3” referring exclusively to that language version 3.x and no other versions of that language; * “Python” referring to the language implemented either as Python 2 or Python 3. > At this point I think internal consistency is probably more important, > so if someone wants to go through and make all the python's that > should be python2, etc then please send in a patch. I'll take that on. Send it to anywhere in particular? Or I can just send it to this forum. -- \ “Pinky, are you pondering what I'm pondering?” “Well, I think | `\ so, but *where* do you stick the feather and call it macaroni?” | _o__) —_Pinky and The Brain_ | Ben Finney
Re: Updating python-jsmin
Christopher Baines writes: > On 23/12/15 10:48, gustavo panizzo (gfa) wrote: > > Pkg is already on git, in collab-maint > > Ah, sorry, I missed that. I just used apt-get source to get the source > package. For future reference: The ‘debcheckout(1)’ command will automatically query the package's “VCS-*” fields and get the source from the specified VCS repository. That currently fails for ‘python-jsmin’. Gustavo, please read the Developer's Reference §6.2.5 and add the appropriate “VCS-*” fields to the source package. -- \ “We suffer primarily not from our vices or our weaknesses, but | `\from our illusions.” —Daniel J. Boorstin, historian, 1914–2004 | _o__) | Ben Finney
