With the 3.5.0 release, Python.org has introduced a distribution billed as embeddable zip file.
Unfortunately the zipped file comes without a help file (not even a readme). The download page on Python.org just lists it among the downloads.
Apparently this is a portable Python distribution. It is anyway quite different in structure and size from the standard distribution using the installer.
I realised that it is possible to install pip with get-pip.py and, thanks to pip, it is a breeze to add many other application packages, though I am still unable to add Tkinter (adjust slashes according to your shell):
curl https://www.python.org/ftp/python/3.x.x/python-3.x.x-embed-amd64.zip > epython.zip
unzip -o epython.zip -d env1
curl -L https://bootstrap.pypa.io/get-pip.py>env1/get-pip.py
env1/python env1/get-pip.py
Add what you need, e.g django:
env1/python -m pip install django
Given the size (6.5 Mega for the 3.5.1-x64), I think that it can be convenient as a means to create isolated environments.
In fact the general Python documentation says that
the embedded distribution is (almost) fully isolated from the user’s system, including environment variables, system registry settings, and installed package
Given this, in Windows there are now two isolated Python environments, the second being the standard Virtualenv. The same process in Virtualenv is like follows:
virtualenv env2
and for django it would be:
env2/Scripts/python -m pip install django
Comparing the contents of env1
and env2
, they appear to have the same files. The only significant difference is Tkinter1, which is anyway not much significant for desktop apps.
Which is the difference between Python Virtualenv and Python embeddable?
Specifically, which is the difference between the isolated web app created with the embeddable zip (env1
) and Virtualenv (env2
)?
The embeddable package. New in version 3.5. The embedded distribution is a ZIP file containing a minimal Python environment. It is intended for acting as part of another application, rather than being directly accessed by end-users.
The executable installers provide the full Python Developer Kit; the embeddable package contains the runtime dependencies; nuget packages allow easy use of Python as a build tool; and site extensions for Azure App Service make it easier to manage Python as a web server dependency.
As you can see from the documentation, it is mainly meant for running Python based applications on ms-windows and for embedding Python in an application. As you can see, they left out tkinter
. Maybe to keep the size down?
Comparing it to a virtualenv doesn't make much sense, I think. They have completely different use cases.
In the ms-windows world, applications are generally distributed as monolithic independant entities. In contrast, basically every UNIX flavor has a working package management system which makes it easier to have packages that depend on others. So if you install a python-based app in UNIX, the package management system will basically install Python for you if it isn't installed yet. On ms-windows this doesn't work. Several Python distributions for ms-windows have sprung up because (for technical reasons) compiling and setting up stuff on ms-windows is painful [1] compared to UNIX. So having an embeddable Python could make sense for people who want to distribute Python-based programs or who want to embed Python into their application.
Edit As of 2020, the python.org
distribution has come a long way; you don't need a special compiler for it anymore, and more and more modules distribute precompiled binaries for ms-windows on PyPI. So my recommendation for ms-windows users has changed: use the python.org releases of Python.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With