Installation Requirements

This is indeed a tricky one: you don't want to set either of the supported modules as a dependency in the .info file because then you'd require both of them to be installed and enabled, but you don't want to not declare any dependencies because out of the box the module does not do anything on its own (unless #2116161: Support taxonomy term reference field is fixed of course and then it will work with core taxonomy fields).

Anyways, I gave the patch a quick spin at simplytest.me:

http://simplytest.me/project/entityconnect/7.x-1.x?patch[]=https://drupal.org/files/entityconnect.install.requirements_2.patch

...but it didn't work as I expected it to. I thought it was supposed to stop the module from being enabled or at least throw a warning that you need to download any of the supported modules.

I ran into this problem as well when attempting to include entityconnect in an installation profile. It seems that we ought to check to see what type of installation is occurring, and then perform the requirements checks accordingly. I created the attached patch, and it seems to work nicely in both contexts according to my testing (I attempted installation with and without one of the required modules in both cases). During a Drupal install, it checks for module existence using sherakama's method. During a manual/individual/"normal" module install, it checks using the original method. Now that this distinction is in place, it seems we should use REQUIREMENT_ERROR instead of REQUIREMENT_WARNING, in order to prevent normal installation of the module if none of the required modules are enabled.

I'm currently giving #5 a go and will report back soon. In the meantime, I think it's worth to mention the Module Supports project:

This module shows how modules can be enhanced by or enhance other modules by using information provided in module .info files (implementation of #328932: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files).

I think we should support this and start using either supports[] = modulename or enhances[] = modulename in this module's .info file. So we should either add this:

supports[] = entityreference
supports[] = references

...or this (I actually believe this is a better fit in our case):

enhances[] = entityreference
enhances[] = references

Thanks @ndewhurst for the patch. I will try to review it soon.
You mentionned "sherakama's method", can you provide me a link?

Also, is there any limitation (OS compatibility?) with the use of drupal_system_listing()?

@klonos, thanks for pointing supports module but if I can avoid depencies like that it looks to be better for me.

Hi jygastaud,

By "sherakama's method" I meant using drupal_system_listing() as shown in comment #2 above. That approach makes sense to me, for cases when module_exists() will always return FALSE. drupal_system_listing() seems to be OS agnostic; using it along with DRUPAL_PHP_FUNCTION_PATTERN seems to be a proven approach (e.g. in bootstrap.inc:drupal_get_filename()).
I just updated my patch to use drupal_installation_attempted() to determine whether we're in a Drupal install context.

Thanks for patch update.

It looks great.
I will give it a try in on a fresh installation and if everything OK I will push it in 7.x-1.x branch.

Thanks everyone for the help.