Closed (fixed)
Project:
Search API Solr
Version:
8.x-3.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
2 Jul 2017 at 19:35 UTC
Updated:
10 May 2021 at 09:42 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
bojanz commentedHere'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.
Comment #3
mkalkbrennerInteresting. 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 ...
Comment #4
bojanz commentedThe 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.
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.
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).
Comment #5
mkalkbrennerI 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.
Comment #6
bojanz commentedComposer 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.
Comment #7
damienmckenna+1 for this.
Comment #9
mkalkbrenner@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_solrComment #10
damienmckennaThanks for committing that change.
They don't, and that's a key reason why Ludwig is useful to a large portion of Drupal users.
Comment #11
mkalkbrennerI added a note about ludwig in the release notes of 8.x-1.1 to get some more feedback on this topic.
Comment #12
ressa+1 for adding Ludwig as an option to the module.
Comment #13
shandman commented+another 1 for this
Comment #14
c13l0 commentedAdding 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.
Comment #15
mkalkbrennerOK, 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.
Comment #16
lennart commentedI support having also the ludwig option.
Comment #17
mkalkbrennerPatch?
Comment #18
ressaHere 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:
Comment #19
mkalkbrennerWhat about the requirements of solarium?
composer handles them:
Solarium 5 might require HTTPlug.
And the next version of zipstream will add dependencies as well:
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.
Comment #20
g089h515r806 commented+1 for ludwig
Just write a doc and let developer do it manually for complex dependencies.
Comment #21
mkalkbrennerComment #23
mkalkbrennerComment #25
devad commentedLudwig 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