Re: Binary package contains no Python dependencies, how to convince ‘dh_python3’ to detect them?

2019-01-25 Thread Ben Finney
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”

2019-01-24 Thread Ben Finney
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”

2019-01-24 Thread Ben Finney
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”

2019-01-23 Thread Ben Finney
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`

2018-07-17 Thread Ben Finney
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?

2018-07-15 Thread Ben Finney
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?

2018-07-15 Thread Ben Finney
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

2018-06-09 Thread Ben Finney
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.

2018-06-07 Thread Ben Finney
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.

2018-06-07 Thread Ben Finney
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

2018-05-23 Thread Ben Finney
Diane Trout <di...@ghic.org> 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?

2018-05-14 Thread Ben Finney
Scott Kitterman <deb...@kitterman.com> 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

2018-05-07 Thread Ben Finney
Scott Talbert <s...@techie.net> 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

2018-05-07 Thread Ben Finney
Scott Talbert <s...@techie.net> 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

2018-05-06 Thread Ben Finney
Scott Talbert <s...@techie.net> 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 ?

2018-03-17 Thread Ben Finney
慕冬亮 <mudonglianga...@gmail.com> 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
<URL: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
<URL: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
<URL: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 ?

2018-03-15 Thread Ben Finney
慕冬亮 <mudonglianga...@gmail.com> 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 <URL: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 ?

2018-03-15 Thread Ben Finney
慕冬亮 <mudonglianga...@gmail.com> 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
<URL: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 <bign...@debian.org>



Re: How to package my python module ?

2018-03-15 Thread Ben Finney
慕冬亮 <mudonglianga...@gmail.com> 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
<URL: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?

2018-03-13 Thread Ben Finney
Ghislain Vaillant <ghisv...@gmail.com> 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?

2017-12-14 Thread Ben Finney
Piotr Ożarowski <pi...@debian.org> 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

2017-10-01 Thread Ben Finney
Andrey Rahmatullin <w...@debian.org> 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

2017-10-01 Thread Ben Finney
Ghislain Vaillant <ghisv...@gmail.com> 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

2017-10-01 Thread Ben Finney
Ghislain Vaillant <ghisv...@gmail.com> 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

2017-08-28 Thread Ben Finney
Barry Warsaw <ba...@debian.org> 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

2017-08-08 Thread Ben Finney
Steve Langasek <vor...@debian.org> 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

2017-08-07 Thread Ben Finney
Diane Trout <di...@ghic.org> 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

2017-08-07 Thread Ben Finney
Diane Trout <di...@ghic.org> 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

2017-08-07 Thread Ben Finney
Diane Trout <di...@ghic.org> 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

2017-08-07 Thread Ben Finney
Geoffrey Thomas <geo...@ldpreload.com> 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

2017-08-07 Thread Ben Finney
Barry Warsaw <ba...@debian.org> writes:

> On Aug 7, 2017, at 18:28, Ben Finney <bign...@debian.org> 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

2017-08-07 Thread Ben Finney
Diane Trout <di...@ghic.org> 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

2017-08-07 Thread Ben Finney
Barry Warsaw <ba...@debian.org> writes:

> On Aug 7, 2017, at 14:52, Diane Trout <di...@ghic.org> 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

2017-07-16 Thread Ben Finney
Sandro Knauß <he...@debian.org> 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

2017-07-15 Thread Ben Finney
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

2017-04-03 Thread Ben Finney
Brian May <br...@linuxpenguins.xyz> 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)

2017-04-03 Thread Ben Finney
Brian May <b...@debian.org> 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

2017-03-23 Thread Ben Finney
Ángel Luis <angelluis.pera...@um.es> 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 <URL:https://mentors.debian.net/intro-maintainers>.

The specific answer for NumPy is: Use the existing packages
<URL: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?

2017-03-11 Thread Ben Finney
Brian May <b...@debian.org> 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
<URL: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?

2017-03-11 Thread Ben Finney
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 […].

<URL: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.

<URL: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

2017-03-10 Thread Ben Finney
Andreas Tille <ti...@debian.org> 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

2017-03-09 Thread Ben Finney
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 <ti...@debian.org> 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
<URL: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

2017-03-07 Thread Ben Finney
Andreas Tille <ti...@debian.org> 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

2017-03-03 Thread Ben Finney
Andreas Tille <andr...@an3as.eu> 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

2017-02-10 Thread Ben Finney
Ghislain Vaillant <ghisv...@gmail.com> 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 <bign...@debian.org>



Re: Bug#836710: dput: Handle ‘setuptools’ specially to work around circular dependency

2016-12-28 Thread Ben Finney
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 <bign...@debian.org>


signature.asc
Description: PGP signature


Re: Python 4 and ‘python3’

2016-11-02 Thread Ben Finney
Barry Warsaw <ba...@debian.org> 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
<URL: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’

2016-11-02 Thread Ben Finney
Barry Warsaw <ba...@debian.org> 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”?

<URL: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)

2016-11-01 Thread Ben Finney
Donald Stufft <don...@stufft.io> 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

2016-10-17 Thread Ben Finney
Piotr Ożarowski <pi...@debian.org> 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

2016-10-17 Thread Ben Finney
Piotr Ożarowski <pi...@debian.org> 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,
> <URL: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

2016-10-14 Thread Ben Finney
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 <URL: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,
<URL: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



Upstream build system, Sphinx autodoc, Python import path

2016-09-27 Thread Ben Finney
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

<URL: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

2016-08-30 Thread Ben Finney
PICCA Frederic-Emmanuel <frederic-emmanuel.pi...@synchrotron-soleil.fr>
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’
<URL: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

2016-08-24 Thread Ben Finney
Sebastian Humenda <shume...@gmx.de> 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

2016-08-15 Thread Ben Finney
Andreas Tille <andr...@an3as.eu> 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

2016-08-14 Thread Ben Finney
Andreas Tille <andr...@an3as.eu> 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

2016-08-14 Thread Ben Finney
Barry Warsaw <ba...@debian.org> 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

2016-08-13 Thread Ben Finney
Andreas Tille <andr...@an3as.eu> 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 <URL: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

2016-08-02 Thread Ben Finney
Luke Yeager <luke.yea...@gmail.com> 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

2016-06-27 Thread Ben Finney
Barry Warsaw <ba...@debian.org> 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?

2016-06-23 Thread Ben Finney
Neil Muller <drnlmuller+pyt...@gmail.com> 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)

2016-06-22 Thread Ben Finney
Barry Warsaw <ba...@debian.org> 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

2016-06-22 Thread Ben Finney
Hugo Lefeuvre <h...@debian.org> 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

2016-06-21 Thread Ben Finney
Hugo Lefeuvre <h...@debian.org> 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
<URL: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

2016-06-20 Thread Ben Finney
Barry Warsaw <ba...@debian.org> 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 <URL: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
<URL: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

2016-06-10 Thread Ben Finney
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

2016-05-12 Thread Ben Finney
Stefano Rivera <stefa...@debian.org> 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)

2016-04-21 Thread Ben Finney
Fred Drake <f...@fdrake.net> 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

2016-04-14 Thread Ben Finney
Tiago Ilieve <tiago.my...@gmail.com> 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’
<URL: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

2016-04-13 Thread Ben Finney
Piotr Ożarowski <pi...@debian.org> 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

2016-04-12 Thread Ben Finney
Piotr Ożarowski <pi...@debian.org> 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

2016-04-12 Thread Ben Finney
Piotr Ożarowski <pi...@debian.org> 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

2016-04-11 Thread Ben Finney
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?

2016-04-04 Thread Ben Finney
Christoph Mathys <erase...@gmail.com> 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

2016-03-27 Thread Ben Finney
Brian May <b...@debian.org> 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

2016-03-25 Thread Ben Finney
Brian May <b...@debian.org> writes:

> Ben Finney <ben+deb...@benfinney.id.au> 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:

<URL: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

2016-03-25 Thread Ben Finney
Brian May <b...@debian.org> writes:

> Ben Finney <ben+deb...@benfinney.id.au> 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

2016-03-25 Thread Ben Finney
Brian May <br...@linuxpenguins.xyz> 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

2016-03-01 Thread Ben Finney
Yaroslav Halchenko <deb...@onerussian.com> 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

2016-03-01 Thread Ben Finney
Martin Pitt <mp...@debian.org> 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

2016-02-24 Thread Ben Finney
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
<URL: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
<URL: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

2016-02-15 Thread Ben Finney
Scott Kitterman <deb...@kitterman.com> writes:

> On Tuesday, February 02, 2016 06:44:57 AM Ben Finney wrote:
> > Ben Finney <ben+deb...@benfinney.id.au> 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

2016-02-01 Thread Ben Finney
Ben Finney <ben+deb...@benfinney.id.au> 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 <ben+deb...@benfinney.id.au> 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 def

Re: Python Policy: Things to consider for Stretch

2016-01-29 Thread Ben Finney
Scott Kitterman <deb...@kitterman.com> 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

2016-01-27 Thread Ben Finney
Scott Kitterman <deb...@kitterman.com> 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

2016-01-26 Thread Ben Finney
Dmitry Shachnev <mity...@debian.org> 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

2016-01-25 Thread Ben Finney
Ben Finney <ben+deb...@benfinney.id.au> writes:

> Scott Kitterman <deb...@kitterman.com> 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
   
   
-Loc Minier
+	Loc 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  19992014 Software in the Public Interest
+	  Copyright  19992016 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.
+	  

Re: Python Policy: Things to consider for Stretch

2016-01-25 Thread Ben Finney
Ben Finney <ben+deb...@benfinney.id.au> 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

2016-01-24 Thread Ben Finney
Scott Kitterman <deb...@kitterman.com> 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
> > <URL:bzr+ssh://bzr.debian.org/bzr/pkg-python/python3-defaults-debian/>.
>
> 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
<URL: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

2016-01-23 Thread Ben Finney
Scott Kitterman <deb...@kitterman.com> 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: Python Policy: Things to consider for Stretch

2016-01-23 Thread Ben Finney
Scott Kitterman <deb...@kitterman.com> 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

2016-01-23 Thread Ben Finney
Ben Finney <ben+deb...@benfinney.id.au> 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
<URL:bzr+ssh://bzr.debian.org/bzr/pkg-python/python3-defaults-debian/>.

-- 
 \  “The entertainment industry calls DRM "security" software, |
  `\ because it makes them secure from their customers.” —Cory |
