Important questions to answer before adding Ludwig support to module

Remember, Ludwig is literally Libraries API 2.0, there is no magic here. We find a directory via ludwig.json and we add it to the autoloader.

If my module requires library A, I can easily create a ludwig file. But what is required if library A itself requires library B?
Do I need to add library B to the ludwig file as well?

If I support ludwig as a module maintainer of a module that requires library A as described above, I think that I have to add library B and C to the ludwig file, too. Is that correct?

Yes. You are responsible for every dependency.

Let's say, library B requires library C in version 1.2.x. But Drupal core requires library C as well in version >= 1.x and already installed version 1.3.0. Composer will resolve that situation. But what will ludwig do?

If the library requires a dependency which has a compatible version in core, just omit the dependency from ludwig.json.

Library B has a requirement for some PHP extensions. Composer takes care about that, too. How will ludwig deal with it?

It won't. Your module will need to implement a hook_requirements() if the PHP extension is not one that Drupal already requires.
This could be made more magical in the future (have Ludwig implement hook_requirements and parse the composer.json files).

If library B has a security release, I might not be aware of it because I only track the releases of library A, which is my direct dependency. Who is responsible?
Using composer, the user can update his environment.
Using ludwig, it seems that the Drupal module maintainer needs to create a new release of his module every time there's a security issue somewhere in the dependency tree.

Correct, you are responsible. Let's be honest, no user runs random composer updates, if there's a security update in a dependent library, it will stay unapplied in 90% of current Drupal sites.

It sounds like a lot of additional work load for module maintainers.

That's for you to decide. We maintain dozens of ludwig.json files (Address, Commerce, payment gateways) and our support burden has disappeared since Composer-reluctant people now have a solution. Library updates require retesting from time to time anyway, so a Ludwig version bump does not take noticeable effort on our side.

What if a module doesn't manage it's dependencies using ludwig but is required in a project where ludwig is used? How do you deal with it?

Other modules are free to use Composer or other ways of modifying the autoloader, it doesn't affect us, just the user experience.

I have written some prototype code that automates some of this (generating ludwig.json and packaging libraries). I believe it can be fully automated (e.g. by drupal.org) so that module maintainers don't have to do anything.

In the meantime, anyone with modest linux skills should be able to take any module with a composer.json file and make it Ludwig-ready for installation.

Here it is: https://www.drupal.org/sandbox/alexa/3025040

Fixed typo in title and tried to make it clear that this issue is for module maintainers - not users.

Nothing more to do here.

I have created:

Ludwig integration guide and FAQ for module developers

At new Ludwig module documentation section.

I have used questions and answers from this issue.

Thanks @Bojanz and @mkalkbrenner for your dialog.