Re: on keep providing python 2 packages
On Fri, Aug 19, 2016 at 6:26 PM, Dmitry Shachnev <mitya57@debian.org> wrote:
> Hi Sandro,
>
> On Fri, Aug 19, 2016 at 11:49:25AM +0100, Sandro Tosi wrote:
>> > For example, I have a module (which supports both Python 2 and 3), but
>> > the only user of this module is an app (which is Python 3 only).
>>
>> then this should be an internal module, installed in /usr/share/<pkg>
>> and not importable via python -c "import <module>"
>
> It was initially private, but then was split out into a separate module
> because it can be potentially useful for others.
>
> Since that, some third party projects are using it, but they are all
> Python 3 AFAIK (module in question is pymarkups).
but you are not aware of all the potential users of the py2 version,
they are none now because there is not such version available for them
(as Elena mentioned out in her reply)
>
>> i think we have to support python2 and python3 at the best we can, as
>> we mandate to have py3k packages
>> (https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html)
>> i think we should extend the same level of support to python2, until
>> it will be decided to drop that stack completely
>
> How about at least replacing “must” with “should” in the proposed wording?
that text was not meant to be a patch to the policy (yet), but the
idea is to be mandatory to support every version upstream supports, so
the should is just too weak: you can if you want, but you are not
forced to. the must expresses that's mandatory
anyway, why wouldnt you want to provide a python2 package if the code
supports it? if you got a py3k package working, it's usually
straightforward to have a py pkg. Doing that i've found several issues
with upsteam projects that were fixed, thus increasing the general
quality of their code and our distribution
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi
Reply to: