Re: Bindings not picked up from dependency <command>

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.

Cheers,
 - Tim.

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF