Python 3 does not get used by the script despite being installed

[rEes9P]

Describe the bug I've been running into the nzbToSickBeard: Python 2.7 is no longer supported. issue since January 1 like many others on the forum. However, what is interesting is that I do have Python3 installed on macOS 10.13 (via Homebrew) as recommended here.

While /usr/bin/env python --version shows Python 3.7.6 the script seems to still go to Python 2.7 for some reason. I can't for the life of me figure out why! Would greatly appreciate help in figuring this out.

Amending the first line of the nzbToMedia.py and nzbToSickBeard.py scripts from !/usr/bin/env python to !/usr/local/bin/python3 fixes the issue but I don't want to do this at I read somewhere that doing so breaks future auto-updates.

Additional information: python --version shows Python 3.7.6 which python points to /usr/local/opt/python/libexec/bin/python /usr/bin/env which python points to /usr/local/opt/python/libexec/bin/python /usr/bin/python --version points to Python 2.7.16 /usr/local/bin/python --version points to Python 2.7.16

I have inserted the Homebrew directory at the top of my PATH environment variable using export PATH="/usr/local/opt/python/libexec/bin:$PATH"

Technical Specs

1. Running on Mac
2. Python version 3.7.6
3. Download Client - NZBget
4. Intended Media Management - SickChill

Expected behavior I expected Python 3 to get called after installing it and the files to get post-processed without any issue.

[OneCDOnly]

@clinton-hall as nzbToMedia now won't run on Python 2.x, is there any reason the hashbangs for nzbToMedia can't be updated to point to Python 3?

Thank you.

[rEes9P]

as nzbToMedia now won't run on Python 2.x, is there any reason the hashbangs for nzbToMedia can't be updated to point to Python 3?

@OneCDOnly I am not very proficient with Terminal and am confused as to why the script points to Python 2.x even though on my system /usr/bin/env python --version shows Python 3.7.6. Could you please explain why this is happening? I've been tearing my hair out trying to figure it out! Thank you.

[OneCDOnly]

It will depend on how the Python binaries have been symlinked in each environment. For example, here's mine in Debian 10.2:

/usr/bin$ ll python*
lrwxrwxrwx 1 root root    7 Mar  5  2019 python -> python2
lrwxrwxrwx 1 root root    9 Mar  5  2019 python2 -> python2.7
-rwxr-xr-x 1 root root 3.6M Oct 11 08:02 python2.7
lrwxrwxrwx 1 root root   33 Oct 11 08:02 python2.7-config -> x86_64-linux-gnu-python2.7-config
lrwxrwxrwx 1 root root   16 Mar  5  2019 python2-config -> python2.7-config
lrwxrwxrwx 1 root root    9 Mar 26  2019 python3 -> python3.7
-rwxr-xr-x 2 root root 4.7M Apr  3  2019 python3.7
lrwxrwxrwx 1 root root   33 Apr  3  2019 python3.7-config -> x86_64-linux-gnu-python3.7-config
-rwxr-xr-x 2 root root 4.7M Apr  3  2019 python3.7m
lrwxrwxrwx 1 root root   34 Apr  3  2019 python3.7m-config -> x86_64-linux-gnu-python3.7m-config
lrwxrwxrwx 1 root root   16 Mar 26  2019 python3-config -> python3.7-config
lrwxrwxrwx 1 root root   10 Mar 26  2019 python3m -> python3.7m
lrwxrwxrwx 1 root root   17 Mar 26  2019 python3m-config -> python3.7m-config
lrwxrwxrwx 1 root root   14 Mar  5  2019 python-config -> python2-config

So, if I request python, I'll actually get Python v2.7.

But your environment may be different. If you have no Python 2.7 and only a Python 3.x, then your python may point to Python v3.x.

[OneCDOnly]

I saw earlier a PR has been submitted to address this: https://github.com/clinton-hall/nzbToMedia/pull/1691

[rEes9P]

Thanks @OneCDOnly. So, brew info python yields the following. Not sure if it is helpful to identify whether my Python binaries are linked as necessitated but I did run brew link python3.