_o__)     Doctorow, 2014-02-05 |
Ben Finney



Re: Updating python-jsmin

2015-12-23 Thread Ben Finney
Christopher Baines <ch...@cbaines.net> 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 <b...@benfinney.id.au>



Re: OT: To CC or not to CC?

2015-12-04 Thread Ben Finney
Christoph Groth <christ...@grothesque.org> writes:

> Piotr Ożarowski wrote:
>
> > your message went through, I simply decide to ignore you for a while
> > because you CCed me on a mailing list that I subscribe :P
>
> But how can I know that you, or someone else, is subscribed?

When a message is sent to a forum (e.g. a mailing list), there's no need
to know whether the person who sent it is subscribed. That's their
business, and if they want to receive replies they should either
subscribe to the forum or arrange some other way to receive replies from
that forum.

> I believe that instead of asking oneself this question each time when
> replying to some message on some mailing list, CCing the author by
> default is the only reasonable policy.

I disagree, it is more reasonable to think that someone sending a
message to a forum can arrange by themselves to receive message from
that forum — and if they do not say otherwise, they do not want public
replies duplicated to them privately.

> People who are annoyed by receiving the same message twice can quite
> easily configure any good MUA to hide messages that also go to lists
> that they read anyway.

Some of us have not informed our MUA about the forum at all because we
don't subscribe to the forum via email. If we haven't asked explicitly
for public replies to be duplicated to our individual email address, it
would be rude to unilaterally send messages there without good reason.

