Problem/Motivation

I've been hunting down library related issues - and one I'm having a problem understanding is the dependency of PHPMailer.
First, I am fully aware that ludwig and composer don't play well together - and maybe that is all this is. However.
When I look at packages - ludwig reports the phpmailer/phpmailer required as 6.1.7 and goes so far as to create it as a subfolder named as such.
When I remove both smtp and phpmailer -clear my routing cache etc. - and then install via composer I get a 6.4 version of phpmailer and smtp module and both install nicely.
However, ludwig reports a missing required library of 6.1.7. The download and install within ludwig resolves this but now I have 2 phpmailer libraries. Shouldn't my installation of phpmailer/phpmailer pre-emptively to the SMTP module either take SMTP from the ludwig list -or- show in ludwig that the dependency is met?

I was looking at the patch somewhat related to this but I'm still scratching my head. If someone can easily explain this, I'd be greatly appreciative.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments

jshimota01 created an issue. See original summary.

devad’s picture

devad commented

As much as I can see, the PHPMailer module is not updated recently and it does not work nicely with library version 6.x.x at the moment. So, until #2947489: Provide support for PHPMailer 6.x is resolved - you may try the PHPMailer SMTP module instead.

If you are trying to use the current (not-updated) PHPMailer module and this SMTP Authentication Support module together.... yeah... you can have all kinds of library issues - because their required libraries are not compatible. It does not matter if you are using Composer or Ludwig... this combination will not work nicely until #2947489: Provide support for PHPMailer 6.x issue is resolved and a new tagged release of PHPMailer module is released. There is a patch though in this issue, so if you have patch testing experience you may try to test it and report back if the provided patch works for you.

The Ludwig and Composer stuff

Ludwig and Composer has nothing which connects them.

Composer reads data from composer.json file and installs all libraries required by composer.json file.

Ludwig reads the ludwig.json file and installs all libraries required by ludwig.json file.

It is the maintainer's job to keep the composer.json file and the ludwig.json file in sync.

However, the Composer is MUCH more powerful tool than Ludwig. It takes into consideration a whole bunch of other factors which influence the library compatibility with web project like: PHP version, compatibility with other drupal modules, eventual conflicts with older libraries or drupal modules etc. Composer also automatically supports all types of existing libraries while Ludwig does not.

Ludwig has a lot of limitations, but for Drupal users not familiar with Composer it can do a decent job. You can read about all ludwig limitations inside the FAQ section here: Ludwig integration developer's guide and FAQ

If you are getting more and more familiar with Composer, my humble suggestion for you (and everybody else) would be that you forget about Ludwig and that you manage all you web projects with Composer since it is much superior way of managing web projects today (and tomorrow).

And, if you are not familiar with Composer... Ludwig is here to help - until you adopt Composer one day in full. The sooner is the better. :)

mmjvb’s picture

mmjvb commented

When using Ludwig for the dependencies of SMTP it is your responsibility to verify the version information. The information in the ludwig.json of SMTP only pins to one particular version of a dependency. Consider it a minimum requirement. Ludwig doesn't have the capability to specify a version constraint like Composer does. You need to alter the version when you want a different (more recent) version. Same as with Composer consider patch or minor releases that are more recent.

AFAIK Drupal doesn't know how extensions are managed. Different methods can be used without problem, however not multiple methods for the same extension. At least, not all combinations make sense. Looks like Ludwig doesn't know how extensions are managed either. Suggest to ignore Ludwig for those managed by Composer.

Obviously, keeping track of how extensions (and their dependencies) are managed makes it harder as Drupal doesn't provide support for that. Without keeping track it is very easy to make mistakes, the different methods can't just be interchanged. Not all methods allow to determine the target destination. It is very difficult to use multiple versions of the same library.

jshimota01’s picture

jshimota01 commented

I am grateful for the replies.
I thought Ludwig was a drupal module that interfaced to composer! oops. I guess I should read more. I had no idea it was maintained via a separate json.

I've only got 2 libraries showing in ludwig- time to kill Ludwig. Pun intended.

I understand enough of composer and composer.json to be dangerous - i'll manage addon libraries through it from now on. I was reading somewhere about d9 and future library handling so this may be a gone issue someday.
thx.

jshimota01’s picture

jshimota01 commented
Status: Active » Closed (works as designed)
mmjvb’s picture

mmjvb commented

No, Ludwig doesn't interface to Composer, it interfaces with Drupal. It is a module that allows you to manage the dependencies of other modules. They need a ludwig.json to specify their dependencies. Drupal uses the autoload mechanisme of Composer, Ludwig extends that. (the usage by Drupal, not the mechanisme of Composer)

It is no problem to use Ludwig and Composer together. It becomes hard, maybe even impossible, when there is overlap between the two.

Obviously, when module managed by Composer, you can ignore Ludwig for that module and its dependencies. Use Ludwig when users extending Drupal don't have access to Composer. Use Composer when it fits your workflow.