I think it's time to re-evaluate the possibility of external (composer) dependencies for Rules. More specifically, I want to discuss the possibility of including https://github.com/fubhy/math-php as an external dependency for a set of Rules actions/conditions that evaluate mathematical expressions using variables from the Rules state. I think it would be a shame to having to include these directly in the Rules code base. I would greatly prefer to simply having things like this resolved through composer and the latest developments and research conducted by people like @webflo, @bojanz, @derhasi, etc. have shown that this is definitely an achievable goal for D8. At this point and given these developments, I am quite certain, that it would not in any way be harmful to the project if we included composer dependencies. Thoughts?

Comments

fubhy created an issue. See original summary.

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago at drunomics commented

Sounds totally reasonable imho.

Torenware’s picture

Torenware CreditAttribution: Torenware as a volunteer commented

How would this work in practice? Does D8 have a built-in mechanism to look for composer.json files in modules, so that the whole build forms a single set of dependencies?

Also, how would potential version conflicts on libraries installed into Core's vendor directory be handled? Is this discussed by any links from @webflo, @bojanz, @derhasi, etc.?

Would be real cool if this was workable, however.

bojanz’s picture

bojanz CreditAttribution: bojanz at Centarro commented

@Torenware
The current situation is documented at https://bojanz.wordpress.com/2015/09/18/d8-composer-definitive-intro/
We are working to make it simpler (#2380389: Use a single vendor directory in the root).

The end result is that people will need to do "composer require drupal/rules" in the Drupal root to install Rules, other methods won't be supported*.

(Unless you dowload the module manually and then edit the root composer.json manually, but most people won't want to do that)

TR’s picture

TR CreditAttribution: TR commented
Status: Active » Closed (won't fix)

There are two parts to this. First is the infrastructure to include Composer-based dependencies in Drupal modules. That has been figured out by core since this issue was first opened four years ago - it's now easy to do if you want to. But the second part is whether we should be doing this in Rules.

I am strongly opposed to *requiring* Composer in order to use Drupal/Rules. It is fine to support the use of Composer (and Rules *does* support it), but *requiring* it is a different thing - that basically excludes a lot of the non-developer user base as this user base may not have command-line access, may not have a server that meets the ridiculously huge memory requirements of Composer (most shared servers don't, in my experience), and may not have the technical knowledge or *desire* to learn yet another complicated tool just in order to install Drupal. I don't want to impose extra conditions to install Rules above what Drupal core requires. Drupal does not (yet) require Composer and has made a lot of effort to ensure that Drupal can be used without Composer.

So I suggest that if you have some useful functionality for Rules that can best be implemented using an external dependency include via Composer, that functionality should be first put into a separate contributed module where it can be useful without burdening Rules with the extra dependency. Then down the road if this functionality proves to be something that should be moved into Rules core we can re-evaluate the situation. Perhaps Drupal core will have it figured out at that point.