-- 
 \  “Science embraces facts and debates opinion; religion embraces |
  `\opinion and debates the facts.” —Tom Heehler, _The Well-Spoken |
_o__)       Thesaurus_ |
Ben Finney



Which bug report is tracking the “python3 is Python 3.5” transition? (was: Packaging Python that requires 3.5)

2015-11-28 Thread Ben Finney
Brian May <b...@debian.org> writes:

> However I don't know much about this Python 3.5 transition, or what
> the current waiting point is.

API/ABI transitions (such as switching default Python 3 to be PYthon
3.5) are managed by the release team, with a workflow described at
<URL:https://wiki.debian.org/Teams/ReleaseTeam/Transitions>.

A transition is initiated by a bug report against ‘release.debian.org’,
tagged with the user-tag “transition”. You can check current transitions
<URL:https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=release.debian@packages.debian.org;tag=transition>.

The transition of default ‘python3’ to Python 3.5 does not appear in
that set, so I'm not sure how it's being tracked.

The prior transition – to add support for Python 3.5 – is at
<URL:https://bugs.debian.org/798999> and refers to future transitions.
I think maybe the “default python3 is Python 3.5” transition has somehow
become entangled with that prior one.

> Is there anything that can be done to help?

Have a read through the log for bug#798999 and see whether they're
waiting on something we can help with.

-- 
 \ “Are you pondering what I'm pondering?” “I think so, ... Brain, |
  `\but how can we get seven dwarves to shave their legs?” —_Pinky |
