/snap/bin not in path for juju run/juju ssh

[Alberto Donato]

The /snap/bin directory is not included in PATH in "juju run" and "juju ssh" commands.

Using full path works of course, but I think the path should be included by default.

[John A Meinel (jameinel)]

https://www.reddit.com/r/linuxquestions/comments/5gkv87/what_is_responsible_for_adding_snapbin_to_path/

seems to say that /snap/bin is added to system profile.d directories
/etc/profile.d/apps-bin-path.sh

The question remains why (assuming snapd is installed), we aren't seeing it
added to the PATH when running charm hooks. It seems that profile.d is only
loaded by login shells.

I'm not sure that juju should be concretely adding knowledge about snap's
paths directly, vs snap adding itself to the default system paths all the
time rather than only in login shells.

On Tue, May 23, 2017 at 3:25 PM, Alberto Donato <email address hidden>
wrote:

> Public bug reported:
>
> The /snap/bin directory is not included in PATH in "juju run" and "juju
> ssh" commands.
>
> Using full path works of course, but I think the path should be included
> by default.
>
> ** Affects: juju-core
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> https://bugs.launchpad.net/bugs/1692866
>
> Title:
> /snap/bin not in path for juju run/juju ssh
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1692866/+subscriptions
>

[John A Meinel (jameinel)]

juju-core is for juju-1.x, retargetting to 'juju' for 2.x

[John A Meinel (jameinel)]

From things like:
 https://lists.ubuntu.com/archives/snapcraft/2016-September/001068.html

It is intended that snaps do not default to seeing /snap/bin in their path,
and instead need to use things like content interfaces to get access to
other binaries.

However, charms that are managing snapped applications are not quite the
same thing.

That said, a charm would know if it is deploying a snapped application (did
it do snap install or apt install), then it *could* do /snap/bin/app.

Since Juju itself isn't ever installing snapd (it is only ever
there-by-default or driven by the charm), it doesn't feel like our direct
responsibility.

It may be the that we need to work around the fact that snapd itself isn't
doing the right thing.

John
=:->

On Tue, May 23, 2017 at 6:08 PM, John Meinel <email address hidden> wrote:

> https://www.reddit.com/r/linuxquestions/comments/
> 5gkv87/what_is_responsible_for_adding_snapbin_to_path/
>
> seems to say that /snap/bin is added to system profile.d directories
> /etc/profile.d/apps-bin-path.sh
>
> The question remains why (assuming snapd is installed), we aren't seeing
> it added to the PATH when running charm hooks. It seems that profile.d is
> only loaded by login shells.
>
> I'm not sure that juju should be concretely adding knowledge about snap's
> paths directly, vs snap adding itself to the default system paths all the
> time rather than only in login shells.
>
>
>
>
> On Tue, May 23, 2017 at 3:25 PM, Alberto Donato <
> <email address hidden>> wrote:
>
>> Public bug reported:
>>
>> The /snap/bin directory is not included in PATH in "juju run" and "juju
>> ssh" commands.
>>
>> Using full path works of course, but I think the path should be included
>> by default.
>>
>> ** Affects: juju-core
>> Importance: Undecided
>> Status: New
>>
>> --
>> You received this bug notification because you are subscribed to juju-
>> core.
>> https://bugs.launchpad.net/bugs/1692866
>>
>> Title:
>> /snap/bin not in path for juju run/juju ssh
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/juju-core/+bug/1692866/+subscriptions
>>
>
>

[John A Meinel (jameinel)]

I'm not sure that 'snapd' is the right target for this, but not having '/snap/bin' on your PATH inside systemd launched scripts seems to be a snapd packaging issue.

[Anastasia (anastasia-macmood)]

This seems to be related to, if not duplicate of, bug # 1660273.

[John A Meinel (jameinel)]

Agreed

[John A Meinel (jameinel)]

From things like:
 https://lists.ubuntu.com/archives/snapcraft/2016-September/001068.html

It is intended that snaps do not default to seeing /snap/bin in their path,
and instead need to use things like content interfaces to get access to
other binaries.

However, charms that are managing snapped applications are not quite the
same thing.

That said, a charm would know if it is deploying a snapped application (did
it do snap install or apt install), then it *could* do /snap/bin/app.

Since Juju itself isn't ever installing snapd (it is only ever
there-by-default or driven by the charm), it doesn't feel like our direct
responsibility.

It may be the that we need to work around the limitation of snapd packaging.

On Tue, May 23, 2017 at 6:08 PM, John Meinel <email address hidden> wrote:

> https://www.reddit.com/r/linuxquestions/comments/5gkv87/
> what_is_responsible_for_adding_snapbin_to_path/
>
> seems to say that /snap/bin is added to system profile.d directories
> /etc/profile.d/apps-bin-path.sh
>
> The question remains why (assuming snapd is installed), we aren't seeing
> it added to the PATH when running charm hooks. It seems that profile.d is
> only loaded by login shells.
>
> I'm not sure that juju should be concretely adding knowledge about snap's
> paths directly, vs snap adding itself to the default system paths all the
> time rather than only in login shells.
>
>
>
>
> On Tue, May 23, 2017 at 3:25 PM, Alberto Donato <
> <email address hidden>> wrote:
>
>> Public bug reported:
>>
>> The /snap/bin directory is not included in PATH in "juju run" and "juju
>> ssh" commands.
>>
>> Using full path works of course, but I think the path should be included
>> by default.
>>
>> ** Affects: juju-core
>> Importance: Undecided
>> Status: New
>>
>> --
>> You received this bug notification because you are subscribed to juju-
>> core.
>> https://bugs.launchpad.net/bugs/1692866
>>
>> Title:
>> /snap/bin not in path for juju run/juju ssh
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/juju-core/+bug/1692866/+subscriptions
>>
>
>