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
>>
>
>
From things like: /lists. ubuntu. com/archives/ snapcraft/ 2016-September/ 001068. html
https:/
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/linuxques tions/comments/ what_is_ responsible_ for_adding_ snapbin_ to_path/ d/apps- bin-path. sh /bugs.launchpad .net/bugs/ 1692866 /bugs.launchpad .net/juju- core/+bug/ 1692866/ +subscriptions
> 5gkv87/
>
> seems to say that /snap/bin is added to system profile.d directories
> /etc/profile.
>
> 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:/
>>
>> Title:
>> /snap/bin not in path for juju run/juju ssh
>>
>> To manage notifications about this bug go to:
>> https:/
>>
>
>