Re: Bindings not picked up from dependency <command>

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.


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

------------------------------------------------------------------------------
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