On 06/09/16 00:53, Mark Shuttleworth wrote:
There is a balance - the upside of having a "sandbox" /lib/ is that it
is *the same everywhere* even if your snap is running on openwrt.
But for this class of developer tool, snaps will be much more useful if
they can really integrate into the CLASSIC environment.
We'll get to this. My straw man proposal is an interface which
essentially makes "/classic/lib/" and "/classic/bin/" available to your
snap, so as long as your snap's $PATH is twisted appropriately it will
find things there. That's a proper bit of yoga on where snaps came from
and how we got them onto classic in the first place, but I think it has
merit as a starting point.
Yea, makes sense. It'll be fun to play with when it's ready :-)
There was an idea that occurred to me, which I'm not sure necessarily fits with
the snappy vision, but here goes. The metaphor for interfaces is plugs and
sockets -- which suggests one to one connections. But where things like
development libraries are concerned, one could imagine this more like posts on a
bulletin board: the individual services post their availability via a particular
board (in this case, the "development library" board), and snaps interested in
consuming a particular class of service can find out about and access all the
services of a particular kind by asking to read the associated board.
IOW instead of requesting access to one particular interface, snaps could
request access to collections of services, and other snaps could add individual
services to a given collection.
This could be an interesting way to make development libraries available without
relying on an underlying "classic" system.
On the other hand, snapping redis, rethinkdb and rqlite has gone really
smoothly :)
Nice! Congratulations :-)
--
Snapcraft mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
