Repository: borgbackup/borg

Issue:
drop python 3.5?
current master branch is working towards "hydrogen" release, likely not released before Q4/2018.

considering that current stable dists will rather stay with borg 1.1.x, i guess we could target future stable dists and drop python 3.5 testing and support.

a lot currently stable dists already have py36, debian stretch being an exception - but as they won't upgrade from 1.1 to 1.2 in stable anyway, no problem there either.

Reasons to drop 3.5 (note that we already had dropped 3.4 a while ago in master):

- https://docs.python.org/3/whatsnew/3.6.html
- quicker testing, less waiting for travis-ci and vagrant based tests (we will have to add py37 testing soon)

Note: pyinstaller should work with py36 since pyi 3.3.

Any important reasons to keep py35?


Discussion:
note: switched the stretch64 vagrant VM to pyenv, so we have py35 from the dist and py36 via pyenv.

for building the borg binary it uses the py36, works.

py 3.5.0 does not build via pyenv, openssl 1.1 issue?
That'd instantly exclude all Ubuntu 16.04 users as it has python 3.5 as the latest version in the repos (https://packages.ubuntu.com/xenial/python/python3). I guess many people still use this Ubuntu release is it's long term supported until 2021. Borg is also include with an older version in the repo – same as with Debian. But with Ubuntu it's much more common to use external repos (PPA) to keep selected tools up to date.
this ticket is about master branch which will eventually lead to a borg 1.2 release later. it doesn't mean we'll drop py 3.5 (or 3.4) for 1.1-maint or 1.0-maint branch (borg 1.1.x / 1.0.x releases).

xenial has borg 1.0.2
xenial-updates has borg 1.0.11
xenial-backports has nothing
@LocutusOfBorg's ppa has borg 1.1.5 for xenial

i don't think it makes much sense to support bleeding edge for ubuntu old-lts - people keen on bleeding edge sw usually use something newer.

borg 1.2 would likely work on the current lts, bionic, which has py36 and openssl 1.1 (and is used for one of our vagrant test machines).

also, there is no problem continuing to use borg 1.1.x (or even 1.0.x) on the xenial machines. at least for 1.1 there will be bug and security fix releases in parallel to borg 1.2.x.

the fat binary we will provide for 1.2 releases (which will include py36, openssl 1.1, etc.) might run on xenial - so that might be an option, too.

> That'd instantly exclude

Ok, i admit "instantly" was a bit to hysteric 🙂

> the fat binary … will include py36

Really? You'll include a python 3.6 runtime into the deb just for being used by borg? Wouldn't that add the need to update the package every time python 3.6 gets an update?

The fat binary is what you see there (it's not the .deb package):

https://github.com/borgbackup/borg/releases

And yes, bundling a lot of stuff together means that it needs an update at least when one of the parts has a critical issue.
fine for me, xenial can continue to get 1.1 from my ppa in case.
This may make borg 1.2 a bit hard to test on debian and its derivatives != ubuntu. Stretch is on python 3.5 and stretch will go EOL only in 2022 with Buster not likely to come out before 2020. Unfortunately python 3.6 is not in the debian stretch backports either and from discussion on groups it looks like python 3.6 will not be officially backported. With this, the various alphas and betas of borg 1.2 might not be testable on debian (other than for those who can switch to debian testing).  Missing the opportunity to test in debian may mean missing the less used architectures which are supported in debian and debian ports.
@callegar hmm, good points, reopening.

Current state of master branch is that we dropped 3.5 - consider reverting this change.
Just noticed that you reopened, considering reverting the change. Thanks for considering my points above!
I recently switched to qubes os on my laptop, it has debian 9...

But using `pyenv`, one can install any python version one likes on debian stretch, even 3.7 and 3.8-dev. Just wanted to put that info here in case someone needs it.

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -276,6 +276,7 @@ def run(self):
         'Operating System :: POSIX :: Linux',
         'Programming Language :: Python',
         'Programming Language :: Python :: 3',
+        'Programming Language :: Python :: 3.5',
         'Programming Language :: Python :: 3.6',
         'Programming Language :: Python :: 3.7',
         'Topic :: Security :: Cryptography',
@@ -302,5 +303,5 @@ def run(self):
     setup_requires=['setuptools_scm>=1.7'],
     install_requires=install_requires,
     extras_require=extras_require,
-    python_requires='>=3.6',
+    python_requires='>=3.5',
 )
diff --git a/src/borg/archiver.py b/src/borg/archiver.py
--- a/src/borg/archiver.py
+++ b/src/borg/archiver.py
@@ -2138,11 +2138,11 @@ def do_break_lock(self, args, repository):
 
         {now}
             The current local date and time, by default in ISO-8601 format.
-            You can also supply your own `format string <https://docs.python.org/3.6/library/datetime.html#strftime-and-strptime-behavior>`_, e.g. {now:%Y-%m-%d_%H:%M:%S}
+            You can also supply your own `format string <https://docs.python.org/3.5/library/datetime.html#strftime-and-strptime-behavior>`_, e.g. {now:%Y-%m-%d_%H:%M:%S}
 
         {utcnow}
             The current UTC date and time, by default in ISO-8601 format.
-            You can also supply your own `format string <https://docs.python.org/3.6/library/datetime.html#strftime-and-strptime-behavior>`_, e.g. {utcnow:%Y-%m-%d_%H:%M:%S}
+            You can also supply your own `format string <https://docs.python.org/3.5/library/datetime.html#strftime-and-strptime-behavior>`_, e.g. {utcnow:%Y-%m-%d_%H:%M:%S}
 
         {user}
             The user name (or UID, if no name is available) of the user running borg.


Test patch: