multiple binaries from the same package

[Sam Yaple]

This isn't a bug, but rather an architectural concept issue.

If I want a snap to seamlessly replace an existing system package, it only works if what I am snapping has a single binary. An example would look like this:

I have some compression library (for sake of example, named 'tiny') that provides pack and unpack type binaries. Users are used to typing (and all documentation refers to) `tiny` to compress and `untiny` to uncompress. I can't replicate this behavior with a snap, the best I can get is:

/snap/bin/tiny
/snap/bin/tiny.untiny

I understand the reason for this, to avoid conflicts between multiple packages, but perhaps there is a way to do this better. Perhaps some sort of metapackage to claim the other namespace? Have 'tiny' be the package and 'untiny' be a claimed metapackage so both binaries can exist without a prefix?

In the real-world, I am attempting to package OpenStack in snaps and this issue would prevent people from following existing documentation for management of OpenStack. With a solution to this problem it could truly be a seamless experience to use snappy instead of packages.

[Gustavo Niemeyer (niemeyer)]

I definitely understand the desire, but it's a slightly hard one to solve.

The problem is not technical though, but organizational. Everybody wants every command to be top-level, so offering this would mean moving what is today a flat snap namespace into being a flat application namespace, which would be somewhat unfortunate for the ecosystem.

Perhaps we can do something else to fix the problem, though. We should be able to easily offer a mechanism to put every application name from a specific selected snap in the current $PATH, which means all interactions with those commands would resolve into that snap.

This would have to be a user choice, but might solve the issue you're concerned about.

[Sam Yaple (s8m)]

I get your concerns, and I share them. It is a tough problem to solve without stepping on peoples toes. I would be interested to see a solution that involves modifying the PATH to includes specific projects, but I can't quite see how that would solve it.

Continue this discussion with explicit examples, in the case of OpenStack I need to access the following commands (from different snaps):

keystone-manage
glance-mange
nova-manage
neutron-db-manage

Just to name a few. Would all those paths be in the PATH variable? That gets to the point of possibly being considered PATH abuse.

Additionally, the package name might be 'rabbitmq' but the correct command to control this would be `rabbitmqctl`. So even if a snap has a single binary it needs to run, it's still rabbitmq.rabbitmqctl

I don't know what the right answer is, I do feel this is something that will need to be solved (preferably without user interaction) to get adoption up in the long run. Perhaps some config value that does this PATH thing automatically? Or another solution altogether.

[Gustavo Niemeyer (niemeyer)]

If the snap name is keystone, glance, nova, rabbitmq, etc, the pattern is to go with keystone.manage, glance.manage, nova.manage, rabbitmq.ctl, etc.

This really doesn't feel offensive from a user standpoint (subjective, of course), even more if you explain the rationale. That said, if you're keen on having the original names, simply ship this:

alias keystone-manage=keystone.manage
alias glance-manage=glance.manage
...

inside a file, and ask people to source it.

It needs to have user interaction, otherwise we need to conflict and offer a solution to deconflict that necessarily involves choosing between two snaps. Potentially completely unrelated snaps.

In a traditional Linux distribution, it's the responsibility of a closed set of maintainers to follow a policy and rename binaries out in some cases, and use "alternative" in other cases. When the namespaces are completely automated, that's not feasible.

We indeed may end up implementing something else on this area at some point, but it cannot be rushed in. It's better to have some names that we're not in love with at first, than to have a namespace that is impossible to use soon.

[Sam Yaple (s8m)]

"It's better to have some names that we're not in love with at first, than to have a namespace that is impossible to use soon."

This I completely agree with. There are solutions to this problem like you mention, aliasing is what I am currently doing. My goal is to make documentation re-consumable, but rabbitmq.ctl and keystone.manage would not achieve that goal due to different binary names.

I hope this doesn't come across as complaining, but rather I just want to make sure it is known that this is an area I believe there could be some improvement in as I feel it is an important issue. The sooner a conversation is had, the easier any solution that comes up can be implemented.

[Gustavo Niemeyer (niemeyer)]

Ah, don't worry, the input is appreciated and I understand where you're coming from.

We have a sprint next week, so will try to schedule a conversation about this too.

Keeping the bug open to track the topic nevertheless.

[Seth Arnold (seth-arnold)]

On Fri, Jul 15, 2016 at 06:23:22PM -0000, Gustavo Niemeyer wrote:
> alias keystone-manage=keystone.manage
> alias glance-manage=glance.manage
> ...
>
> inside a file, and ask people to source it.

This won't work particularly well with e.g. python scripts that might be
written to automate tedious tasks.

Not a bad start for user-facing friendlyness though.

THanks

[Michael Vogt (mvo)]

Work on this has been started, its codename is "toplevel commands" internally.

[Sergio Schvezov (sergiusens)]

https://github.com/snapcore/snapcraft/pull/947

[Joe Talbott (joetalbott)]

'aliases' and 'toplevel commands' are different from my understanding.

[John Lenton (chipaca)]

Joe, can you explain how you understand them to be different?

[Joe Talbott (joetalbott)]

I was under the misguided impression that 'aliases' would still be of
the form <snapname>.<alias> and that top-level commands would be of
the form <command>.

On Wed, Dec 14, 2016 at 9:34 AM, John Lenton <email address hidden> wrote:
> Joe, can you explain how you understand them to be different?
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1603481
>
> Title:
> multiple binaries from the same package
>
> Status in Snapcraft:
> Fix Committed
> Status in Snappy:
> In Progress
>
> Bug description:
> This isn't a bug, but rather an architectural concept issue.
>
> If I want a snap to seamlessly replace an existing system package, it
> only works if what I am snapping has a single binary. An example would
> look like this:
>
> I have some compression library (for sake of example, named 'tiny')
> that provides pack and unpack type binaries. Users are used to typing
> (and all documentation refers to) `tiny` to compress and `untiny` to
> uncompress. I can't replicate this behavior with a snap, the best I
> can get is:
>
> /snap/bin/tiny
> /snap/bin/tiny.untiny
>
> I understand the reason for this, to avoid conflicts between multiple
> packages, but perhaps there is a way to do this better. Perhaps some
> sort of metapackage to claim the other namespace? Have 'tiny' be the
> package and 'untiny' be a claimed metapackage so both binaries can
> exist without a prefix?
>
> In the real-world, I am attempting to package OpenStack in snaps and
> this issue would prevent people from following existing documentation
> for management of OpenStack. With a solution to this problem it could
> truly be a seamless experience to use snappy instead of packages.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snapcraft/+bug/1603481/+subscriptions

[Michael Vogt (mvo)]

The alias feature has landed in snapd 2.20/2.21