Experimental Python interpreter snap

[James Henstridge]

On 21 February 2017 at 23:37, Barry Warsaw <barry at ubuntu.com> wrote:
> On Feb 21, 2017, at 09:30 PM, James Henstridge wrote:
>
>>So we might be able to do a single package that can both serve as a
>>runtime for other snaps and as a useful Python development
>>environment.
>
> It would be interesting to see, but my tendency is to want separate
> interpreter environments for different purposes.  See my previous post re: a
> locked down system interpreter for /usr/bin scripts.
>
> The problem with one-size-fits-all (and we have this problem today with
> deb-based /usr/bin/python{2,3}) is that people sudo pip install all kinds of
> crazy things into their {site,dist}-packages, and that can break things, which
> are difficult to debug (though we're adding some useful features to 3.7 to
> help with that).


That's the thing: a confined app using the interpreter from my package
via the content interface is effectively going to get its own
environment.  It won't be searching for Python modules under /usr
because that's not where the Python installation comes from.  It won't
search for modules installed to ~/.local/lib/pythonX.Y because it
won't have permission to read that directory.

So even if we get it so "sudo pip install" works, it won't actually
have any impact on other snaps using the interpreter.

>
> So I think it makes some sense to separate these concerns: OS platform use,
> confined snap application use, developer playground.  Virtualenvs are the
> typical "Pythonic" way of doing that, but snaps provide another opportunity
> for confinement.
>
> (Of course "/usr/bin/python{,2,3}" is the long-established ui for that
> developer playground.)

Yep.  So I think it probably makes most sense for the Python runtime
snap to default to classic confinement so that it behaves as a user
would expect for interactive/development work, with pip ready to
install to ~/.local/lib/..., or to the system wide $SNAP_DATA folder
if the user really wants to install things system wide.  This would
seem to satisfy both use cases well.

James