Dear Maintainer,
When applications (e.g. tox) are Python 3 scripts but are contained in
binary packages named python-foo instead of python3-foo, pybuild won't
apply Python 3 transformations to it. For example, renaming
usr/lib/python3.X/dist-packages to usr/lib/python3/dist-packages
However, in almost all such cases, the binary package will Depend:
${python3:Depends} so that should be a good enough indication that
the binary package should get those transformations.
- -- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dh-python depends on:
pn python3:any <none>
dh-python recommends no packages.
dh-python suggests no packages.
- -- no debconf information
iQIcBAEBCAAGBQJToIcxAAoJEBJutWOnSwa/0HIQAIWnCuZohVVF9KsPoIc0z2WO
h/829foavzQLk7a+h0EDdhPdJ5DG2JxX6kcbMNheWxgJPMgDvzdV8UQvKvh1ksbu
GmiqkQskzLEOaUeVEwDmzP7CUOd3lYvpP5biSDmKN7y7w0m9RL7rfchNpL3uUQ9G
TTy3sSsKca2LX2d+PsOP1Ep8gAThEhpX67y4q1YDo/3ZC9QE3uXIvqTXJOdGsDXD
UGpMjhVaMkMDALf4f8horOipM79E6bB9UuVv2kfSmhqtBfuZSH1VG5kHiwPa1HF8
9WzMHhwQ0zjuTroE6UZEnt6gtqJHdhECxJ1UiqXoCGdGBd2JNuCDePb/slGxz6Tp
6yYGGDHqjE/u0IuTCdeZcmOXgA3Gsm4LQzKUetQzo5/v6+fO1T5D3WCjXAzSgdCh
BA3NkqUnPZyKNgp0R2jCTKBppmJ+O93CScUEIcuiqvJYJOIJMX0eNe7CcirL28K2
Ia0pWvXFKL605sBU2Aa6JtBoPsId4Klb98s7OEBiceoAJMPiOUbUJ0tTFvDRMkAQ
yrkHHPdDID2KzJfJjzspGEVknNzxBVovJzft9lkZo966v6YrY0092t2BiSK06kB1
mSm300sR1pyI9FofP9wjc/rH7kwN8gmSRzybIo4spqkkUXd9iiQ6OMGzCudUMJX6
abBgDmrTa75Gwv1dDtbO
=qudG
-----END PGP SIGNATURE-----
Control: tags 751908 + wontfix
thanks
dh_python3, not pybuild.
* pybuild is for building/installing/testing
* dh_python3 is for messing with already installed files
(moving to the right location, adding postinst/prerm maintainer
scripts, etc.)
I'm sorry, but our policy says python-foo packages should contain 2.X
code and 3.X should go to python3-foo packages.
(I know I told you on IRC I will implement it, but then realized it's
against policy - I mentioned it in the channel IIRC)
I will do something like this (checking for ${python3:Depends} or
${python:Depends} or ${pypy:Depends} in Depends) in foo packages, not in
python-foo ones
Control: tags 751908 + wontfix
thanks
dh_python3, not pybuild.
* pybuild is for building/installing/testing
* dh_python3 is for messing with already installed files
(moving to the right location, adding postinst/prerm maintainer
scripts, etc.)
I'm sorry, but our policy says python-foo packages should contain 2.X
code and 3.X should go to python3-foo packages.
(I know I told you on IRC I will implement it, but then realized it's
against policy - I mentioned it in the channel IIRC)
I will do something like this (checking for ${python3:Depends} or
${python:Depends} or ${pypy:Depends} in Depends) in foo packages, not in
python-foo ones
Sorry about the bug mis-identification (I knew better). I think this is fine, however we do need to be more explicit about cases where a package is either split into bilingual libraries + executable, or just an application with ancillary libraries (some might say "private" library). There are lots of examples where the latter exists in python-foo binary packages. virtualenv was a prime example and its Python 3 executable has now been moved to `virtualenv` (no prefix). If we cannot have a Python 3 application live in a python-foo binary package, then we need to be explicit about this in Python policy, and the application style guide.
Sorry about the bug mis-identification (I knew better). I think this is fine, however we do need to be more explicit about cases where a package is either split into bilingual libraries + executable, or just an application with ancillary libraries (some might say "private" library). There are lots of examples where the latter exists in python-foo binary packages. virtualenv was a prime example and its Python 3 executable has now been moved to `virtualenv` (no prefix). If we cannot have a Python 3 application live in a python-foo binary package, then we need to be explicit about this in Python policy, and the application style guide.
python-foo packages have to provide public libraries, you can ship additional private libraries or scripts in the same package but I think it's cleaner to separate them into new binary package (especially if this application/private library requires additional dependencies). If you want to ship a private library that works with 3.X only then it simply is not acceptable due to additional python3 dependency (you cannot force anyone to install python3 when you apt-get install python-foo) policy mentions that Python 2.X and Python 3.X are separate languages for us and that's why we have python-foo and python3-foo packages. I don't want APT to install python3 when I install python-foo and I don't want APT to install python when I install python3-foo. If you want one package to provide Python 2.X and Python 3.X code - it's fine, just don't use "python-" or "python3-" prefix in package name and don't provide public libraries.
I agree with what you said, but it's not the point. :)
Take a package like virtualenv. Its library is compatible with both Python 2
and Python 3, plus it provides a command line executable, /usr/bin/virtualenv.
It is set in policy and uncontroversial that the Python 2 version of the
library should be put in the python-virtualenv binary package. Likewise for
the Python 3 version of the library going into python3-virtualenv.
Policy does not specify, afaict, what the binary package name should be that
contains /usr/bin/virtualenv. When compatible, we generally now prefer
executables to be shebang /usr/bin/python3. Clearly, neither
python-virtualenv nor python3-virtualenv are the appropriate binary packages
to contain /usr/bin/virtualenv (and its manpage). python-virtualenv is
clearly inappropriate because it's Python 2, and python3-virtualenv is
inappropriate because especially in a bilingual package, it should only
contain the libraries.
Note in that case that historically, python-virtualenv also contained the
executable, and I resolved the issue by adding a `virtualenv` binary package,
putting the executable and manpage in there.
However, let's take application Foo written in Python 3, with a /usr/bin/foo
executable. But let's say it either doesn't have a Python 2 compatible
library, or it doesn't have any library it generally expects to be imported,
so there are no appropriate python{,3}-foo binary packages. Since we want
dh_python3 to do the right thing with its support code anyway, some questions
come to mind:
* What should its binary package name be?
* What tools should we use to build it?
* How do we tell those tools to install everything in the right place?
Often, such applications are put in a python-foo binary package. Now, I think
that's historically wrong because it clashes with what policy now says
python-foo should be, i.e. the Python 2 version of the library. python3-foo
doesn't seem right either, so I'm suggesting that Debian Python Policy (DPP)
recommend or require that the application go in binary package 'foo' *without*
a python- or python3- prefix. If 'foo' clashes with other binary packages in
the archive, then it must be disambiguated, but DPP should prohibit using
"python-" or "python3-" as a prefix in that case. E.g. maybe call it
'foo-python' (this is where we need a decision!)
I think you still want to use pybuild and dh_python3 for the Python 3
application "foo", which is why I favor the latter doing its manipulations
when binary package "foo" or "foo-python" or "foo-application" Depends on
${python3:Depends}, which I think you're also agreeing with.
So really, all we need to do (in addition to resolving this bug :) is to make
it clear the DPP prohibits applications from being put in the python-foo
binary package, *especially* if it's a Python 3 application.