Integrate with contributed class loader modules

Updated issue summary.

Another option:
- Always register composer class loader (I think the registration itself is not too expensive)
- Provide a reliable way for other modules to know about the composer directory (which contains the autoload_classmap.php), or to know directly about the map of classes / namespaces.
- Provide a reliable way for other modules to know if new namespaces need to be registered
- Let the other module do the rest.

E.g. for xautoload I could imagine
- A setting in xautoload to let it handle composer namespaces (configured on performance settings page).
- Let xautoload replace the registered composer loader, if the setting is enabled.
- xautoload will directly check autoload_classmap.php to get the namespaces to register.

Motivation:
I want to absolutely avoid that xautoload becomes or is perceived as a possible risk to the system.
E.g. if someone has the wrong version of xautoload, etc.

swappable

What kind of "swappable" are you thinking of? The native spl_autoload_unregister() ?

I think it would be a good idea to wait until D8 gets PSR-4, and xautoload gets a new branch which supports that.
Maybe that new branch will have simplifications compared to the existing branch.

See #2083547: PSR-4: Putting it all together

I once had the idea to provide this convenient method when implementing.
But apparently this never made it into the module.
Would you say this is useful?

/**
 * Implements hook_xautoload()
 */
function composer_manager_xautoload(xautoload_InjectedAPI_hookXautoload $api) {
  $api->composerVendorDir('sites/default/vendor');
}

I want to mention that xautoload has a new branch 7.x-4.x with PSR-4 support, and an improved API.
This is going to be in alpha until Dries makes a decision on #1971198: [policy] Drupal and PSR-0/PSR-4 Class Loading, but this should not be an obstacle for 3rd party integration.
Also some interface names should be fine-tuned, and compatibility with the 7.x-3.x branch needs to be tested.

The new xautoload API can do this, similar to what i already proposed in #9:

/**
 * Implements hook_xautoload()
 */
function composer_manager_xautoload($api) {
  $api->composerDir('sites/default/vendor/composer', FALSE);
}

xautoload is designed to do everything pretty early in the request. This particular stuff happens on hook_init() or hook_custom_theme() whichever is first, and/or when new modules are enabled.
On the other hand, if APC cache or another cache is enabled, then all the registration stuff will only happen if there is a cache miss. This means, composer_manager_xautoload() will not fire at all on an average request. I think this is pretty awesome :)
There could even be ways to do this in hook_boot() or even earlier..

The real question is, how early is desirable?
#2157583: Fatal errors thrown when a module requires a dependency in composer.json that other modules include in their code base this one is a bit confusing to me, I think we need to get to a conclusion there before we talk about xautoload integration.

Because _rules_rebuild_cache() is called before composer_manager_init(). I do not why, but it happens.

If you look at a stack trace, often such hooks are called as a side effect of things other modules do in hook_init(), hook_custom_theme() or hook_boot(). xautoload "cheats" by implementing hook_custom_theme() in addition to hook_init(), because hook_custom_theme() fires earlier in the request.

I can use classes via composer in rules hooks (hook_rules_data_info()) again.

Can you confirm this still works with xautoload 7.x-5.x?

One problem with xautoload is that someone might have the wrong version of xautoload installed, and gets a WSOD for some features not being supported yet.

Not sure how we can solve this, if we don't want to make it an explicit dependency..

Some kind of feature detection would be nice.
Maybe xautoload should define constants such as

define('XAUTOLOAD_API_7X5X');

Or define a class, so you can do class_exists()..
Or something with class constants?

Also consider that the version in xautoload.info is not available if you have it from git.

Not to derail the thread, but would you suggest Composer Manager do the same thing in terms of registering its autoloader?

You could even consider to use hook_boot().
The question is, which side effects can this have? E.g. if at some point this triggers another hook to fire, then all kind of nonsense can happen. Some module might call watchdog(), and this might trigger theme initialization.
Or even if that does not happen, a hook to fire would cause premature inclusion of all *.module files.

For hook_custom_theme(): I am not sure this happens in every request, e.g. maybe it does not happen in Drush. So, the safe bet would be to implement both hook_init() and hook_theme(), and then whichever goes first.

You should also consider what to do when new modules are enabled.

After a lot of talking and some silence:

There is no fundamental problem in having both Composer's autoload.php and XAutoload working alongside.

However, the XAutoload cache (APC or other) works better if there are no other class loaders in play.
Especially, the "postpone initialization until first cache miss" stuff does not really work, if other modules/libraries want to use classes that xautoload doesn't know. This is because the cache does not store classes that failed to load (e.g. if you call class_exists('NonexisitingClass')). So every first unknown class in a request triggers a "first cache miss" behavior.

This could be mitigated by registering other class loaders (Composer) before xautoload's class loader. However, then we waste some microseconds in Composer's class loader, for classes that are only known by xautoload.

Still, all of this is about a few milliseconds or less. (just a wild guess, it's been a while that I benchmarked it)

There is also a risk involved: There might be a bug in xautoload, or someone might have the wrong xautoload version, or stuff is happening in the wrong time of the request. Or something might go wrong that is not caused by xautoload at all, but people still think it is.
Even if this risk is low, I still don't want to be blamed for "why this crap, when autoload.php works just fine".

The conclusion is to make this opt-in.
Even with both modules enabled, the admin should have to actively do something to enable this behavior.
And, there should be a reliable way out, if Drupal does not boot anymore.
The opt-in could be a setting, or an integration module to be enabled.
If we go for a setting, it would be nice if you can override it from settings.php.

Implementation:
1. Register Composer manager stuff in xautoload.
2. Stop the regular Composer class loader.

1. can be done like in #13.
(I hope that composer_manager_vendor_dir() does not have any unpleasant side effects and can be called at any time in the request)
2. How?