Develop Reference

How to grant access to virtual environment to other users on CentOS server

I used this tutorial (rec by GoDaddy because I have a GoDaddy VPS)
https://www.godaddy.com/garage/how-to-install-and-configure-python-on-a-hosted-server/
to install a secondary version of Python (3.6.6) and create a Virtual Environment to run modules with the secondary version of Python. I want to be able to run scripts in the virtual environment but do not want to always use the admin account to do this. I have one other account set up that does not have admin privileges. Is there a way to extend authority to more than the admin account that created it? Do I need to do a virtual environment on every user account that is going to have access to run python?
It says to add a line to the bash_profile script. The script already had this:
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin
export PATH
This makes sense in that it seems to be defining the location of underlying Python (i.e., 2.6.6). I have modules in a venv that require 3.4+ so I created the virtual environment. I want to be able to call the script from Chrome and run it for some scripts and run it from cronjob for other scripts and the scripts need to always point to the virtualenv to use that installed interpreter. I have no idea how to do this correctly. Here's my system information and the results of some SSH printouts:
$ cd $PATH
-bash: cd: /home/flohosti/.local/bin:/home/flohosti/perl5/bin:/usr/local/cpanel/3rdparty/lib/path-bin:/usr/local/cpanel/3rdparty/lib/path-bin:/usr/local/cpanel/3rdparty/lib/path-bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/cpanel/composer/bin: No such file or directory
Before going into the VirtualEnv I run which python and get /usr/bin/python which I expected.

There are multiple ways to do that.
You can simply give read access to the directory where virtual environment is installed and then export its path in /etc/profile so that its automatically added to every users path.
Or you can give access to python binary inside the virtual env folder.
That being said this isn't the right way to go about it, most of the times you would want to have virtual environment inside your projet folder so that it is automatically available the project and who so ever has access to that project.
Edit 1
So the answer to your comment
Yes absolutely you can use the same virtual env to execute script in cron but you have to give absolute path to virtaul environment and your script in cron, like /home/flohosti/projectOne/env/bin/python <script path> or you can just set the PATH in cron and then you can use relative path as well.

Add relative paths to configuration file virtualenv_path_extensions.pth

I'm attempting to find a set of steps necessary to make a virtual environment of python 3.6 on windows relocatable.
1st I created a virtual environment on virtualenv 15.1.0 with the following command:
virtualenv
--always-copy
-a "path\to\project\dir"
-r "path\to\requirements.txt"
venv_name
After this, I run the following command to use the built in 'make paths relative ' functionality of virtualenv:
virtualenv --relocatable venv_name
Part of my requirements.txt is pypiwin32 library which, at least when installed via pip, wont work until the:
python Scripts/pywin32_postinstall.py -install
script is run (See here for details).
At this point, if I search the venv directory for clues of hardcoding, I see them in scripts\activate.bat, which I can make relative by changing this:
set "VIRTUAL_ENV=C:\path\to\venv"
into this:
pushd %~dp0..
set VIRTUAL_ENV=%CD%
popd
There are some other other places where I had to make slight adjustments to make them relative (I used the search in folder feature of sublime with my username as the search parameter - it brought up all the path\to\username\then\some\more style lines in the directory.
There are 2 hardcoded paths which are not so simple:
1. "path\to\venv\Lib\orig-prefix.txt"
I understand that orig-prefix.txt is a record of which is the source python installation on which the venv was based and so cannot really be relative but may need to be left blank if moving the venv to another machine (it's absence may crash the python launcher but its emptiness is fine.)
2. "path\to\venv\Lib\site-packages\virtualenv_path_extensions.pth"
This is trickier. As it is a hard-coded path which is then added to sys.path as a location to look for modules, when I move the venv to another machine where this path doesn't exist, the module load will fail.
Is there a way I can add relative paths to the configuration files such as virtualenv_path_extensions.pth

Normally environments are tied to a specific path. That means that you cannot move an environment around or copy it to another computer. You can fix up an environment to make it relocatable with the command:
$ virtualenv --relocatable ENV
This will make some of the files created by setuptools use relative paths, and will change all the scripts to use activate_this.py instead of using the location of the Python interpreter to select the environment.
Note: scripts which have been made relocatable will only work if the virtualenv is activated, specifically the python executable from the virtualenv must be the first one on the system PATH. Also note that the activate scripts are not currently made relocatable by virtualenv --relocatable.
Note: you must run this after you’ve installed any packages into the environment. If you make an environment relocatable, then install a new package, you must run virtualenv --relocatable again.
Also, this does not make your packages cross-platform. You can move the directory around, but it can only be used on other similar computers. Some known environmental differences that can cause incompatibilities: a different version of Python, when one platform uses UCS2 for its internal unicode representation and another uses UCS4 (a compile-time option), obvious platform changes like Windows vs. Linux, or Intel vs. ARM, and if you have libraries that bind to C libraries on the system, if those C libraries are located somewhere different (either different versions, or a different filesystem layout).

How to customise a virtual environment in Python correctly?

I have to develop software with the use of several programs together, like Python 3.6 (with specific packages), WKHtmlToPdf and an embedded browser (based on CEF). I should be able to share all this together in one directory, so with a virutal environment of Python 3.6...
My question to you all is: how can I make the paths of a Python virtual env relative.
A second question I have is: is it possible to just activate the virtual env without changing cmd prompts and things? I tried to write a batch file which 1) starts the environment, 2) executes a Py script and 3) runs the embedded browser. That batch file failed after it started the virtual environment...

