run my script in a spefic version or any later one

[Skaperen]

in a POSIX system (i'm using Xubuntu 18.04 LTS) i can choose whether my script runs on python2 or python3 at the first line ... the #! line. i can even specify a specific minor version such as python3.6. how can i designate it to run on "Python 3.6 or later" so that on a system with only 3.7 it will run under 3.7?

[Gribouillis]

On my system, /usr/bin/python3 is a symlink to the installed version of python 3. Why not use this link?

[Skaperen]

if you have a system with 3.5 as the standard (such as Ubuntu 16.04 LTS) and have installed 3.8 from source then that symlink would still point to 3.5 in which case my script needs to use 3.8 (3.5 does not support f-strings). i don't know if changing the symlink would still work for the system scripts. some are in Python. if they work in 3.5 i'd think they'd work in 3.8 but i can't be 100% confident.

[Gribouillis]

You could create your own symlink, for example /usr/local/bin/bestpython3 or ${HOME}/.local/bin/bestpython3 pointing to the python3.8 executable and use this symlink on the shebang line.

[Skaperen]

is that the name every system with 3.6 or 3.7 or 3.8 will have and every system with an earlier python will not have. since my script with f-strings fails to even compile on 3.5 or earlier, i can't run tests for version control, which i previously did a lot.

i have a snippet of code i sometimes insert into the beginning of scripts that checks for the minimum version needed and looks around for a usable version and reruns itself with that engine. but that is not usable when there is a compile failure. if that snippet could not find a usable engine it would tell the user why it cannot run and suggest installing a version that is usable.

i need to get a cloud instance going with 3.8.0 for testing.

---

what i have been thinking is that a series of special symlinks be added or replaced by each minor version install to point to the best compatible version that is installed. these would have a different name like /usr/bin/python-compat3.6 and point to the best that can run scripts made to work on 3.6. the installation of any version would add or replace all the appropriate symlinks to point to itself. so a script than would fail in 3.3 or earlier would refer to /usr/bin/python-compat3.4 which might point to python3.8.0.

[Gribouillis]

i have a snippet of code i sometimes insert into the beginning of scripts that checks for the minimum version needed and looks around for a usable version and reruns itself with that engine.

In an old python2 project, I used a custom interpreter and my shebang line was #!/usr/local/bin/chathon. This file was a symlink to a file named chathon.py which would select a python interpreter known as ~/.chabei-apps/chabeibox/bin/python, create a custom environment and launch a subprocess with this interpreter and the correct input, output and error streams.

Such a scheme would work in your case because the chathon command was called before the program's syntaxic analysis. Here is the program chathon.py exactly how it was in this project, you can try and adapt it to your case

#!/usr/bin/env python
# -*-coding: utf8-*-
'''doc
'''
from __future__ import (absolute_import, division,
                        print_function, unicode_literals)
import os
import subprocess as sp
import sys
pjoin = os.path.join

def chabeibox(*args):
    return pjoin(os.path.expanduser('~'), '.chabei-apps', 'chabeibox', *args)

class main(object):
    def __call__(self):
        chapython = chabeibox('bin', 'python')
        env = dict(os.environ)
        env['PYTHONPATH'] = ''
        self.nettoie_path(env)
        i, o, e = range(3)
        proc = sp.Popen([chapython] + sys.argv[1:], stdin=i, stdout=o, stderr=e, env=env)
        proc.wait()

    def nettoie_path(self, env):
        L = [x for x in env['PATH'].split(':') if x.startswith(('/usr/', '/bin', '/sbin')) and 'bin' in x]
        L[0:0] = [chabeibox('bin')]
        env['PATH'] =  ':'.join(L)

if __name__ == '__main__':
    main()()

[snippsat]

I do no like this approach of finding a Python version and install for User,the more normal way is to set a minimum required Python version.
Then user is free to install for all newer version over minimum required Python version.
Also a lot people also use pyenv(me always) then Python will be in a other place.

tom@tom:~$ which python
/home/tom/.pyenv/shims/python
tom@tom:~$ python -V
Python 3.7.3

tom@tom:~$ pyenv global 3.8.0
tom@tom:~$ which python
/home/tom/.pyenv/shims/python
tom@tom:~$ python -V
Python 3.8.0

If use black as example so do it requires Python 3.6.0+.
In setup.py

assert sys.version_info >= (3, 6, 0), "black requires Python 3.6+"
python_requires=">=3.6",

User is free to install in all newer version than 3.6-->
If try to install to 3.5 this happens,will not install.

λ py -3.5 -m pip install black
Collecting black
  Could not find a version that satisfies the requirement black (from versions: )
No matching distribution found for black

Eg install to 3.8 on Linux.

tom@tom:~$ pip -V
pip 19.2.3 from /home/tom/.pyenv/versions/3.8.0/lib/python3.8/site-packages/pip (python 3.8)

tom@tom:~$ pip install black
Collecting 
Download ....
Installing collected packages: click, appdirs, toml, attrs, black
Successfully installed appdirs-1.4.3 attrs-19.3.0 black-19.3b0 click-7.0 toml-0.10.0

My guess is that you don't use Python ecosystem like (pip, setup.py, Wheel, PyPi),but make you own stuff

[Skaperen]

i have a snippet of code i sometimes insert into the beginning of scripts that checks for the minimum version needed and looks around for a usable version and reruns itself with that engine.

In an old python2 project, I used a custom interpreter and my shebang line was #!/usr/local/bin/chathon. This file was a symlink to a file named chathon.py which would select a python interpreter known as ~/.chabei-apps/chabeibox/bin/python, create a custom environment and launch a subprocess with this interpreter and the correct input, output and error streams.

i remember dabbling around with some code like that. it should work. the problem is that the end user would have to install that setup before it could be used. what i would want is to do that on systems where no such effort had been made. it's too late to work in existing systems by installing a single file. but, if the setup of symlinks will include the symlinks for "this version or later" from now on, future cases can be handled. i want to handle situations where the sysadmin is behind because that is where the warning is needed.

i don't know if it is python itself or the OS packaging that sets up these symlinks. but there is generally an OS package for each minor version of python. the scheme i envision would be done there.

the name i am thinking of now for the symlinks is like /usr/bin/python3.3+ -> python3.8 (chaining through /usr/bin/python3.8 -> python3.8.0). if 3.8.0 gets removed, that symlink is also removed unless any higher version is present in which case the symlink is replaced to point there.

---

I do no like this approach of finding a Python version and install for User,the more normal way is to set a minimum required Python version.

then how do i notify the user about the version issue?

My guess is that you don't use Python ecosystem like (pip, setup.py, Wheel, PyPi),but make you own stuff

i do make my own stuff because in the past it was my common practice to do that because i needed stuff before generally available stuff became available. so i got into that habit and developed such skills. now with python, i don't need to since so much is already available. but it's still difficult because there is so much. i do search pip but usually find too much. i have tried stuff and often gotten junk or something entirely unexpected. it is rare to find gems, though it has happened.

now i have the opposite problem, too many things to choose from. i need to test so many things to find something i can use. i end up making my own stuff because i need something sooner than i can find something else.

i do use python ecosystem where i know about it.

one issue is that many of my scripts need to work where many common things, even things i actually use, are just not available, or not done right. for example, today, i don't even try to support python2. it has been over 10 years since python3 was released (2008-12-03). anyone not at least having it available, shame on them (will /usr/bin/python -> python3 next year?).

it would be nice to see an uncluttered document that indexes through the best of the ecosystem. it should not present every possible thing in each category unless it at least describes the best one or at least best few. i know that would be a lot of work by someone. but it would also have great value. for stuff with APIs, it should describe the general approach of the APIs, such as if it uses callbacks. a list of its abstractions can help.

after 2019-12-31, at least, things could be a lot easier. we can pretend python2 is not there.

[wavic]

After all, you always can make it single executable so no installation of anything to be needed.

I can't see now because I am on Windows system at this time, but I think you can point the exact version in the shebang line.

#/usr/bin/env python3.6

In combination with the version assertion @snippsat proposed.

[Skaperen]

so which exact version should i point to ... 3.6, 3.7, or 3.8?