<div dir="ltr">Hi James,<div><br></div><div>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:</div><div><br></div><div><a href="https://github.com/liu-xiao-guo/httpstat">https://github.com/liu-xiao-guo/httpstat</a><br></div><div><br></div><div>In the above example, I in fact do not package the python. It works.</div><div><br></div><div>Thanks & best regards,</div><div>XiaoGuo</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 20, 2017 at 10:16 AM, James Henstridge <span dir="ltr"><<a href="mailto:james.henstridge@canonical.com" target="_blank">james.henstridge@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To learn a bit more about I put together a snap for Python 3.6.0,<br>
which can be installed with:<br>
<br>
    snap install --edge python36-jamesh<br>
<br>
You can then run "python36-jamesh.python3", which will give you the a<br>
Python shell running with strict confinement, with the full standard<br>
library available.<br>
<br>
Now I know Snapcraft already has support for packaging Python<br>
applications, so what benefits does this package add?  There were a<br>
few extra points in how I built the package:<br>
<br>
1. the interpreter binary and extension modules all have appropriate<br>
$ORIGIN relative rpath set.<br>
<br>
2. a sitecustomize.py is provided that will add<br>
$SNAP/lib/python3.6/site-<wbr>packages to sys.path. (more on why this is<br>
useful later)<br>
<br>
This makes the interpreter fully relocatable in the file system while<br>
still being able to find the bundled libraries.  In turn, this means<br>
the interpreter is functional when exported to another snap via the<br>
content interface.<br>
<br>
To demonstrate this, I put together a trivial "hello world" snapcraft<br>
project here:<br>
<br>
<a href="https://github.com/jhenstridge/python-snap-pkg/tree/master/examples/hello-world" rel="noreferrer" target="_blank">https://github.com/<wbr>jhenstridge/python-snap-pkg/<wbr>tree/master/examples/hello-<wbr>world</a><br>
<br>
After building this package, it can be run after installing and<br>
connecting the interface:<br>
<br>
    $ snap install --dangerous hello-world_0.1_amd64.snap<br>
    hello-world 0.1 installed<br>
    $ snap connect hello-world:python3 python36-jamesh:python3<br>
    $ hello-world<br>
    Hello world!<br>
<br>
Since the hello-world snap doesn't actually include Python, it is<br>
quite light weight (4 kB, which I think is as small as a squashfs<br>
gets).  The space savings may not be that great with a single snap<br>
(the interpreter snap is almost 20MB), but the space savings increase<br>
as you install more snaps using the interface.  It also means that we<br>
could upgrade to Python 3.6.1 (when it comes out) without rebuilding<br>
this snap.<br>
<br>
And since the interpreter is being run under the hello-world snap's<br>
confinement policy, it can do potentially do things the main<br>
"python36-jamesh.python3" binary can't.  For example, if you add the<br>
"network" plug, you'll be able to access the network.<br>
<br>
And the sitecustomize script will also mean the interpreter can locate<br>
packages shipped in the plug snap.<br>
<br>
I'd be interested in any suggestions or feedback about the snap.<br>
<br>
Thanks,<br>
<br>
James.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Snapcraft mailing list<br>
<a href="mailto:Snapcraft@lists.snapcraft.io">Snapcraft@lists.snapcraft.io</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/snapcraft" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>mailman/listinfo/snapcraft</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">XiaoGuo, Liu </div></div></div></div>
</div>