On 21 February 2017 at 16:57, Stuart Bishop <stuart.bis...@canonical.com> wrote: > On 20 February 2017 at 11:41, James Henstridge > <james.henstri...@canonical.com> wrote: >> On 20 February 2017 at 10:45, XiaoGuo Liu <xiaoguo....@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.bis...@canonical.com> > > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
