38

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)?

antonio
  • 10,629
  • 13
  • 68
  • 136
  • As said above, there is no Tkinter in the embeddable Python. If you know how to, please, answer [here](http://stackoverflow.com/q/37710205/1851270). – antonio Jun 08 '16 at 18:30

1 Answers1

14

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.

In general though I recommend that ms-windows users install either Canopy or Anaconda because they come with most of the external modules that you'll be likely to need.

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.

Roland Smith
  • 42,427
  • 3
  • 64
  • 94
  • Thanks, this confirms that this _"distribution is (almost) fully isolated from the user’s system, including environment variables, system registry settings, and installed packages."_ My second point makes sense, then. – antonio Jun 04 '16 at 19:40
  • 3
    @antonio This answer is pretty much spot on (although I dunno about the Canopy or Anaconda endorsement). What maybe could be more clear is that virtualenv is used to isolate *installed packages*, while embeddable Python is used to isolate *the entire Python runtime*. You use virtualenv when you can share a runtime but not the installed packages (most web apps fall into this category) and embeddable Python when you don't want to share a global install (This makes sense for a lot of desktop apps.). From a development perspective, using the embeddable version is probably somewhat more trouble. – jpmc26 Jun 04 '16 at 20:24
  • @jpmc26: I see that they both use a distinct runtime for each environment. Or are you speaking about the virtualenv option [Using Virtualenv without bin/python](https://virtualenv.pypa.io/en/stable/userguide/#using-virtualenv-without-bin-python)? – antonio Jun 04 '16 at 21:38
  • +1 Good points. One last thing, please. Virtualenv is often used with virtualenvwrapper, which requires some bash like environment. Unfortunately [MSYS2](http://msys2.github.io/), which comes with a package system (Arch Linux pacman), installs a non-compatible Python, so Virtualenv/virtualenvwrapper does not work. A script downloading/extracting copies of the embeddable Python zip is therefore very convenient. After installing django in the embeddable Python, is it possible to require the same libraries on the server site and transfer the project like with Virtualenv? or is it again a pain? – antonio Jun 04 '16 at 22:15
  • @antonio I've never tried virtualenvwrapper. I usually have some kind of bootstrap script that other people can run to get going quickly, and setting up virtualenv and installing packages (including some unofficial wheels) is part of that. I don't really see the point of virtualenvwrapper. From the docs, it looks like it takes something that's meant to be *per project* and turns it into some kind of semi-global/user-scope thing, which feels like defeating the purpose to me. I say embeddable would be more trouble during development because you'd have to include it in that bootstrap script. – jpmc26 Jun 05 '16 at 04:50
  • So that said, if you don't actually *need* a fully isolated Python runtime, then you can just use the Windows install and have a per project virtualenv for package management. Plus there's the downside that the embeddable version doesn't include tkinter, which is a big downside if you're writing a desktop app. – jpmc26 Jun 05 '16 at 04:52
  • 1
    @jpmc26 The absence of tkinter puzzles me as well. Given the dual use for the embedded Python I'd hazard a guess that it is *mostly* meant for those who want to embed Python in their application. – Roland Smith Jun 05 '16 at 09:05
  • @jpmc26, @Roland Smith: Perhaps it should be noted that the MSI version of the installer (_easily scriptable_) has been removed. With the zipped version, it takes just a curl && unzip line to have a working Python and a curl && `python get-pip.py` to have it with pip. There should be some similar way for tkinter. – antonio Jun 05 '16 at 15:22