==> Caveats Python has been installed as /usr/local/bin/python3

Unversioned symlinks python, python-config, pip etc. pointing to python3, python3-config, pip3 etc., respectively, have been installed into /usr/local/opt/python/libexec/bin

[OneCDOnly]

The important thing people are asking for is that as nzbToMedia will (understandably) no-longer accept Python 2, it shouldn't be requesting the default Python as determined by the OS.

It should instead explicitly request Python 3.x via #!/usr/bin/env python3

edit: apologies to the dev, that wasn't meant to sound like a demand. :smile:

[rEes9P]

So, I tried fiddling about and changing to first line to !/usr/bin/env python3 but that didn't work for me. Changing it to !/usr/local/bin/python3 did but I don't want to do so to break auto-updates. 🤷‍♂️

[OneCDOnly]

This is sounding more like an issue with the environment brew creates. :disappointed:

[rEes9P]

Ah! I hope @clinton-hall can shed some light on what can be done. Thanks for all your help @OneCDOnly.

[OneCDOnly]

BTW: for some reason, I went cross-eyed and thought I was chatting with Clinton... :laughing:

Yes, let's hope Clinton comes to the rescue again.

[rEes9P]

Hahahaha. Sorry to disappoint you! I am not the venerable @clinton-hall

[clinton-hall]

sorry for the delay... I was going to review python2 before new year.... but Christmas happened. Then my son and I went hiking for a few days and wow... it's 2020 and the script no-longer works with python2!

