Dear Maintainer,

I've been using dh-python to build a package and I've had to add a version
dependency in my setup.py (requests >= 2.4.2) but this isn't being picked up
and added to the debian/control.
The package will depend on python3-request in the control file but without the
versioning string.
Doing a quick look on source.debian.net this isn't a bug only I'm seeing.
http://sources.debian.net/src/pexpect/4.2.0-1/setup.py/ (final line has
install_requires=['ptyprocess>=0.5'])
http://sources.debian.net/src/pexpect/4.2.0-1/debian/control/ (control file
"Build-Depends: dh-python, python-all (>= 2.6.6-3~), python3-all, python-
sphinx, debhelper (>= 9), python-ptyprocess, python3-ptyprocess, python-pytest,
python3-pytest" no versioning on python-ptyprocess)

I believe the source of this is:
dh-python/dhpython/pydist.py

152             if req_d['version'] and (item['standard'] or item['rules'])
and\
153                     req_d['operator'] not in (None, '==', '!='):
154                 v = _translate(req_d['version'], item['rules'],
item['standard'])
155                 return "%s (%s %s)" % (item['dependency'],
req_d['operator'], v)

The offending section is (item['standard'] or item['rules]) the first one is
None the second one is []
and then the whole expression reduces down to "[]" which is False in python so
we fall through to.

156             else:
157                 if item['dependency'] in bdep and
bdep[item['dependency']][None]:
158                     # TODO: handle architecture specific dependencies from
build depends ("None" below)
159                     return "{} ({})".format(item['dependency'],
bdep[item['dependency']][None])
160                 return item['dependency']

Which only gives the package name, not the version depedency.

Changing the code to:

152             if req_d['version'] and (item['standard'] is not None or
item['rules'] is not None) and\
153                     req_d['operator'] not in (None, '==', '!='):
154                 v = _translate(req_d['version'], item['rules'],
item['standard'])
155                 return "%s (%s %s)" % (item['dependency'],
req_d['operator'], v)

Solved the problem and added the version string to the control file. Is this a
valid solution? I'm not sure what exactly the item dictionary is supposed to do
so I might not have setup the package generation properly.
item['standard'] was None in and item['rules'] was an empty list, if the above
isn't a bug is there something I can do to add an entry to the item['rules']
list?

Cheers,
Anthony

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

Control: tags -1 wontfix

dh_python{2,3} ignores version on purpose. It does more than that, it
removes recognized dependency from requires.txt so the version is
ignored later by pkg_resources as well. I'm sure Python guys hate me for that.

There was PEP386, there is PEP440 and plenty of other related PEPs or
ideas on how to handle versions. The other thing is to put latest or
unreleased version into install_requires (AKA requires.txt AKA Requires header)
just because that's the version upstream worked with during development.

Until I'm convinced that they finally figured that out and the exception
is when an upstream project doesn't follow the standard rather than when
it actually follows it - Debian maintainer will have to confirm that
upstream is sane WRT versioning to get it copied/translated into Debian
dependency (and to do that: pydist file with "PEP386" flag has to be
installed or maintainers have to add versioned build dependency - which
is my preferred solution as in most cases that version is required for
tests during build anyway)


PS I heard some rumors that PyPI will enforce one of the standards, but
   I don't know the status of that

Ok, thank you for the explanation and the quick response :).

Cheers,
Anthony

I think this is the wrong approach. A too-tight dependency is a
problem, but too-lax ones are a problem too. At least for lower
bounds. Upper bounds are a bit more problematic and package
maintainers should remove the upper bounds where they make no sense.
But they are very reasonable if the module is following semantic
versioning, and the upper bound is on the next major version.

See #841314, the versioned build-dep is not propagated to the binary package.


According to the python packaging doc, all modules must satisfy PEP440[1]

[1] https://packaging.python.org/distributing/#standards-compliance-for-interoperability


Saludos

[Felipe Sateler, 2016-10-19]

can you point me to a source package where I can reproduce it or close
this bug?

docker-compose, version 1.8.0-1. That package has a
debian/pydist-overrides file, but removing it had no effect.