install borgmatic in virtualenv

[stroobl]

Should fix #60.

Install borgmatic in a virtualenv in /opt/borgmatic and create a wrapper script in /usr/local/bin to use borgmatic from that location. Feel free to suggest improvements.

Also tested this on my laptop since an Ubuntu dist-upgrade broke borgmatic and I didn't really like the current system-wide installation (which also includes a not recommended update of setuptools that has been installed from a package).

[m3nu]

Like it. That's how my own servers are set up, if Python tools need to be installed.

Let me just check if there are any other implications by changing this path. Then merge it.

[m3nu]

Thanks for the great addition! 🙏

[kenayagi]

I'm facing a problem since this addition:

"Failed to find required executable python3 -m venv in paths: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

But a valid python3 actually exists in /usr/bin/python3 and running /usr/bin/python3 -m venv venv in a console works as expected.

Do you have any tip to solve this issue?

[m3nu]

Which OS and version are you using? I tried on Ubuntu yesterday and it was fine. Our CI tests are also fine. So would need to test it on your specific version.

From experience, this issue happens, when the python3-virtualenv package is missing for some reason. The role should install it, but who knows.

[m3nu]

We may need python3-venv for a few more distros here: https://github.com/borgbase/ansible-role-borgbackup/tree/master/vars

[m3nu]

I'm collecting the missing parts here: https://github.com/borgbase/ansible-role-borgbackup/pull/71

So let me know which OS you used to trigger the error, @kenayagi and I'll see what's happening.

[kenayagi]

I've tried on some Debian Buster and Debian Stretch. In all of them the python3-virtualenv package is installed.

(the machines were already managed with a previous version of this role)

[kenayagi]

Update!

I think that something got broken on my management client.

I've just reset the virtualenv (client-side) with Python 3.8 and only

ansible==4.1.0
pip==21.1.2
setuptools==57.0.0
wheel==0.36.2

and now it seems to regularly works even with remote servers.

I'm sorry for having bothered you. Thanks @m3nu for the quick feedback, anyway.

[m3nu]

Can happen. I recall something similar when using Ansible. Was long before this role changed.

But glad it's resolved now. I think using a virtualenv in /opt is a great improvement and it's also how I deploy most of my other projects.

[calbasi]

Update!

I think that something got broken on my management client.

I've just reset the virtualenv (client-side) with Python 3.8 and only

ansible==4.1.0
pip==21.1.2
setuptools==57.0.0
wheel==0.36.2

and now it seems to regularly works even with remote servers.

I'm sorry for having bothered you. Thanks @m3nu for the quick feedback, anyway.

Hi, I'm having this issue too. I'm not an experimented Ansible user, just a newbie. Then, I don't understand what have you done to solve your issue.

I'm executing the ansible in a Debian 10 computer, using the default Python 3.7,3. And the target server, where I want to install the borg stuff is another Debian 10 machine.

Where and how can I reset the "virtaulenv"?

[calbasi]

By the way, my Debian 10 run ansible 2.7.7:

$ ansible --version ansible 2.7.7 config file = /etc/ansible/ansible.cfg configured module search path = ['/home/MYUSER/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python3/dist-packages/ansible executable location = /usr/bin/ansible python version = 3.7.3 (default, Jan 22 2021, 20:04:44) [GCC 8.3.0]

[calbasi]

I've tried using a Debian 11 as "ansible manager" and I have not this issue. So I think there is a problem using Debian 10.

[kenayagi]

Where and how can I reset the "virtaulenv"?

With "reset" I meant to simply delete the entire virtualenv folder and recreate it from scratch.