_o__)           and The Brain_ |
Ben Finney



Re: Application libraries private, Distutils metadata available for console scripts and introspection

2015-11-26 Thread Ben Finney
Piotr Ożarowski <pi...@debian.org> writes:

> As I already suggested in my previous mail, installing scripts into
> private directory and symlinking them in /usr/bin is the cleanest
> solution IMHO

Thank you. I have come to a compromise solution on this which builds on
that suggestion.


Ben Finney <ben+deb...@benfinney.id.au> writes:

> * The ‘console_scripts’ entry point is used to specify command line
>   programs, ‘lorem’ and ‘ipsum’, using that Distutils feature. Those are
>   the correct names for the commands, so I don't want to mess with that.

Main point of compromise: Change the installed names of the commands.

Second point of compromise: Make an application namespace package.


Distutils (and Python generally) makes it highly awkward to have an
importable module *also* be an executable program.

Python's import mechanism makes it infeasible to have a module file
named without a suffix; this makes it infeasible to name a command file
by Unix conventions of having no suffix for the implementation language.

There are many approaches to address this, which I won't detail here,
but suffice it to say that none of them work smoothly.

So the compromise is:

* Patch upstream's ‘setup.py’ to rename the command file to something
  like ‘execute-lorem’, so that it can be installed alongside the
  ‘lorem’ package directory.

* Create a symlink in the application-private directory, making an
  application namespace from which to import the private modules.

* Create a public symlink, ‘/usr/bin/lorem’, to the private
  ‘execute-lorem’ command file.

> * The ‘--install-lib’ option is used in ‘PYBUILD_INSTALL_ARGS’ to place
>   the Python packages in an application-private directory,
>   ‘/usr/share/foo-app/’. The point of that is so they won't be on the
>   Python module search path.

This remains the same; the ‘--install-lib’ option is used to place the
application-private packages in a private directory. That's the whole
point of this endeavour, and everything else is a workaround for
Python's awkwardness to deal with this.

The programs will still need to be importable, but we want to protect
against a conflict with some other publicly-installed Python library.

So we create a namespace ‘FooApp’ specifically for the application, with
a symlink internal to the application's own library directory.

> * The ‘--install-scripts’ option is *not* used, because Distutils places
>   the constructed scripts in the correct directory (‘/usr/bin/’) by
>   default.

We must now install the program command files to the same location, in
order that the application-private packages can be imported by those
programs.

So the ‘--install-scripts’ option is used, naming the same
application-private directory as for the ‘--install-lib’ option.

> * The script names are correct, but are identical to names of
>   directories in the ‘/usr/share/foo-app/’ top level. That's
>   another good reason not to use the ‘--install-scripts’ option. It is
>   also normal and expected, and shouldn't be a problem because the
>   scripts will not exist there; they belong in ‘/usr/bin/’.

Because the command files cannot keep their upstream name and live in
the same location as package directories with the same names, we need to
patch upstream's ‘setup.py’.

Patch upstream's ‘setup.py’ so the ‘console_scripts’ names differ from
the package directory names. For clarity of association and purpose, I
chose to name them ‘execute-lorem’ and ‘execute-ipsum’.

Patch the target of the ‘console_scripts’ entry points, so that those
entry points are preceded by the ‘FooApp’ namespace package.

>   According to Robert's earlier message, that means the Distutils
>   metadata file needs to be not in the application's private
>   directory, but in a directory on the Python module search path. That
>   seems odd to me, since this is not amodule import being done.

