Re: Dropping Python 2 (Problem with ipaddr)

[Adolf Belka <adolf.belka@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 4703 bytes --]

Hi Michael, All

On 11/05/2021 12:40, Michael Tremer wrote:
> Hello,
> 
> Python3 comes with an own module to handle IP addresses. Therefore I am not sure if there is any need to bundle any of the alternative ones.
> 
> What is depending on this? Can we not simply drop this?
There has not been any further response on this. Should I raise a patch to remove this module from IPFire?

Regards,
Adolf.
> 
> -Michael
> 
>> On 11 May 2021, at 11:37, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi All,
>>
>> I have run into a problem with ipaddr that I have not been able to solve myself.
>>
>> ipaddr.py has a lot of python2 specific code in it so I ran the 2to3 convertor on it. That fixed those issues.
>>
>> Then I had the problem that the original ipaddr.py had a mixture of spaces and tabs at the line starts. Python2 appears to have accepted this but python3 doesn't.
>>
>> So I converted all initial line tabs to spaces in the file and reran the build and that problem was solved.
>>
>> Now I am getting the following error message.
>>
>>      cd /usr/src/ipaddr-1.2 && install -m 0644 ipaddr.py /usr/lib/python3*
>>      /usr/bin/python3 -c "import ipaddr"
>>      Traceback (most recent call last):
>>      File "<string>", line 1, in <module>
>>      File "/usr/lib/python3.8/ipaddr.py", line 1287, in <module>
>>      broadcast_network = network('255.255.255.255', 32, DEMAND_FILTER)
>>      File "/usr/lib/python3.8/ipaddr.py", line 612, in __init__
>>      self.ip = ipaddr(ip)
>>      File "/usr/lib/python3.8/ipaddr.py", line 351, in __init__
>>      self.intrep = int(ip)
>>      ValueError: invalid literal for int() with base 10: '255.255.255.255'
>>      make: *** [ipaddr:75: /usr/src/log/ipaddr-1.2] Error 1
>>
>> python2 had long variables as well as int. python3 only has the int variables which are also longs.
>>
>> However python2 long appeared to accept the string '255.255.255.255' as an input and python3 does not.
>>
>> I don't know how to deal with this problem.
>>
>>
>> If this issue is a fundamental stop to using ipaddr.py with python3 I have found that python3 has, as standard, ipaddress.py available which I believe is supposed to cover the same things as ipaddr.py does. I just don't know if it does it with the same usage format or not. I could not find where in IPFire, ipaddr.py is being used.
>>
>>
>> Any help, advice, direction is gladly welcomed.
>>
>>
>> Regards,
>>
>> Adolf.
>>
>> On 05/05/2021 16:27, Michael Tremer wrote:
>>> Hello,
>>>
>>> I would like to talk about what has been discussed at the last developer conference call this week: Dropping Python 2
>>>
>>> This version of Python has reached its end of life and will no longer receive any security fixes. Hence we need to get rid of it as soon as possible.
>>>
>>> However, there is lots of software that still depends on it which has to be migrated away first.
>>>
>>> There are at least the following packages:
>>>
>>> boost
>>> fetchmail
>>> fireinfo
>>> iotop
>>> ipaddr
>>> libxml2
>>> libxslt
>>> newt
>>> nmap
>>> python
>>> python-clientform
>>> python-daemon
>>> python-distutils
>>> python-distutils-extra
>>> python-docutils
>>> python-feedparser
>>> python-inotify
>>> python-ipaddress
>>> python-m2crypto
>>> python-mechanize
>>> python-optional-src
>>> python-pyparsing
>>> python-rssdler
>>> python-setuptools
>>> python-six
>>> python-typing
>>>
>>> We also have the following scripts:
>>>
>>> config/ca-certificates/certdata2pem.py
>>> config/unbound/unbound-dhcp-leases-bridge
>>>
>>> Fireinfo is written by us and has a lot of C which will make it a little bit more difficult to migrate. We would also have to be very careful to not change any behaviour of the current implementation.
>>>
>>> The rest is probably either software that is entirely written in Python 2 or software that brings bindings for Python. The latter case is easy because we can either force it to build with Python 3 or we just disable the bindings.
>>>
>>> Ultimately we might need to keep Python around in the build system if there are other packages that rely on it. However, it would be great if we were able to remove it from the distribution very soon. Looking at his list, it does not seem to be too difficult.
>>>
>>> Would anyone be up to help and remove Python from any of those packages above? I would like to aim for Core Update 158 and remove as much stuff as possible - if we can everything - and then remove Python 2 in the update after that. If anyone has any custom scripts or applications, people will have some time to migrate away.
>>>
>>> Best,
>>> -Michael
>