[LV2] Best practice to get plugins using 3rd party extensions/features to pass validation?

[David Robillard]

On 2017-07-11, at 22:37, Hanspeter Portner <dev at open-music-kontrollers.ch> wrote:
> 
> On 11.07.2017 15:49, Filipe Coelho wrote:
>> On 11.07.2017 15:45, Hanspeter Portner wrote:
>>> A prominent reason are plugins using 3rd party extensions/features (e.g.
>>> harrisonconsoles' inlinedisplay:queue_draw/schedule, kxstudio's
>>> programs:interface, modgui).
>> 
>> Hello.
>> 
>> The kxstudio extensions can be found here:
>> https://github.com/KXStudio/LV2-Extensions
>> So they're easy to install. (copy *.lv2 bundles to LV2_PATH)
>> 
>> The MOD stuff is here: https://github.com/moddevices/mod-sdk
>> Easy to install as well.
>> 
>> 
>> I use kxstudio & mod stuff in my plugins, and have no issues regarding validation.
> 
> I know I (as developer) can install them manually. I wanted to know something
> else, though, from the user's perspective.
> 
> I'll try to rephrase...
> 
> Who's job is it to provide the 3rd party extension/feature definitions on the
> user's machine?
> 
> 1) it is the users job (e.g. grab the 3rd party *.ttl from the web)
> 2) it is the developer's job (e.g. ship the 3rd party *.ttl (or a shortened
> version thereof) with the plugin)
> 3) it is the distribution packagers job to provide the 3rd party *.ttl via a
> dependency
> 4) it is enough for a plugin to validate on the developer's machine
> 5) …

I suppose it depends, really.  Different platforms have different conventions about this sort of thing, and it depends if the extension is used by many plugins or just one set that is distributed as a whole (in which case including it in that bundle is easy)

It is general best practice for them to always be installed, though.  It’s not just about validation, but the definition of things in extensions might have useful data which applications actually use in a user-visible way.  Comments being used for help text is the most obvious example.

Also worth noting that sord_validate is more stricter than it could be.  I think this is a good thing because it catches more errors, but for example a property not being defined at all is a different sort of thing than plugin having a value which is known to definitely be incorrect because the schema is available.  I could maybe add an option for this, but I’m not sure how feasible this would be to do.  Might also make the situation less confusing if there was a warning/error distinction in the output here?

Some sort of “universe” thing where the LV2 infrastructure could be used to distribute extensions that aren’t part of LV2 itself could help with the distribution aspect as well, but then somebody would need to maintain that thing, so without having some sort of actual LV2 “package” manager this doesn’t seem terribly realistic to me.  Maybe some big monolithic git repo...

— 
dr