Search API Solr has along with Address (which I created) been one of the early adopters of Composer, which has created a ton of support requests and user anger in both of our issue queues.

I eventually gave in and provided an alternative to Composer, by writing Ludwig, a module that allows people to extract libraries directly into the module's lib folder, and have them autodetected. Blog post here: https://drupalcommerce.org/blog/49669/installing-commerce-2x-without-com...

If we add a ludwig.json to this module, then people will be able to use Ludwig to install it as well. There's no downside.

Comments

bojanz created an issue. See original summary.

bojanz’s picture

Status: Active » Needs review
StatusFileSize
new1020 bytes

Here's a patch.

As a bonus I also added a hook_requirements() that checks whether the library exists. The same kind of check in Address still catches several people each week, who failed to read the install instructions and just downloaded the tarball. Core was supposed to do this check automatically, but so far the issue hasn't gone anywhere.

mkalkbrenner’s picture

Interesting. But why does a module maintainer need to take care about where to get the download from?
Why doesn't Ludwig simply get the requirements from composer.json and uses packagist to find the download?
Where does Ludwig put the libraries and how does it deal with the autoloader?
One thing I'm really afraid of is the conflict management. I faced that so many times before composer was usable with drupal ...

bojanz’s picture

But why does a module maintainer need to take care about where to get the download from?
Why doesn't Ludwig simply get the requirements from composer.json and uses packagist to find the download?

The goal was to make Ludwig as simple and non-magical as possible. I was nervous about reimplementing any part of Composer's constraint resolving. This way the module maintainer is responsible for picking a known-to-work library version.

Where does Ludwig put the libraries and how does it deal with the autoloader?

Read the blog post / module page, it has good info :)
Libraries go into the module folder. In your case it's in modules/contrib/search_api_solr/lib/solarium-solarium/3.8.1/.
The library namespaces are added to the autoloader during container rebuild, by LudwigServiceProvider.

One thing I'm really afraid of is the conflict management. I faced that so many times before composer was usable with drupal ...

It will never be as good as Composer. But many people would rather die (or use Joomla) than learn. The dangers are the same as they were in D7. For us more theoretical, since I doubt other modules will try to include the Solarium library (or the addressing one in my case).

mkalkbrenner’s picture

I read the blog post. But to be honest, I'm still not a fan of ludwig.
I'm still of the opinion that the module maintainer should not be responsible to provide an exact download link.
As a module maintainer, I don't want to be responsible for taking care about security releases of 3rd party libraries and to be forced to react that quickly.

bojanz’s picture

Composer or Ludwig, people will always only update the libraries when updating your module.
Expecting more than that would be extremely unrealistic.
And yes, that means checking library versions before each release, but it feels like a small price to pay.

The patch has already been written. You are free to reject it, but the only consequence of that will be the ever increasing number of support requests in this queue, just like it was in the Address one.

damienmckenna’s picture

+1 for this.

  • mkalkbrenner committed e5b8f86 on 8.x-1.x authored by bojanz
    Issue #2891694 by bojanz: Check for solarium lib during install
    
mkalkbrenner’s picture

@bojanz: I committed the additional check for solarium during the install phase.

I had the chance to talk to some developers about ludwig. Nobody felt enthusiastic about it. But I'm aware that they are not "end users".
But due to the fact that even end-users will have to deal with the command line anyway, I still prefer to only promote this:
composer require drupal/search_api_solr

damienmckenna’s picture

Thanks for committing that change.

even end-users will have to deal with the command line anyway

They don't, and that's a key reason why Ludwig is useful to a large portion of Drupal users.

mkalkbrenner’s picture

I added a note about ludwig in the release notes of 8.x-1.1 to get some more feedback on this topic.

ressa’s picture

+1 for adding Ludwig as an option to the module.

shandman’s picture

+another 1 for this

c13l0’s picture

Adding Ludwig as an option +1!!!

For our use case, we have 21 sites built through Pantheon upstream. In order to use Solr for multi-site search we would have to completely rebuild every site from the ground up using composer. Using Ludwig would be a perfect option for us. For now, we are using a custom google search as a work around.

mkalkbrenner’s picture

Version: 8.x-1.x-dev » 8.x-2.x-dev
Status: Needs review » Needs work

OK, I consider (experimental) support for ludwig for 8.x-2.x. But the patch needs to adjusted.
We already committed a part of the original patch that needs to be removed.
And maennchen/zipstream-php is missing as dependency.

lennart’s picture

I support having also the ludwig option.

mkalkbrenner’s picture

Patch?

ressa’s picture

Status: Needs work » Needs review
StatusFileSize
new488 bytes

Here is an updated patch, which adds Ludwig integration. After installing the Ludwig module, I successfully installed the two libraries, required by Search API Solr Search:

$ drush ludwig-download
Downloaded package "solarium/solarium".
Downloaded package "maennchen/zipstream-php".
mkalkbrenner’s picture

Status: Needs review » Needs work

What about the requirements of solarium?

composer handles them:

    "require": {
        "php": "^7.0",
        "symfony/event-dispatcher": "^2.7 || ^3.0 || ^4.0"
    },

Solarium 5 might require HTTPlug.

And the next version of zipstream will add dependencies as well:

 "require": {
    "php": ">= 7.1",
    "ext-mbstring": "*",
    "psr/http-message": "^1.0",
    "myclabs/php-enum": "^1.5"
  },

I'm still not a fan of that ludwig thing. It puts additional load on me to do things manually composer would solve automatically. And I'm afraid of additional support request, too.

g089h515r806’s picture

+1 for ludwig

Just write a doc and let developer do it manually for complex dependencies.

mkalkbrenner’s picture

Version: 8.x-2.x-dev » 8.x-3.x-dev
Component: Code » Miscellaneous
Status: Needs work » Needs review
StatusFileSize
new504 bytes

  • mkalkbrenner committed 81564c0 on 8.x-3.x authored by bojanz
    Issue #2891694 by bojanz, ressa, mkalkbrenner: Add Ludwig integration
    
mkalkbrenner’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

devad’s picture

Title: Add Ludwig integration » Search API Solr - Add Ludwig integration

Ludwig integration is officially abandoned by Search API Solr module maintainers in the meantime.

For those who need to use Search API Solr module without Composer - there is a working D9 ludwig.json file example here:

#3082582-12: Search API Solr - Dropped Ludwig support