[Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye
Control: tags -1 help On Wed, Sep 11, 2019 at 09:33:54AM -0300, Antonio Terceiro wrote: > E: Sub-process /usr/bin/dpkg returned an error code (1) > ~[100]$ cycle > File "/usr/bin/cycle", line 29 > if lang_find: > ^ > TabError: inconsistent use of tabs and spaces in indentation Argh. That's fixed via autopep8 in Git[1] now. However, when calling cycle I get $ cycle Traceback (most recent call last): File "/usr/bin/cycle", line 12, in from dialogs import * File "/usr/share/cycle/dialogs.py", line 8, in from cal_year import cycle, Val File "/usr/share/cycle/cal_year.py", line 9, in from dialogs import Note_Dlg ImportError: cannot import name 'Note_Dlg' from 'dialogs' (/usr/share/cycle/dialogs.py) Any idea how to fix this? Kind regards Andreas. [1] https://salsa.debian.org/med-team/cycle -- http://fam-tille.de
Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye
On Wed, Sep 11, 2019 at 04:12:34PM +0200, Andreas Tille wrote: > Control: tags -1 help > > On Wed, Sep 11, 2019 at 09:33:54AM -0300, Antonio Terceiro wrote: > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > ~[100]$ cycle > > File "/usr/bin/cycle", line 29 > > if lang_find: > > ^ > > TabError: inconsistent use of tabs and spaces in indentation > > Argh. That's fixed via autopep8 in Git[1] now. However, when calling > cycle I get > > $ cycle > Traceback (most recent call last): > File "/usr/bin/cycle", line 12, in > from dialogs import * > File "/usr/share/cycle/dialogs.py", line 8, in > from cal_year import cycle, Val > File "/usr/share/cycle/cal_year.py", line 9, in > from dialogs import Note_Dlg > ImportError: cannot import name 'Note_Dlg' from 'dialogs' > (/usr/share/cycle/dialogs.py) There are circular imports in the code so you most likely broke that by reordering imports in various files. "from cal_year import *; from dialogs import *" works, the reverse doesn't, so the /usr/bin/cycle code is definitely problematic, not sure about other changes. -- WBR, wRAR signature.asc Description: PGP signature
Re: dh-python and pylint
Hi! > thanks a lot, but what about backports. On backports we still need this > mapping. Aren't the backports built using the dh-python version of the platform they are ported to? In this case it shouldn't really matter right? I see that Ubuntu released a new dh-python with this exact fix. It seems to work fine. Right now the packages we push with the pylint3 dependency renamed still end up with pylint3 as dependency, so should we hold off on the auto-pylint transition until https://salsa.debian.org/python-team/tools/dh-python/merge_requests/9 is merged and release? Or is an automatic rebuild of the packages having that problem planned when that fix in dh-python is release? Thanks, Joseph
Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])
On 9/10/19 7:50 AM, Andreas Tille wrote: > Hi, > > in the process of the Python3 migration the package lefse was converted > using 2to3. Hi Andreas, I wont comment on the relative import ambiguity problem, as Ghislain replied correctly. However, I do want to comment on 2to3. I generally recommend against using it, in the favor of other tools. For example, you can use sixer, which I maintain in Debian, and often used (and abused) to do Python 3 conversions. There's also 2to6, which I don't know much about, but I've read it works about the same way as sixer (which was specifically written for OpenStack). The advantage is that you'll get a source code that will work on both Python 2 and 3. It's generally a way more easy to submit upstream, which may not want to loose Python 2 compatibility. Cheers, Thomas Goirand (zigo)
Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])
On 9/10/19 7:50 AM, Andreas Tille wrote: > Hi, > > in the process of the Python3 migration the package lefse was converted > using 2to3. Hi Andreas, I wont comment on the relative import ambiguity problem, as Ghislain replied correctly. However, I do want to comment on 2to3. I generally recommend against using it, in the favor of other tools. For example, you can use sixer, which I maintain in Debian, and often used (and abused) to do Python 3 conversions. There's also 2to6, which I don't know much about, but I've read it works about the same way as sixer (which was specifically written for OpenStack). The advantage is that you'll get a source code that will work on both Python 2 and 3. It's generally a way more easy to submit upstream, which may not want to loose Python 2 compatibility. Cheers, Thomas Goirand (zigo)
