Experimental Python interpreter snap

[Sergio Schvezov]

On Tue, 21 Feb 2017 19:53:31 +0700, Stuart Bishop wrote:
> On 21 February 2017 at 18:35, James Henstridge
> <james.henstridge at canonical.com> wrote:
>
>>> You could probably also get the pip in your snap to install packages
>>> to $SNAP_USER_DATA or $SNAP_DATA if run as root. Although most devs
>>> would stick to using virtualenvs outside of the snap for this,
>>> assuming a modern enough Python.
>>
>> With the snap as it stands, it is most useful as a runtime for other
>> snaps rather than for interactive use or for development.  If you
>> install my package with --devmode to disable confinement, it could be
>> useful for development, but there isn't really an opportunity for a
>> shared site-packages directory ($SNAP_DATA for the python snap won't
>> be accessible to other snaps).
>
> 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.

While I was fixing our python plugin in snapcraft (released in 2.27) to detect interpreters that might have been staged and reuse those (mostly to support classic confined snaps), Zygmunt was busy playing with python as classic confined snaps... not sure what the progress is with other versions, but `snap find` can take you back in time:

python0                      0.9.1       zygoon        classic  Ancient version of Python for programming archeologists

Some may call this duplication of effort, but I call it independent confirmation, we all took a similar path to enable this even though the final purpose may differ.

--