virtualenv is probably what you are looking for. See
A Virtual Environment is a tool to keep the dependencies required by different projects in separate places, by creating virtual Python environments for them. It solves the “Project X depends on version 1.x but, Project Y needs 4.x” dilemma, and keeps your global site-packages directory clean and manageable.
Install virtualenv via pip:
$ pip install virtualenv
Create a virtual environment for a project:
$ cd my_project_folder
$ virtualenv venv
virtualenv venv will create a
folder in the current directory which will contain the Python
executable files, and a copy of the pip library which you can use to
install other packages. The name of the virtual environment (in this
case, it was venv) can be anything; omitting the name will place the
files in the current directory instead.
This creates a copy of Python in whichever directory you ran the
command in, placing it in a folder named venv.
You can also use a Python interpreter of your choice.
$ virtualenv -p /usr/bin/python2.7 venv
This will use the Python
interpreter in /usr/bin/python2.7
To begin using the virtual environment, it needs to be activated:
$ source venv/bin/activate
The name of the current virtual environment
will now appear on the left of the prompt (e.g.
(venv)Your-Computer:your_project UserName$) to let you know that it’s
active. From now on, any package that you install using pip will be
placed in the venv folder, isolated from the global Python
Install packages as usual, for example:
$ pip install requests
If you are done working in the virtual
environment for the moment, you can deactivate it:
If you want to move your environment:
You can make a list of installed packages inside the virtualenv:
$ pip freeze > requirements.txt
And install them on the destination virtualenv using:
$ pip install -r requirements.txt
From my experience, virtualenvs can be created and managed for both python2 and python3 (on my system, I have both
Note that virtualenv does not itself provide the python interpreter. It allows you to create isolated environments where a python interpreter is already available.
IMHO, bundling python binaries into your script would not only make your package much bigger, it would in fact make your script less portable as the binaries would be compiled for the specific OS and glibc. If someone wanted to use the script on a different (linux) OS/architecture it would not be possible unless you provided a package for that version.