Add support for the Libraries API

The way it looks, we could just check for function_exists('libraries_get_path') (or module_exists('libraries')) and thereby avoid the additional dependency (which I don't want to add). In any case, this also needs to be included in INSTALL.txt.

I did think of proceeding as stated in #1 but then we'll need to add again code to check for sites/all/libraries.

In my opinion this is still preferable. Just add the Libraries API as the first option, but keep all the other code. Not really elegant to just keep piling things for this, but at least it would resolve your problem. And keep dependencies to a minimum.

But maybe someone else might want to chime in here with their opinion?

I don't think we should duplicate Libraries API here. Just support it if it's there and provide a simple fall-back otherwise.
Patch attached.

libraries_get_path's result is not reliable: libraries_get_path('non-exists') returns 'sites/all/libraries/non-exists'.

Ah, OK, that's a version-mismatch issue. I was basing my patch on Libraries API 2.x, which (much more sensibly, in my opinion) returns FALSE when no directory can be found. In my opinion, that's very bad judgement on the part of the maintainers, just changing the function's contract instead of introducing a new function … Rather difficult to work with this now. Your patch won't work correctly with the 2.x branch, as it checks for the existence of the Drupal root directory and returns that if the library isn't installed in a location known to the Libraries API.

Either we have to explicitly handle the case that libraries_get_path() returns FALSE, or we explicitly check for the version of Libraries API.
Do you happen to know how to do the latter, i.e., retrieve a module's installed version? Otherwise we'd unnecessarily check for the directory's existence a second time in 2.x (although I guess that's tolerable …).

Hm, come to think of it, checking twice for the directory might easily be faster than doing the module version lookup, so let's just do that. Patch attached.

OK, committed the last patch.
Thanks for the suggestion and your work on this!

I don't think this is working for me. I added my SolrPhpClient in DRUPAL_ROOT/profiles/PROFILE/libraries, but it gives the following error.

WD php: Exception: SolrPhpClient library not found! Please follow the instructions in           [error]
search_api_solr/INSTALL.txt for installing the Solr search module. in
_search_api_solr_solrphpclient_path() (line 47 of
/home/quickstart/websites/profile.dev/profiles/da7/modules/contrib/search_api_solr/search_api_solr.module).
Exception: SolrPhpClient library not found! Please follow the instructions in search_api_solr/INSTALL.txt for installing the Solr search module. in _search_api_solr_solrphpclient_path() (line 47 of /home/quickstart/websites/profile.dev/profiles/da7/modules/contrib/search_api_solr/search_api_solr.module).

I verified that drush make put all the files in the correct directory.

Here is the info for my make file:

; Search API SOLR
libraries[SolrPhpClient][download][type] = get
libraries[SolrPhpClient][download][url] = http://solr-php-client.googlecode.com/files/SolrPhpClient.r60.2011-05-04.tgz
libraries[SolrPhpClient][directory_name] = SolrPhpClient

I am using the latest 1.x-dev

Do you have Libraries API 2.x installed and enabled? And is PROFILE the profile you use for installing?

Yes I'm using

projects[libraries][version] = 2.0-alpha1
projects[libraries][subdir] = contrib

No, "da7" is the name of the profile I'm using.

Let me know if there is anything else I can test.

Could the problem be that I don't yet have Apache Solr installed? It's throwing the error on a fresh site install. I have my install profile set to enable the search_api and search_api_solr modules.

Some more info:
When trying a fresh install with the install profile, the site always gives the error above. Either through Drush or a web install.

If I disable the search_api_solr module from installing in the install profile, then the site installs fine. Once the site is installed, I can then enable the search_api_solr module and everything works fine, no errors.

...strange? I'm not sure what is going here.

Seems to be some problem with Features and dependencies, where it tries to install Search API Solr before installing Libraries API and/or the SolrPhpClient library. Hardly anything I can do about it, you'll probably have to manually add some dependencies (through dummy features that only reference dependencies, or additional make files, or something like that).
Anyways, a separate support request rather than really a continuation to this issue.

No, "da7" is the name of the profile I'm using.

I was referring to this:

DRUPAL_ROOT/profiles/PROFILE/libraries

So is this DRUPAL_ROOT/profiles/da7/libraries?

Seems to be some problem with Features and dependencies, where it tries to install Search API Solr before installing Libraries API and/or the SolrPhpClient library. Hardly anything I can do about it, you'll probably have to manually add some dependencies (through dummy features that only reference dependencies, or additional make files, or something like that).
Anyways, a separate support request rather than really a continuation to this issue.

I'm not using any Features yet. I'm just trying to create a site using an installation profile that I created. The SolrPhpClient library is downloaded and placed in DRUPAL_ROOT/profiles/da7/libraries folder. The installation profile then enables the search_api_solr module.

I did some more testing and everything worked when I placed the SolrPhpClient library into the search_api_solr module folder.

Just tried putting the library in DRUPAL_ROOT/sites/all/libraries folder and that worked.

So the remaining issue is that the code doesn't work when installing your SolrPhpClient library in DRUPAL_ROOT/profiles/YOURPROFILE/libraries folder.

So the remaining issue is that the code doesn't work when installing your SolrPhpClient library in DRUPAL_ROOT/profiles/YOURPROFILE/libraries folder.

It does work (you confirmed this yourself in #16), it just doesn't work when Libraries API isn't yet running – which it apparently isn't in your setup. Nothing we can do about that.