Meta-packages for snaps

[Joseph Rushton Wakeling]

On 27/03/17 04:33, Michael Hall wrote:
> Because your snap is going to pull in all of your dependencies, doing
> one snap per tool will likely result in more duplication and thus more
> disk space than providing it all as a single package.

That's a very good point.  On the other hand, the disk space issue isn't likely 
to be so great in the grand scheme of things, whereas providing tools separately 
may allow greater freedom in updating their individual versions (these are not 
things all deriving from one repo or one release series).

> If your users are likely to want more than one of these tools, I would
> recommend just providing them all in one package. That way it's still
> easy for them to install with a single command, and they will have
> everything they might want already there.

Fair enough.  This actually dovetails quite nicely with the planned use-case, 
which is snap packages for all the core D utilities: the D core devs I'm talking 
with are probably in favour of a single snap providing all the utilities.  I 
will probably follow up on this soon :-)

Overall, though, I still think it'd be nice to have the flexibility (as a 
publisher) to choose between a single snap with multiple commands, versus a 
meta-snap that ensures multiple different independent snaps are installed.