proper way to start python ds in astor

# 2 years ago
ABence	I would like to know how to properly start python deviceServer in Astor? before I used a shell-script as launcher. now i use a python launcher. but one of my colleague was surprised that i use the shebang `#!/usr/bin/env` `#!/usr/bin/env /usr/Local/pyroot/PyTangoRoot/bin/pytango` instead of `#!/usr/bin/python` I don't know enough to know which is better? Your opinion ? example of one of my astor launcher `#!/usr/bin/env /usr/Local/pyroot/PyTangoRoot/bin/pytango # -- coding: utf-8 -- # PythonDS device server launch script import sys import os dir = os.path.dirname(__file__) print(dir) print(os.path.join(dir, 'BLM_manager')) sys.path.insert(0, os.path.join(dir, 'BLM_manager')) from DG_PY_BLM_Manager import main if __name__ == '__main__': main()`

# 2 years ago

I would like to know how to properly start python deviceServer in Astor?

before I used a shell-script as launcher.
now i use a python launcher.
but one of my colleague was surprised that i use the shebang

#!/usr/bin/env

#!/usr/bin/env /usr/Local/pyroot/PyTangoRoot/bin/pytango

instead of

#!/usr/bin/python

I don't know enough to know which is better?

Your opinion ?
example of one of my astor launcher

#!/usr/bin/env /usr/Local/pyroot/PyTangoRoot/bin/pytango
# -*- coding: utf-8 -*-
# PythonDS device server launch script
import sys
import os
dir = os.path.dirname(__file__)
print(dir)
print(os.path.join(dir, 'BLM_manager'))
sys.path.insert(0, os.path.join(dir, 'BLM_manager'))
from DG_PY_BLM_Manager import main
if __name__ == '__main__':
 main()

# 2 years ago
Anton	Hi ABence A short question, but it will need a long answer! General notes on scripts and shebangs: If you have Python script (or shell script) to launch your device server, the shebang matters if you run the script directly. For example, if the script was named MyDS, we could either run it directly or pass it as a parameter to a Python interpreter executable. Assuming we are in the same folder as the script, we can: 1. run it directly from the command line: ./MyDS instance 2. run it via a Python interpreter from the command line: /usr/bin/python3.6 ./MyDS instance If we want to run it directly the script also has to be marked executable. We could do that with a command like chmod +x MyDS. When we launch the script directly, the shell interpreter (e.g., bash) will look at the shebang to figure out what application is required to execute the file. If we had #!/usr/bin/python, then the result of ./MyDS instance is basically to run /usr/bin/python MyDS instance instead. If we run it via a Python interpreter, the shebang is ignored by Python. Using #!/usr/bin/env <command> in the shebang is common. The /usr/bin/env application will search the current PATH to find <command>, and then use that application (the first one it finds). This is useful if you work with virtual environments (e.g., venv, virtualenv, conda, etc.). In that case you might not want to use the version of Python linked to /usr/bin/python (and its related packages). Instead you want to use the Python version (and related packages) installed in the virtual environment that is currently active. If you had #!/usr/bin/env python this would work, since "activating" an environment typically adds its bin folder at the front of the PATH. If you had #!/usr/bin/python, your virtual environment would be ignored when running the script directly. Using /usr/bin/env with the absolute path to a command is a bit strange - there is no need to search the path. #!/usr/bin/env /my/bin/python is the same as #!/my/bin/python. In your example, you have /usr/Local/pyroot/PyTangoRoot/bin/pytango . I have no idea what the pytango application is you reference here. It would make more sense if it was /usr/Local/pyroot/PyTangoRoot/bin/python. Some notes on the applications involved here: Astor is just a graphical user interface to help configure and run device servers. If you are using Astor, your device server is actually run by another device server called Starter. Starter runs as a service on a specific host. Astor communicates with the Starter to request the status of the device servers and request starting, stopping, etc. The configuration is stored in the Tango Database, e.g., command line to use, which level to start instances at, which host to start them on, etc. https://tango-controls.readthedocs.io/en/latest/administration/deployment/starter.html Which shebang to use? Finally, to answer your main question. If you have PyTango, and all your other Python dependencies for the device server installed in the OS's system Python (so you probably used OS packaging tools like yum or apt), then you can use a shebang like #!/usr/bin/python. On older Linux distros this would probably point to Python 2.7. If you have installed your Python packages in a specific virtual environment, the you have two options: 1. if you activate the environment first, you could do: #!/usr/bin/env python 2. if you don't activate it (or don't have a chance to), then you would use the absolute path: #!/path/to/my/virtualenv/bin/python Since Starter is running as a service, it typically won't activate the virtual environment. You would need to use the absolute path. The obvious downside of absolute paths like this is that it requires you to always use the correct path when creating the virtual environments. Hope that helps. Regards, Anton

