Your message dated Sun, 7 Feb 2016 21:39:30 +0100
with message-id 
<CAHms=ea+_5w8d3rksbmymrbkdo_z86vmpkxwekbsww2bmok...@mail.gmail.com>
and subject line Re: Bug#814023: pyqt5-dev-tools should be offered in Python 2 
and 3 variants
has caused the Debian Bug report #814023,
regarding pyqt5-dev-tools should be offered in Python 2 and 3 variants
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
814023: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814023
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: pyqt5-dev-tools
Version: 5.4.2+dfsg-1build4~wily1~test1~qt551~1
Severity: normal

Dear Maintainer,

The pyqt5-dev-tools currently depends on Python 3. Since packages of PyQt5 are
for both Python 2 and 3 are available, I think it would make sense to split
this package into python3-pyqt5-dev-tools and python2-pyqt5-dev-tools, for
Python 3 and Python2, respectively. The scripts installed would have to be
renamed (e.g. "python2-pyuic5" and "python3-pyuic5" to avoid conflict).

As it currently stands, if I'm developing a PyQt5 application using Python 2, I
need the tools provided by this package. But installing it needlessly forces me
to install Python 3. I have no problem with installing Python 3 on my dev
machine, but when building the application in a clean environment such as
Docker, pulling in Python 3 seems a bit silly. It would be much better if there
was a python2-pyqt5-dev-tools I could install.

-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-25-generic (SMP w/4 CPU cores)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pyqt5-dev-tools depends on:
ii  libc6          2.21-0ubuntu4
ii  libgcc1        1:5.2.1-22ubuntu2
ii  libqt5core5a   5.5.1+dfsg-1ubuntu1~wily1~test1
ii  libqt5xml5     5.5.1+dfsg-1ubuntu1~wily1~test1
ii  libstdc++6     5.2.1-22ubuntu2
ii  python3        3.4.3-4ubuntu1
ii  python3-pyqt5  5.4.2+dfsg-1build4~wily1~test1~qt551~1

pyqt5-dev-tools recommends no packages.

pyqt5-dev-tools suggests no packages.

-- no debconf information

--- End Message ---
--- Begin Message ---
2016-02-07 19:40 GMT+01:00 Elvis Stansvik <[email protected]>:
> Hi Dimitry,
>
> 2016-02-07 18:10 GMT+01:00 Dmitry Shachnev <[email protected]>:
>> Hi Elvis,
>>
>> On Sun, Feb 07, 2016 at 05:48:40PM +0100, Elvis Stansvik wrote:
>>> The pyqt5-dev-tools currently depends on Python 3. Since packages of PyQt5 
>>> are
>>> for both Python 2 and 3 are available, I think it would make sense to split
>>> this package into python3-pyqt5-dev-tools and python2-pyqt5-dev-tools, for
>>> Python 3 and Python2, respectively. The scripts installed would have to be
>>> renamed (e.g. "python2-pyuic5" and "python3-pyuic5" to avoid conflict).
>>
>> Please remember that initally our PyQt5 packages were for Python 3 only.
>> We have added Python 2 packages only to help other applications (like 
>> Calibre)
>> porting from PyQt 4 to PyQt 5. I do not recommend using Python 2 in new code.
>
> I see, that explains why there's no Python 2 variant. I wouldn't
> recommend Python 2
> either, but in this case a dependency on VTK keeps us on Python 2 for now, 
> until
> VTK 7 has been packaged (which is Python 3 ready). This should happen 
> soon-ish,
> but we need to work on our tool right now. We'll switch to Python 3 as soon as
> something like a python3-vtk7 package is ready (debian-sci-maintainers
> are working
> on it).
>
>>
>>> As it currently stands, if I'm developing a PyQt5 application using Python 
>>> 2, I
>>> need the tools provided by this package. But installing it needlessly 
>>> forces me
>>> to install Python 3. I have no problem with installing Python 3 on my dev
>>> machine, but when building the application in a clean environment such as
>>> Docker, pulling in Python 3 seems a bit silly. It would be much better if 
>>> there
>>> was a python2-pyqt5-dev-tools I could install.
>>
>> I will not do this. If you just need to use pyuic with Python 2 then you may
>> just use “python2 -m PyQt5.uic.pyuic command” which needs only python-pyqt5.
>
> Yea, that's what I'll do for now. The tool I'm using for invoking
> pyuic (pyqt-distutils)
> even has options letting me specify the command, so that should work fine.
>
>>
>> What I can do is to replace a dependency on python3 with a recommendation —
>> as two of three tools in this package are written in C++ and do not need 
>> Python
>> at all. Let me know if this will help you.
>
> That would be much appreciated, because I need the pyrcc5 binary provided by 
> the
> package, and if you would drop the dependency to a recommendation, I could 
> avoid
> unnecessarily installing Python 3 in the Docker container where I deploy my 
> app.

After some discussion with ScottK on Freenode, it seems it's not so easy to do
the above after all, as it would break building for some other packages.

I'm closing this bug and will live with this inconvenience until we can move to
Python 3, which should hopefully be soon (pending a python3-vtk7 package).

Scott also suggested I look at equivs to fake-provide a python3, which is hacky
but could be OK since I'd only do it in our Dockerfile.

Thanks for looking into this.

Elvis

>
> Thanks for the quick reply.
>
> Elvis
>
>>
>> --
>> Dmitry Shachnev

--- End Message ---
_______________________________________________
Python-modules-team mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team

Reply via email to