Experimental Python interpreter snap

Barry Warsaw barry at ubuntu.com
Tue Feb 21 15:31:03 UTC 2017


On Feb 21, 2017, at 07:35 PM, James Henstridge wrote:

>It probably wouldn't be too difficult to build a snap tracking 3.7
>development, yeah.

Now that CPython development has moved to GitHub, I wonder if this isn't
something we could automate, with a mirror on Launchpad.

On Feb 21, 2017, at 07:53 PM, Stuart Bishop wrote:

On 21 February 2017 at 18:35, James Henstridge

>I think I was thinking that the main snap could use classic
>confinement, allowing you to use it as the interpreter for scripts
>located anywhere. And snaps using the interface would remain contained
>as they are. Assuming we are allowed to mix interfaces and classic
>confinement :)
>
>But now I think on it further, its probably not a good idea to pollute
>the main python snap when it is being used as a dependency.

An important feature would be allowing those other snaps which use the
interpreter snap to "install" extension modules.  Pure Python package are
generally no problem, but the shared libraries of extension modules have to be
compiled with the same flags as the interpreter they'll be dynamically loaded
into, and they are of course specific to the platform's architecture.

Something else that would be kind of cool to experiment, from a platform point
of view, is an idea many of us who work on various Linux distros have wanted
for a while: a Python interpreter for system operations separate from one for
general user consumption (i.e. developers and application administrators).
For the OS, we want an interpreter that's more locked down, that won't be
influenced by a user's $PATH, $PYTHONPATH, $PYTHONSTARTUP, or whatever stuff
someone might have randomly pip installed.

So I muse that if the safe system interpreter (not called /usr/bin/python3)
were a classic snap, with a locked down, but still extensible through third
party modules in a controlled way, then system scripts would use that
(e.g. /usr/bin/spython perhaps).  The regular /usr/bin/python3 then would be
more flexible for end users because they would know that they can't break
their system by messing with that interpreter's environment.  (Yes, they could
break their own apps, but caveat emptor).

Cheers,
-Barry




More information about the Snapcraft mailing list