duplicity-team team mailing list archive

[Kenneth Loafman <kenneth@xxxxxxxxxxx>]

Hi,

Been looking at Python 3 w.r.t. the requirement.txt entries and it appears
that python-cloudfiles is the only one that will not immediately load due
to naming changes in urllib.  Urlencode moved in 3 and I'm quite sure other
things have moved as well.  But, this looks promising.

I'm sure that we will not want to maintain 2 and 3 versions of the code, so
I'm proposing that we cut off 2.x after the 0.8-series and make 0.9-series
be 3.x and above.  Now, since I've been reading, where do we start in the
3.x Python series?  It seems that there's a break in there, around 3.3 (?)
where it would be difficult to maintain backwards compatibility.  I need
some advice on this.  Is there need of supporting Python 3.0 thru 3.3?

...Ken

ken@dione:~/workspace/duplicity-src8$ pip3 install -U -r requirements.txt
Collecting boto (from -r requirements.txt (line 1))
  Using cached boto-2.48.0-py2.py3-none-any.whl
Collecting coverage (from -r requirements.txt (line 2))
  Using cached coverage-4.4.2-cp36-cp36m-macosx_10_12_x86_64.whl
Collecting dropbox==6.9.0 (from -r requirements.txt (line 3))
  Using cached dropbox-6.9.0-py3-none-any.whl
Collecting fasteners (from -r requirements.txt (line 4))
  Using cached fasteners-0.14.1-py2.py3-none-any.whl
Collecting future (from -r requirements.txt (line 5))
  Using cached future-0.16.0.tar.gz
Collecting jottalib (from -r requirements.txt (line 6))
  Using cached jottalib-0.5.1.tar.gz
Collecting mock (from -r requirements.txt (line 7))
  Using cached mock-2.0.0-py2.py3-none-any.whl
Collecting paramiko (from -r requirements.txt (line 8))
  Using cached paramiko-2.4.0-py2.py3-none-any.whl
Collecting pexpect (from -r requirements.txt (line 9))
  Using cached pexpect-4.3.1-py2.py3-none-any.whl
Collecting pycodestyle (from -r requirements.txt (line 10))
  Using cached pycodestyle-2.3.1-py2.py3-none-any.whl
Collecting pydrive (from -r requirements.txt (line 11))
  Using cached PyDrive-1.3.1.tar.gz
Collecting pylint (from -r requirements.txt (line 12))
  Using cached pylint-1.8.1-py2.py3-none-any.whl
Collecting pyrax (from -r requirements.txt (line 13))
  Using cached pyrax-1.9.8-py2.py3-none-any.whl
Collecting pytest (from -r requirements.txt (line 14))
  Using cached pytest-3.3.1-py2.py3-none-any.whl
Collecting pytest-runner (from -r requirements.txt (line 15))
  Using cached pytest_runner-3.0-py2.py3-none-any.whl
Collecting python-cloudfiles (from -r requirements.txt (line 16))
  Using cached python-cloudfiles-1.7.11.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File
"/private/var/folders/qr/rwbgbn9s1d1g4vhk1g9zngdr0000gn/T/pip-build-bg66scvi/python-cloudfiles/setup.py",
line 6, in <module>
        from cloudfiles.consts import __version__
      File
"/private/var/folders/qr/rwbgbn9s1d1g4vhk1g9zngdr0000gn/T/pip-build-bg66scvi/python-cloudfiles/cloudfiles/__init__.py",
line 82, in <module>
        from cloudfiles.connection     import Connection, ConnectionPool
      File
"/private/var/folders/qr/rwbgbn9s1d1g4vhk1g9zngdr0000gn/T/pip-build-bg66scvi/python-cloudfiles/cloudfiles/connection.py",
line 13, in <module>
        from    urllib    import urlencode
    ImportError: cannot import name 'urlencode'


On Sun, Dec 3, 2017 at 10:18 AM, Kenneth Loafman <kenneth@xxxxxxxxxxx>
wrote:

> It's been merged.  Thanks for all the fixes!
>
> I left the ANSI_... stuff in there.  It looks like getfilesystemencoding()
> has had a lot of issues!  Pity we have to rely on it.
>
> ...Ken
>
>
> On Sat, Dec 2, 2017 at 10:55 AM, Kenneth Loafman <kenneth@xxxxxxxxxxx>
> wrote:
>
>> I'll merge it this weekend.  Fighting with a new router today.  😏
>>
>> On Sat, Dec 2, 2017 at 10:36 AM, Aaron <lists@xxxxxxxxxxxxxxxxxx> wrote:
>>
>>> Sorry Ken, I had already submitted my branch for merging before I saw
>>> this.
>>> On 01/12/17 20:43, Kenneth Loafman wrote:
>>>
>>> Hi Aaron,
>>>
>>> Not sure about adding ANSI_X3.4-1968.  That would mean that the system
>>> indeed hand locale specified properly.
>>>
>>> The values 'ascii' and None were returned when locale was not specified
>>> at all (detached or cron jobs on some setups).  ANSI implies a proper
>>> locale setting.
>>>
>>> ...Ken
>>>
>>> I am not sure I see the conceptual distinction between ascii and ANSI_X3.4-1968
>>> in this context. I believe ANSI_X3.4-1968 is an alias for ASCII and is
>>> often also a default when things are misconfigured -- a quick Google brings
>>> up a bunch of "why does x return ANSI_X3.4-1968 instead of y", e.g.:
>>> https://stackoverflow.com/questions/44344458/why-does-locale
>>> -getpreferredencoding-return-ansi-x3-4-1968-instead-of-utf-8
>>> "Since in your locale LC_ALL is not set, the ASCII default (“ANSI
>>> X3.4-1968”) is used (this might answer your question in the title)."
>>>
>>> I agree there is some risk of a system deliberately configured as ANSI_X3.4-1968
>>> will be misinterpreted as UTF-8, but think that same risk exists with the
>>> recent change to make 'ascii' default to UTF-8. As the code/my branch is
>>> currently, this global is only used for reading encoded text and, as UTF-8
>>> is a superset of ascii/ANSI_X3.4-1968, I cannot see how it could go
>>> wrong unless/until somebody also uses that global for writing.
>>>
>>> If you do not want to merge this approach, I would really appreciate
>>> further thoughts on how else to get past the pexpect/testing environment
>>> being misdetected as ANSI_X3.4-1968, as I'm at a bit of a loss.
>>>
>>> Kind regards,
>>>
>>> Aaron
>>>
>>>
>>
>