Thanks to everyone for explaining this to me; it's a messy hack, and I
do wish the Python Packaging Authority patience and strength in solving
this better than the mess we have now.

> Here is the output from the example. I can provide the files if anyone
> wants to experiment.

Here is an updated session to show how this works:

=
$ pwd
/home/bignose/Projects/debian/foo-app-1.2.3

$ find .
.
./setup.py
./lorem
./lorem/amet.py
./lorem/dolor.py
./lorem/sit.py
./lorem/__init__.py
./ipsum
./ipsum/elit.py
./ipsum/adipiscing.py
./ipsum/consecteur.py
./ipsum/__init__.py
./debian
./debian/compat
./debian/rules
./debian/foo-app.links
./debian/changelog
./debian/control

$ cat ./setup.py
from setuptools import (setup, find_packages)

setup(
name="FooApp",
version="1.2.3",
packages=find_packages(),

entry_points={
'console_scripts': [
"execute-lorem = FooApp.lorem.dolor:main",
"execute-ipsum = FooApp.ipsum.conse

Re: Installing python modules in a non-standard way

2015-10-25 Thread Ben Finney
Onur Aslan <o...@onur.im> writes:

> I can't use --buildsystem=pybuild to install python wrappers, this
> package is not providing a configure script or Makefile. pybuild is
> not invoking autoreconf to generate a configure script.

Can you add a target to ‘debian/rules’ that will invoke ‘autoreconf’, as
a pre-requisite for the ‘override_dh_build’ target?

> Piotr suggested me to make a loop to install python3.4 and python3.5
> versions of package.

I don't use a loop, but rather a pattern-matching target and a Makefile
substitution variable to generate targets for all the supported Python
versions. It amounts to the same result, but is not “a loop”.

> But is it really necessary?

In the absence of Pybuild, yes I've found that explicitly making
separate targets for each supported Python version is necessary. This is
one of the main benefits of migrating to Pybuild.

> I am wondering what is proper way to install python modules in this
> package?

My suggestion: work hard to get the package to provide what Pybuild
needs, and let Pybuild do its job from there.

-- 
 \  “Our products just aren't engineered for security.” —Brian |
  `\ Valentine, senior vice-president of Microsoft Windows |
_o__)        development, 2002 |
Ben Finney



Does “${python3:Depends}” reliably generate correct dependencies?

2015-10-24 Thread Ben Finney
Howdy all,

If we set “Depends: ${python3:Depends}” in the binary package, and use
‘dh_python3’, is that all that is needed to ensure the correct
dependencies on Python 3 versions?

Recently I received this bug report (Bug#802889):

please don't depend on all python3 versions, forcing the
installation of all python versions shouldn't be enforced for a
module.

$ apt-cache show python3-coverage | grep Depends
Depends: python3-pkg-resources, python3 (<< 3.6), python3 (>= 3.4~),
python3.4, python3.5, libc6 (>= 2.4)

<URL:https://bugs.debian.org/802889>

So far as I can tell, these dependencies are generated because
“Depends: […] ${python3:Depends}” is in that “Package” definition.

On a Debian Sid system today, building a package for Python 3, along
with its extension modules, means building it for all supported Python 3
versions. Are the above dependencies wrong for that?

If the dependencies are incorrect, what should be used in the Depends
field instead of “${python3:Depends}”?

If the dependencies are correct, exactly what should I say in
explanation to the reporter of Bug#802889?

-- 
 \ “Smoking cures weight problems. Eventually.” —Steven Wright |
  `\   |
_o__)          |
Ben Finney



Re: DPMT Policy

2015-10-21 Thread Ben Finney
Piotr Ożarowski <pi...@debian.org> writes:

> [Barry Warsaw, 2015-10-21]
> > """
> > DPMT requires a pristine-tar branch, and only upstream tarballs can be used 
> > to
> > advance the upstream branch.  Complete upstream git history should be 
> > avoided
> > in the upstream branch.
> > """
>
> just a tiny change: s/  / /

+1 
<URL:http://www.slate.com/articles/technology/technology/2011/01/space_invaders.html>

-- 
 \  “The entertainment industry calls DRM "security" software, |
  `\ because it makes them secure from their customers.” —Cory |
_o__) Doctorow, 2014-02-05 |
Ben Finney



  1   2   3   4   >