There are 2 pull requests that have been sent that change the she-bang to python3. The main issue I have is that previously I specified calling python2 (since calling python didn't work for systems where python3 was the default) and that caused major problems for many 3rd party systems, NAS, and busybox etc.

you can actually see in these pull requests that they fail all checks done using azure CI (basically the default image there doesn't recognize python3).

There are also other issues here... SABnzbd defaults to call all .py scripts with python2.7 (unless you are on a python3 versions of SABnzbd). On NZBget you can use the shell override to call a specific python versions (so if you have set this previously to call python2 then this will always be the case).

I think the easiest "fix" might be to edit eol.py so that it prints a warning to say it is no longer officially supported, but otherwise still continue.

[clinton-hall]

lol... ignore my comment about azure CI... that failure was related to ffmpeg! but I have found some examples of systems where python3 doesn't exist although it should! for now, python2.7 will continue to run...

[Anakim]

hy @clinton-hall is still have the same problem on my omv nas and docker containers like sabnzbd. I'm waiting for the solution ..

I have now adjusted the eol.py first ..

thanks

[mannibis]

I have also tried changing the shebang to "#!/usr/bin/env python3" but NZBGet still called python2. I am running NZBGet in a docker container. Thankfully the folks over at linuxserver.io added python3 to their container so python3 does exist on the system and "usr/bin/env python3" does give me python3 in a terminal. NZBGet's shelloverride option right now is ".py=/usr/bin/python; .py3=/usr/bin/python3" but if I change nzbToSickbeard.py to nzbToSickbeard.py3, all of the environmental variables within NZBGet for the script get wiped out, so I left the extension as py3. The last thing to try would be to change the shelloverride to ".py=/usr/bin/python3", but that may break all my other custom python scripts that haven't been converted to python3 yet. I will wait for a better solution as well.

On another note, my logs now contain a hundred of these INFO outputs from nzbToSickbeard: "nzbToSickBeard: Trying to intuit the encoding" Not sure what that means, but I still get the EOL warning. The script, however, runs and completes successfully.

[clinton-hall]

@Anakim You will need to revert any changes you have made and update to the latest version. This should then work as wanted.

git reset --hard
git pull

[clinton-hall]

@mannibis I have suppressed the intuit logging in latest nightly... to be honest, I think the whole char_replace code needs to be removed for python3.

[rEes9P]

@clinton-hall I tried post-processing again on NZBGet on macOS but it didn’t work. Do I need to amend the eol.py manually or update to the latest version manually via a hard git reset? Would the latter reset all preferences? Thanks for your help.

[clinton-hall]

you don't need to edit anything.. in-fact you want to remove all manual edits (git reset --hard) as suggested above and update to the latest (git pull).

the reset will not reset any preferences.

[Anakim]

@Anakim You will need to revert any changes you have made and update to the latest version. This should then work as wanted.

git reset --hard
git pull

it works !! thank you for your help and time

[gibxxi]

For me, on QNAP, I used WinSCP to edit the symlink target in the "/opt/bin/python" symbolic link (right-click -> Edit Link or select file and hit ALT+F6) to point to python3.8.

Only caveat to this is, every time you upgrade firmware on the NAS, you'll probably have to redo the mod.

Also, to get Python 3 you'll probably need to install the 3rd Party Python 3 addon from QNAPClub, located here: https://qnapclub.eu/en/qpkg/261

[mgaulton]

So maybe i'm running into something weird but I just noticed that /usr/bin/python3 -OO /opt/sabnzbd/SABnzbd.py -f /opt/.sabnzbd/sabnzbd.ini is calling python /opt/Sick-Beard/autoProcessTV/nzbToMedia.py

This is using latest git pulls from both app repos.

server6:~ # python -V Python 2.7.18 server6:~ # python3 -V Python 3.8.5

[gibxxi]

I'm going to guess that your using a NAS device, and that the "python" command is actually a symbolic link. In this case, you will need to change / edit the "python" symbolic link to point at the Python 3 executable, rather than the Python 2.7.18 binary.

This can be achieved fairly easily with WinSCP.

Using a SSH session, you need to find where the "python" symbolic link is located, (It is likely that it will reside in the same folder as the Pythion 2.7.18 and Python 3 executables). Right click on it, and and select "Edit Link". Then replace the path to the Python 2.7.18 executable with the path to the Python 3 executable. Then, whenever an app uses the generic "python" command, it will invoke running Python 3, not Python 2.7.18.

[clinton-hall]

yeah, this is a funny one. Originally SABnzbd would call all .py scripts with python 2.7 (the python that was running SAB) and ignoring the hashbang in the script and ignoring the PATH.

Once SAB was updated to use Python3 it appears they now execute the script using the HashBang.

As above, you can either edit the symlinks so that python actually points to python3. Alternatively you may be able to edit the init/start-stop script for SABnzbd and add another directory (e.g. /usr/local/bin) at the front of the PATH variable. In that location, make sure python is python3

e.g. ln -sf /usr/bin/python3 /usr/local/bin/python (creates the symlink in /usr/local/bin)

Then edit the start script for SABnzbd and insert export PATH=/usr/local/bin:$PATH near the top and edit the command that launces SABnzbd to use python (not /usr/bin/python3) python -OO /opt/sabnzbd/SABnzbd.py -f /opt/.sabnzbd/sabnzbd.ini

[mgaulton]

My bad, this is on an OpenSuse tumbleweed system.

[mgaulton]

My method for starting is a little complicated so trying the below. I use a systemd unit to start SAB, within a linux namespace where the vpn connection lives :) Since I'm running SAB from a systemd unit, I went with the suggested here https://unix.stackexchange.com/questions/347873/set-path-for-a-systemd-unit

ExecStart=/bin/bash -c 'PATH=/new/path:$PATH exec /bin/mycmd arg1 arg2'

[clinton-hall]

So in theory, as long as /new/path as per your command above, has a python executable or link that is python3... then SAB should be calling nzbToMedia to run using python3.

[mgaulton]

I soft linked python3 to python in /usr/local/bin and added that to the path for the systemd unit.

On Tue, Nov 3, 2020 at 7:31 PM Clinton Hall [email protected] wrote:

So in theory, as long as /new/path as per your command above, has a python executable or link that is python3... then SAB should be calling nzbToMedia to run using python3.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/clinton-hall/nzbToMedia/issues/1692#issuecomment-721446588, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEJRXVNK6RKPTR6IJN6OPDSOCOGPANCNFSM4KCRUPDA .