I should be able to share all this together in one directory, so with a virtual environment
Virtual environments are not portable (they must reside in the same directory on a computer where exist global Python), hence you cannot share a virtual environment.
My question to you all is: how can I make the paths of a Python virtual env relative.
No, and you certainly don't need to do it.
A second question I have is: is it possible to just activate the virtual env without changing cmd prompts
Yes, it's regulated in bin/activate script which you can edit to your taste.
and things?
What "things"? Activating virtual environment means changing PATH, PYTHONPATH and so on, you certainly cannot use virtual environment without changing these and other things.
That batch file failed
If you want us to help you should show us the essential parts of the batch and in what way it failed.
May be you need a different solution like a Docker image. Docker can be installed on Windows though it must be installed on the target computers.
There are also simpler solutions: py2exe, PyInstaller, cx_Freeze. They "compile" python scripts to .exe and accompany that .exe with Python interpreter (in a .dll) and library (in a .zip file). But if your program needs more DLLs you have to copy them to the target computer.
You can also take a look at RVirtualEnv. It allows to create relocatable virtual environments. I don't know if such envs can be copied to a different host, though.

python virtualenv -- possible to augment $PATH or add other environment variables?

I'd like to alter my $PATH only in a Python virtual environment. Is it possible to have the $PATH change when I activate a virtual environment?

You can write an activation script that sources virtualenv's activate (on linux, or calls the bat file on windows) and then updates PATH, PYTHONPATH and other environment variables. Use the virtualenv bootstrap hooks to install the script when the virtualenv is created and call it instead of activate.

Depending on what operating system you are using you could edit the activate file and set an environment variable there. For example, a Windows virtualenv folder has a sub-folder called Scripts. Inside scripts is the activate.bat file. Edit activate.bat and alter the path variable. One thing to consider though, is you might want to save the original path variable in another temporary environment variable and restore from that temporary environment variable in the deactivate.bat file.

Virtual Environments with Python

Hi I've been reading a lot about virtual environments but I don't seem to get one thing.
So I have my path like this:
../my_app/
../my_app/app.py
..etc
Where should I put the virtual environment?
Inside my_appas /my_app/venv/bin,include,lib?
or at the same level as my_app
/my_app/
/venv/
I don't understand if the location matters or if by using activate it will reference it instead of going to the main environment.
I hope this question makes sense.
Thanks!

I recommend utilizing the root directory which virtualenv creates as the root directory for your source files. Virtual-envirments are designed to be tied to a project, not shared between different projects. Example, lets say I write a lot of code in my ~/school directory. I'd cd to ~/school, do virtualenv ENV. Now I have an ENV directory in which to keep my source files and dependencies for the project. So you can create a ~/school/ENV/source folder in which to keep all your source folders. And all your virtual-environment files are close to your program, easily accessible in the ENV directory.
EDIT:
To address one part of your question: As long as you keep track of your environment, and you source bin/activate before running your python programs and installing dependencies with pip, you can install your virtual environment anywhere.

I don't understand if the location matters or if by using activate it
will reference it instead of going to the main environment.
It doesn't matter, as activate will take care of the paths correctly, but you shouldn't put your virtual environment in your source, as it is not part of your application (and its not portable). Instead, create a file with your requirements and put that under your source control.
You should put it in any directory other than your source code. The activate script will make sure the paths point to the right places.
Here is an example:
$ virtualenv /home/somedir/envs/myenv
... # some output
$ source /home/somedir/envs/myenv/bin/activate
(myenv) $ mkdir /home/somedir/projects
(myenv) $ cd /home/somedir/projects
(myenv) projects $
As you can see, the virtual environment is in the envs directory and is called myenv. Your source is in /home/somedir/projects. Type deactivate to exit your virtual environment.