On 21 February 2017 at 20:53, Stuart Bishop <stuart.bis...@canonical.com> wrote: > On 21 February 2017 at 18:35, James Henstridge > <james.henstri...@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 :)
As I understand it, this should be fine: when you connect two snaps with the content interface, all it does is bind mounts a directory from the slot-side snap to a mount point within the plug-side snap. It shouldn't matter what confinement policies the two snaps are using. And since the snap data is a read-only squashfs, neither side can alter the content that is being shared. > 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. Well, it should be pretty easy to detect whether we're running in the context of the Python snap: checking if sys.prefix is equal to $SNAP would probably be enough (from a different snap, the interpreter will be mounted somewhere else). It wouldn't be difficult to add extra directories to sys.path in this case, and with confinement disabled I suspect we'd pick up the standard "user site" directory automatically. 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. James. -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