# 2 years ago

Anton

Hi ABence

A short question, but it will need a long answer!

General notes on scripts and shebangs:

If you have Python script (or shell script) to launch your device server, the shebang matters if you run the script directly. For example, if the script was named MyDS, we could either run it directly or pass it as a parameter to a Python interpreter executable.

Assuming we are in the same folder as the script, we can:

1. run it directly from the command line:

./MyDS instance

2. run it via a Python interpreter from the command line:

/usr/bin/python3.6 ./MyDS instance

If we want to run it directly the script also has to be marked executable. We could do that with a command like chmod +x MyDS.
When we launch the script directly, the shell interpreter (e.g., bash) will look at the shebang to figure out what application is required to execute the file. If we had #!/usr/bin/python, then the result of ./MyDS instance is basically to run /usr/bin/python MyDS instance instead.

If we run it via a Python interpreter, the shebang is ignored by Python.

Using #!/usr/bin/env <command> in the shebang is common. The /usr/bin/env application will search the current PATH to find <command>, and then use that application (the first one it finds). This is useful if you work with virtual environments (e.g., venv, virtualenv, conda, etc.). In that case you might not want to use the version of Python linked to /usr/bin/python (and its related packages). Instead you want to use the Python version (and related packages) installed in the virtual environment that is currently active. If you had #!/usr/bin/env python this would work, since "activating" an environment typically adds its bin folder at the front of the PATH. If you had #!/usr/bin/python, your virtual environment would be ignored when running the script directly.

Using /usr/bin/env with the absolute path to a command is a bit strange - there is no need to search the path. #!/usr/bin/env /my/bin/python is the same as #!/my/bin/python.

In your example, you have /usr/Local/pyroot/PyTangoRoot/bin/pytango . I have no idea what the pytango application is you reference here. It would make more sense if it was /usr/Local/pyroot/PyTangoRoot/bin/python.

Some notes on the applications involved here:

Astor is just a graphical user interface to help configure and run device servers. If you are using Astor, your device server is actually run by another device server called Starter. Starter runs as a service on a specific host. Astor communicates with the Starter to request the status of the device servers and request starting, stopping, etc. The configuration is stored in the Tango Database, e.g., command line to use, which level to start instances at, which host to start them on, etc.

https://tango-controls.readthedocs.io/en/latest/administration/deployment/starter.html

Which shebang to use?

Finally, to answer your main question.

If you have PyTango, and all your other Python dependencies for the device server installed in the OS's system Python (so you probably used OS packaging tools like yum or apt), then you can use a shebang like #!/usr/bin/python. On older Linux distros this would probably point to Python 2.7.

If you have installed your Python packages in a specific virtual environment, the you have two options:

1. if you activate the environment first, you could do:

#!/usr/bin/env python

2. if you don't activate it (or don't have a chance to), then you would use the absolute path:

#!/path/to/my/virtualenv/bin/python

Since Starter is running as a service, it typically won't activate the virtual environment. You would need to use the absolute path.

The obvious downside of absolute paths like this is that it requires you to always use the correct path when creating the virtual environments.

Hope that helps.

Regards,
Anton

# 1 year ago
Fałek	Hi all, this thread is old, but I want to add something from my experience. I'm using python entry points for creating scripts and then build rpm packages. In the end I've chosen #!/usr/bin/env python as default, because sometimes I had two versions of python on one machine (not even virtualenvs). With #!/usr/bin/python it only uses default OS python version. In case of direct path to interpreter, you need different configuration for each version. #!/usr/bin/env python helped to keep it working for any python interpreter and you have only one configuration for all projects without worrying to change to another python version in case of upgrade.

# 1 year ago

Fałek

Hi all,
this thread is old, but I want to add something from my experience.

I'm using python entry points for creating scripts and then build rpm packages. In the end I've chosen #!/usr/bin/env python as default, because sometimes I had two versions of python on one machine (not even virtualenvs).

With #!/usr/bin/python it only uses default OS python version.

In case of direct path to interpreter, you need different configuration for each version.

#!/usr/bin/env python helped to keep it working for any python interpreter and you have only one configuration for all projects without worrying to change to another python version in case of upgrade.