Experimental Python interpreter snap

[James Henstridge]

On 21 February 2017 at 16:57, Stuart Bishop <stuart.bishop at canonical.com> wrote:
> On 20 February 2017 at 11:41, James Henstridge
> <james.henstridge at canonical.com> wrote:
>> On 20 February 2017 at 10:45, XiaoGuo Liu <xiaoguo.liu at canonical.com> wrote:
>>> Hi James,
>>>
>>> Nice. This is a nice example showing how to reduce a python snap package.  A
>>> few days ago, I also made a small example to make use of the python3 coming
>>> with the core at:
>>>
>>> https://github.com/liu-xiao-guo/httpstat
>>>
>>> In the above example, I in fact do not package the python. It works.
>>
>> So I guess the main differences are that this makes it easy to use a
>> newer version of Python than existed at the time Xenial was released.
>> I suspect I could also build a Python 2.7 snap using the same
>> techniques, if you want to go in the other direction.
>
> Yes. I love the idea of being able to use 3.6 or 3.7, and not have to
> rebuild and release my snaps every time there is a point release.
>
> I also like the idea of having easy access to nightly builds of the
> development branch, and antique versions. I think having old versions
> packaged  in snaps is nicer than the current approach of  the
> deadsnakes ppa.

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


>> The Python in my snap is also set up to automatically use packages
>> included in your own snap without fiddling with environment variables
>> or sys.path.
>
> 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).

And if you are trying to package up a Python app that will be running
under snap confinement, do you want writable locations in the default
sys.path?

Maybe there is room for some compromise: we could enable a
site-packages dir in $SNAP_DATA/$SNAP_USER_DATA when running the
interpreter under the python snap's context, but not when running
under a different package's confinement.

James.

>
> --
> Stuart Bishop <stuart.bishop at canonical.com>
>
> --
> Snapcraft mailing list
> Snapcraft at lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft