As I understand snap is conceptually usable as general purpose packaging tool like conda, besides the fact it’s linux specific. Let’s suppose all snaps come from the same store (let it be a community managed set of recipes). Is it true i.e. can it be used say as a replacement for conda in this case?
I understand having snaps as dependencies is not implemented. If it will be, will it be done by copying the read-only snap data that is depended on or by adding permissions?
Does it make sense to add a permission for snaps to access a list of snaps or all snaps from a given store?
It depends on the way you look at it. Conda manages an environment where it pulls down pre-defined bundles that need to have been prepared to work with each other, and it then allows you to use and share those environments. It doesn’t allow an environment to depend on each other, though.
That’s exactly what we have with snaps. Conda’s packages are snapcraft parts, and Conda’s environments are snaps. There’s a rich language and ecosystem around snapcraft parts already, and they can be bundled together to form a usable environment inside the snap. You then share the snap, which is the working and blessed environment with pretty rich semantics.
We even have some ways to have dependencies across snaps already with interfaces. These need to be carefully designed, though, because we want to encourage an ecosystem that works despite people not having to coordinate every single update to avoid breaking each other’s snaps. Other sorts of dependencies will likely be included in the future, but again it needs to be done very carefully to not break that invariant.
Thanks for your reply. What I meant is can a snap provide a functionality equivalent to a conda package not environment. I mean bundling the env together in a snap is good but even docker containers often need to reference each other (using for example docker-compose). Do I understand correctly that despite the isolation of container it has access to other snaps from the same publisher?
@elopio I understand conda can and maybe will be a snapcraft plugin but I used it just as an example of a general purpose package manager
As mentioned above, the behavior of a conda package resembles very closely that of a snapcraft part, both in semantics and intended outcome. So the question being asked ends up being similar to “can a snap behave like a snapcraft part”, for which the answer would be no, because they really work in different phases of the process and have different intended outcomes. We can dig further into this if it remains unclear.
That said, again, snaps can depend on each other via interfaces. The behavior you mention of a snap being able to access data from another one from the same publisher is referring to the content interface specifically.
In terms of Docker, images can’t actually depend on each other. They can be composed instead, and Docker Composer is a tool that may be used to organize that. You can do the same thing with snaps.
In terms of docker afaik one container can assume that there will be another running one that will allow it access it’s certain port. Assuming that installed snaps provide binaries that can just be called my question is what the snaps confinement does allow and what not and how can we grant in a generic way one snap access to other snap binaries
I don’t think you can make a Docker image declare a dependency on a different image like we can with deb and rpm packages. That’s what we generally mean when we say that a package has a dependency on a different package. What one may do is to make a Docker image that attempts to talk to a given port on the system, and expect something to make that port available in a suitable software via Docker Composer or similar. That’s composition.
With snaps you can both compose in that latter sense, and may also declare explicit dependencies via interfaces which allow the snaps to be directly connected to each other. Each interface offers certain level of access into another snap or into the system (via the core snap). The content interface is the one that allows looking into another snap’s files.
We have some good documentation on the content interface but it’s currently sitting in the old wiki. I will copy it over into a topic in the forum and link it here shortly.
Thank you. I read about the content interface that it’s auto-connected for the snaps from the same publisher. Does it mean snaps from the same publisher can use each other files freely? If yes, how flexible is it? Is it conceptually possible to allow one publisher use snap files of another publisher but request some kind of permission? In a generic way so that not to write an interface for every single case
My problem(conjure-up) is we want to rely on things like LXD/Juju snaps without having to build them directly into our snap. It was mentioned to have some sort of YAML that can be used between snapd and the snapstore to define what dependencies are required for a particular snap. It would also be nice to have a ‘recommends’ of sorts for things like LXD which isn’t a hard requirement for conjure-up but most people would find very useful to have.
I wanted to kick off this discussion in hopes of getting something formulated so that it can be proposed as a feature request into both snapd and snapstore.
Merged the topic here since it’s the same topic and they had almost exactly the same summary.
Per the notes above, snaps can already have cross dependencies today, via interfaces. These enable sharing actual content (data, files, etc) and also endpoints which expose a particular protocol (that’s somewhat vague, on purpose).
You should be able to use LXD and Juju by simply leveraging their APIs, and we can also get them to expose their clients via the content interface if that’s what you need. Some of the work going on in snapd right now will also make it easier to have sharing in the style of the content interface being performed via other interfaces, so this may soon become even nicer from a user standpoint.
Note that the content sharing in this case needs to take ABI and CLI compatibility issues into account.
It may be worth considering a new kind of interface that would enable one snap to call another one. We’d still want that to be an explicit interface rather than just a dependency, but that would get rid of the ABI issues at least. The CLI compatibility problems would still exist, though, and it’s part of the reason why we’d want that as an interface. The other important reason is enabling different snaps to expose the same interface, and allow the user to choose which to connect.
I think what adam is after is that a “snap install conjure-up” would automatically also install lxd and juju snaps …
i.e. dpkg like “Depends” fields through some kind of store assertions (and now that i wrote that it makes me want to run away screaming even more it would pretty much bring us back into the dependency hell that caused us to start dependency-less snaps initially)
it would pretty much bring us back into the dependency hell that caused us to start dependency-less snaps initially)