Best practice for third-party PHP class-based library I am currently working on a module that requires a third-party PHP library, which is essentially a single PHP class.  Normally, I would place it in an includes/ subdirectory and add

files[] = includes/Foo.php


to my .info file and let the Drupal 7 class auto loader do its thing when I do a  $foo = new Foo().

I have permission, though, to release this module to the public and would rather not include the library with the module.  I am well aware about the complications regarding licensing, but for the sake of this question, I would like to ignore it. 

There is a similar question, How do I include a PHP library?, but I don't really think this answers my dilema.

This answers to this question essentially say to use the Libraries API, but every single module that I have found that uses this just does alibraries_get_path() to get the basepath (and includes fallback path when it isn't available) and then does a require or include with some error checking (or not).  All do something like:

if (!class_exists('Foo')) {
  $path = function_exists('libraries_get_path') ?
    libraries_get_path('foo') : 'sites/all/libraries/foo';
  if (!include($path . '/Foo.php')) {
      // handle this error
  }
}


In this case, the Libraries API isn't really doing anything.  I don't see the advantage to using this, over the old method of asking users to download a copy and place it in the module folder itself.  And, there is still the issue that the module developer still needs to manually do the load with include/require.  For example, the Facebook module just loads the library in a hook_init and the HTML Purifier module has an internal function to check-and-load every time the library is needed.

This may be a widespread practice, but it doesn't seem like a best practice.

Should my module take the initiative and declare a hook_libraries_info so I can use libraries_load('foo')?  This, too, seems odd.
Branch 2.x of the Libraries API module allows developers to define, through hook_libraries_info(), or a .info file for the library, the following information (see libraries.api):


The dependencies of the library
The version with which the library is compatible, for each of the dependencies
The list of the files that needs to be loaded (CSS, JavaScript, or PHP files) 


The list of files that needs to be loaded is used to load those files, when the library is required. This means that your module doesn't need to load CSS, and JavaScript files with drupal_add_css(), or drupal_add_js(), as that is already done from the Libraries API module. Loading the dependencies is a task done from the Libraries API module, without the calling module doing anything.  

All the module does is using the following code, for loading a library. (See Using Libraries API 2.x (as module-developer).)

// Try to load the library and check if that worked.
if (($library = libraries_load($name)) &amp;&amp; !empty($library['loaded'])) {
  // Do something with the library here.
}


If you just need to detect if a library is present, the module should use code similar to the following one.

if (($library = libraries_detect($name)) &amp;&amp; !empty($library['installed'])) {
  // The library is installed.
}
else {
  $error = $library['error'];
  $error_message = $library['error message'];
}


Between the properties hook_libraries_info() can return, there is also 'download url', which is not actually used, not even in the branch 3.x. Probably it will be used in future, or a third-party modules could hook into the Libraries API module, and download the libraries that are requested, but missing.