Re: Bindings not picked up from dependency <command>

On Sat, Apr 25, 2015 at 10:53 PM, Thomas Leonard <[email protected]> wrote:
> On 20 April 2015 at 04:48, Tim Cuthbertson <[email protected]> wrote:
>> On Mon, Apr 20, 2015 at 2:58 AM, Thomas Leonard <[email protected]> wrote:
>>> On 19 April 2015 at 12:54, Tim Cuthbertson <[email protected]> wrote:
>>>> 0install doesn't seem to be picking up bindings from <command>
>>>> dependencies. This seems like a bug, although it's possible commands
>>>> aren't intended to be used for what I'm trying to do.
>>>>
>>>> Specifically, I provide <command>s which aren't really commands, but
>>>> are more just extra bindings. As an example:
>>>>
>>>> http://gfxmonk.net/dist/0install/edit-server.xml
>>>>
>>>> contains (right down the bottom):
>>>>
>>>>     <command name="systemd-unit" path="edit-server">
>>>>       <environment insert="xdg/config" mode="prepend" name="XDG_CONFIG_DIRS"/>
>>>>       <runner interface="http://repo.roscidus.com/python/python"/>
>>>>     </command>
>>>>
>>>> The intent is not to run this directly, but to depend on it as
>>>> <requires command="systemd-unit" .... />, and you'll inherit the
>>>> appropriate environment variables to make this service available in a
>>>> user systemd session.
>>>
>>> <requires> doesn't take a "command" attribute; that goes on the
>>> <executable-in-*> bindings inside.
>>
>> Oops, that'd explain it!
>>
>>> Although you could use a dummy <executable-*> here, I wouldn't
>>> recommend it. In future, we might delay command bindings until the
>>> command is actually run, to avoid polluting the main process's
>>> environment.
>>
>> Agreed, that feels even more hacky...
>>
>>>> If this is a feature (rather than a bug), is there some way to provide
>>>> a set of opt-in bindings by name, rather than requiring the user write
>>>> these themselves? I've always been a little uncomfortable with
>>>> requiring users to write bindings which depend on the directory
>>>> structure of my implementation, but I can also see this being very
>>>> important for opt-in feature sets which export a handful of
>>>> environment variables (which becomes very fragile if you need to
>>>> duplicate multiple bundings in every feed which requires the given
>>>> feature).
>>>
>>> I think having a separate feed ("edit-server-systemd.xml") is the only
>>> easy way to do this.
>>
>> Hmm, that's a bit awkward (because you then have two separate feeds
>> and potentially need to do tedious version-pinning when features
>> change). Would it be possible to add a feature to support this? e.g.
>>
>> <requires interface="...">
>>   <bindings name="systemd"/>
>> </requires>
>>
>> which would bring in bindings from:
>>
>> <implementation ...>
>>     <bindings name="systemd">
>>       <environment ... />
>>     </bindings>
>> </implementation>
>>
>> I have had a bunch of places where I'd like to use something like
>> this, for optional integrations. Usually I just put them in the main
>> feed for simplicity, but I do feel bad bloating environments and
>> potentially injecting unwanted functionality into users environments.
>> Allowing a simple way to opt-in to one or more named integrations
>> would allow me to publish feeds without potentially-unwanted "helpful"
>> environment bindings by default.
>
> You could generalise the current concept of commands to "optional
> extras" like that. I'm not sure the added complexity is worth it
> though.
>
> For pure 0install packages, I think using the directory structure is
> perfectly fine (if documented). e.g. say "The systemd unit will be in
> the /systemd sub-directory", and have users bind that if they want it.
> Adding an extra layer of abstraction is only useful to support
> distribution packages.

There are other examples I can think of, where this isn't flexible enough:

 - multiple bindings. e.g a gnome-shell extension might need to inject
bindings into GJS_PATH and XDG_DATA_DIRS. It's inconvenient to require
the user to specify all of these, especially as GJS_PATH is really an
internal detail (which you might want to add/remove in later
versions).

 - different dependencies, e.g when running under systemd, you might
need to depend on the nodejs-socket-activation library (made up for
this example)

It's not a huge deal (and as you say, possibly not worth the
complexity), but it's going to be awkward if you need to do this sort
of stuff currently.

Cheers,
 - Tim.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y