[Distutils] zc.buildout and "System Python"

[Jim Fulton]

On Mon, Oct 25, 2010 at 4:53 AM, Eric Lemoine
<eric.lemoine at camptocamp.com> wrote:
> Hi
>
> I'm currently switching to zc.buildout 1.5. I've been looking at
> having a Python environment that is fully isolated from the main,
> system-wide Python environment.
>
> Can you confirm that zc.buildout 1.5 supports that?

That depends on what exactly "that" is. The easiest way to have "a
Python environment that is fully isolated from the main, system-wide
Python environment" is to have a separate build.

> Does this imply working with a "System Python"?

buildout 1.5 *tries* to coexist with system Python installations.

> The term "System Python" confuses me a bit, as what I want is an
> environment that is isolated from the system-wide Python environment?
> So could someone please explain what a "System Python" refers to
> exactly?

Maybe we should use a different term, but "System Python" is a
euphemism for a Python that has been packaged by an OS packager.  For
better or worse, these packagers tend to be innovative and deliver
Python installations that differ from a from-source build in
unpredictable ways.  This could involve additions, omissions, or
specialized build options.

Buildout 1.5 tries to coexist with system Pythons by hiding additions
in site-packages (or the innovative equivalent).  Virtualenv does
something similar.

I use the term "clean python" to refer to a Python installation based
on a straightforward build from source, and without any site-local
packages in it's site-packages directory. (Where straightforward is a
euphemism for a build after making sure that certain system libraries,
such as zlib, are available where Python can find them.)  We here at
ZC package these installs as RPMs that are available system wide along
side the "system Python". I tell all my friends to use clean Python's
for anything important.

> Also, the doc says: "Using a system Python is inherently fragile.

Yes.

> Using a clean, freshly-installed Python without customization in
> site-packages is more robust and repeatable". Does this mean using a
> "System Python" isn't recommended for production?

Yes. That's what it means.

> And how can use a
> "clean, freshly-installed Python"? What's a "clean, freshly-installed
> Python" anyway?

"freshly installed" is irrelevent, otherwise see above.

> Again, what I'm after is a Python environment that is fully isolated
> from the system-wide Python, just like virtualenv --no-site-packages
> provides?

The only way to get a Python that is fully isolated from another
Python install is to build one yourself from source.

Note:

- "System-wide" isn't really relevent.  What's important is a
  predictable install, which I choose to define as one you'd get from
  a source build, without special additions or omissions. You can have
  a clean Python that is installed system wide. Theoretically, system
  packages could provide clean Pythons, although I've never seen one.

  It occurs to me that it would be nice if we made clean Python
  packages available for some of the popular Unix platforms.  I'm not
  sure what would be involved in doing that, from a distribution point
  of view.

- "virtualenv --no-site-packages" doesn't give you complete isolation.
  In particular, it doesn't protect you from omissions.

Jim

--
Jim Fulton