Problem/Motivation

The drupal/core package does not require symfony/expression-language, because there is no real dependency regardless of the fact that Drupal\Component\DependencyInjection\Dumper\OptimizedPhpArrayDumper and Drupal\Tests\Component\DependencyInjection\Dumper\OptimizedPhpArrayDumperTest use Symfony\Component\ExpressionLanguage\Expression

From core/tests/Drupal/Tests/Component/DependencyInjection/Dumper/OptimizedPhpArrayDumperTest.php

/**
 * As Drupal Core does not ship with ExpressionLanguage component we need to
 * define a dummy, else it cannot be tested.
 */
namespace Symfony\Component\ExpressionLanguage {
  if (!class_exists('\Symfony\Component\ExpressionLanguage\Expression')) {
    /**
     * Dummy class to ensure non-existent Symfony component can be tested.
     */
    class Expression {

      /**
       * Gets the string representation of the expression.
       */
      public function __toString() {
        return 'dummy_expression';
      }

    }
  }
}

From core/lib/Drupal/Component/DependencyInjection/Dumper/OptimizedPhpArrayDumper.php

    elseif ($value instanceof Expression) {
      throw new RuntimeException('Unable to use expressions as the Symfony ExpressionLanguage component is not installed.');
    }

Proposed resolution

Remove symfony/expression-language from the list of required components in lib/Drupal/Component/DependencyInjection/composer.json

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Eric_A created an issue. See original summary.

Eric_A’s picture

Status: Active » Needs review
FileSize
534 bytes
Eric_A’s picture

Eric_A’s picture

Issue summary: View changes
alexpott’s picture

Shouldn't we move this to suggest then? See https://getcomposer.org/doc/04-schema.md#suggest

Eric_A’s picture

Shouldn't we move this to suggest then?

Yes, probably a good idea.

Arguments against:
- Unlike Symfony\Component\DependencyInjection\Dumper\PhpDumper, there currently is no conditional behavior in Drupal\Component\DependencyInjection\Dumper\OptimizedPhpArrayDumper. It just throws a RuntimeException if an instance of Expression is passed.

Arguments in favor:
- It makes a little difference for the test. The fact that component tests live in drupal/core does not make a real difference, since in order to get subcomponents, chances are you'll do so by requiring drupal/core.
- Suggesting it has value from a documentation point of view. It will make people think before creating a bug report that the Expression class is being used but the component not being required.

Here's a patch that copies the suggestion from symfony/dependency-injection.

Eric_A’s picture

Issue summary: View changes
FileSize
649 bytes
jibran’s picture

Status: Needs review » Reviewed & tested by the community

Looks much better now.

Mile23’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: -Quick fix

In #2337283: Add a composer.json file to every component I determined these dependencies by looking at all the use statements in each component.

If symfony/expression-language is not a dependency then a) we should never reference it in use statements, and b) we shouldn't test against its existence.

For instance, OptimizedPhpArrayDumper says:

use Symfony\Component\ExpressionLanguage\Expression;

Which automatically means it's a dependency. If we're not expecting this class to exist, then when dumpValue() says:

    elseif ($value instanceof Expression) {
      throw new RuntimeException('Unable to use expressions as the Symfony ExpressionLanguage component is not installed.');
    }

...we should get a class not found fatal before we ever throw the RuntimeException.

Eric_A’s picture

The use statement makes class aliasing possible and doing run-time checks like class_exists() and instanceof, which fits the use case of composer suggest. There's no hard dependency, otherwise core would have crashed, given that we currently only process core/composer.json and not the components dependencies.
Sure, there's room for improvement in drupal/core-dependency-injection, and we could make symfony/expression-language a hard drupal/core (dev) dependency, but that seems out of scope here.
Could you elaborate a bit on what work you feel needs to be done here?

Eric_A’s picture

Also, note the similarity in code with Symfony\Component\DependencyInjection\Dumper\PhpDumper. It's all runtime checking.
And in the symfony component it's a dev requirement, so it's only retrieved when the component is the root package, not when the component is a dependency.

Mile23’s picture

Status: Needs work » Reviewed & tested by the community

OK, so I was thinking out of my butt a little bit there. :-)

suggest is good.

And if it isn't, we'll find out after the split.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 7: 2747083-8.patch, failed testing.

Mile23’s picture

Status: Needs work » Reviewed & tested by the community

Unrelated fails? Let's see. Restarting test.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 7: 2747083-8.patch, failed testing.

Eric_A’s picture

Status: Needs work » Reviewed & tested by the community

Per #8 and #12.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed 88d101c96afbe9a3e82e177101a42508e714ff92 to 8.2.x and ff3b3e8 to 8.1.x. Thanks!

  • alexpott committed 88d101c on 8.2.x
    Issue #2747083 by Eric_A, Mile23, alexpott: drupal/core-dependency-...

  • alexpott committed ff3b3e8 on 8.1.x
    Issue #2747083 by Eric_A, Mile23, alexpott: drupal/core-dependency-...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.