openvpn2 front-end: ModuleNotFoundError

[openvpn]

openvpn2 front-end: ModuleNotFoundError

[dsommers]

Hi,

Yes, this is a known issue when installing from source directly (tarball or git), on at least Debian and Ubuntu. The "problem" is the automatically generated install rules autoconf/automake figures out ends up using /usr/lib/python3.?/site-packages/, which is where the openvpn3 module lands. But on Debian and Ubunty, Python base installs has been modified to use /usr/lib/python3.?/ or /usr/lib/python3.?/dist-packages/ instead - and autoconf/automake doesn't detect this. I haven't checked that many Linux distributions, but RHEL/CentOS and Fedora uses the site-packages directory - which autoconf/automake expects.

Quick fix:

# ln -sf /usr/lib/python3.?/site-packages/openvpn3 /usr/lib/python3.?/openvpn3

If someone is capable of figuring out the proper Python 3 install directory with autoconf/automake automatically so it works out-of-the-box across all distributions, I will happily review such patches.

As for a quick comparison:

On RHEL-7

 $ python3 -m site
 sys.path = [
     '/home/user',
     '/usr/lib64/python36.zip',
     '/usr/lib64/python3.6',
     '/usr/lib64/python3.6/lib-dynload',
     '/home/user/.local/lib/python3.6/site-packages',
     '/usr/lib64/python3.6/site-packages',
     '/usr/lib/python3.6/site-packages',
 ]

On Ubuntu 18.04 LTS

 $ python3 -m site
 sys.path = [
     '/home/user',
     '/usr/lib/python36.zip',
     '/usr/lib/python3.6',
     '/usr/lib/python3.6/lib-dynload',
     '/usr/local/lib/python3.6/dist-packages',
     '/usr/lib/python3/dist-packages',
 ]

[dsommers]

Since the Debian packages somehow manages to do this correct, we will not try to hack around this any further. Using dist-packages is a Debianism which we don't want to add additional hacks around just for that distro. And especially not when the Debian packaging tools seems to package the Python files correctly.