Add the symfony validator component to core despite Symfony potentially releasing BC-breaking updates after 2.3.

If it's possible to remove them via composer, then I think we should. If not (i.e., if that would be a manual operation), then not.

In https://groups.google.com/d/topic/symfony-devs/oNaXdV5UGRU/discussion, fabpot listed the Validator component in the least BC stable group. So was the Serializer component, but Dries accepted that. Assigning to Dries, since he'll need to make the call. Is there any updated info available on what is and isn't stable?

Patch to solve #2, but will only work on *nix systems, we can do the same using PHP, see http://getcomposer.org/doc/articles/scripts.md

This should work better

Ignore the patch in #5 it updated everything except adding validator

Since this is blocking and time is running short.

Only question: do we use 'rm -rf' or do we prefer a PHP implementation?

Another solution is to add it to core/vendor/.gitignore so that it's not added to the git repository. Benefit is that:

1. Will work on any platform
2. Easy to update if the Resources location changes
3. We're already using this method for some of the PHP 5.4 fixture code that Symfony provides to let Drupal Testbot pass

Built with drush composer install --prefer-dist .

+++ b/core/vendor/composer/autoload_namespaces.php
@@ -8,6 +8,7 @@
     'Symfony\\Component\\Yaml' => $vendorDir . '/symfony/yaml/',
+    'Symfony\\Component\\Validator\\' => $vendorDir . '/symfony/validator/',

What's causing the extra trailing slash in the namespace name? We haven't yet switched to Composer's autoloader, and instead this gets passed to Symfony's, and I don't know if the trailing slash is a problem there. In any case, it's inconsistent with the other entries.

#13 Assuming this is about the patch in #8, to be honest, no idea I ran composer require symfony/validator, all the magic was done by composer

#13 That's an update from Symfony and is taken into consideration over at #1658720: Use ClassLoader instead of UniversalClassLoader.

Approach in #12 works as well, assuming #13 isn't a blocker.

@fago - have you heard back about the stability of this yet?

#17 most of the interfaces are already tagged with @api, see https://github.com/symfony/Validator/blob/master/ConstraintViolationList...

Not sure why, but composer seems to generate it that way now.

It's an update from Symfony. You can see in their composer.json, they declare Symfony\\Component\\Validator\\. This change is made so that the autoloader has an easier time finding classes. It's fixed by either:

1. #1658720: Use ClassLoader instead of UniversalClassLoader
2. Using Composer's autoload.php

I vote for #1 if we get it working with the bootstrap.

#12 and #19 only differ by that one trailing slash. I'd be fine with either one going in. If #12 goes in, we can deal with fixing it / working around it as part of #1845546: Implement validation for the TypedData API if that issue becomes ready before we've accomplished #20. If #19 goes in, then we can undo that one manual change after fixing #20.

RTBC for #19, this will be the fastest way forward.

There's a difference with this vs. the serializer.

With the serializer we've not been using it to replace any existing core functionality, only to add new functionality which is outside the critical path. So if it turned into a bc disaster or there were other issues then it'd mess up the JSON-ld work but not much else (there's an issue to convert RSS feeds but those don't count as critical path either).

Using this for entity validation puts it right into the middle of core so it's a much more fundamental dependency to be adding.

I haven't reviewed the component yet and need to get caught up on the implementation issue as well...

I haven't had a lot of time to look into this. Based on limited research, I think this is a good idea in theory. However, I agree that we need to understand the practical implications (e.g. stability of API). In that sense, I agree with catch in #24.

I would love to have some level of commitment that allows us to manage the risk or otherwise have some automation to make sure we don't use unstable APIs. Maybe something that could be added to the testbot or so?

Sorry for the delayed response. I just returned from the Symfony conference in Berlin today.

I would like to clear the doubts about the stability commitment of Symfony. Basically, the rules are very simple:

• Anything tagged as @api is guaranteed to be stable, but
• • Until 2.3 we take the right to change code tagged with @api if absolutely necessary. We will try to prevent this scenario at all cost.
  • As of 2.3, no changes will be made to @api-tagged code, except in the case of security issues that cannot be solved otherwise. Any features or improvements that require changes to the tagged API will be postponed to Symfony 3.
• Anything not tagged as @api should generally not be relied on.

So it really boils down to the @api tags: Currently, a large part of Symfony's API (= mainly interfaces and central classes) are already tagged as @api. These tags are put on code that has been proven to work.

The recent refactorings to the Validator are new and thus are not marked as @api yet. We will mark the Validator interfaces as @api with the release of 2.2, unless we (or Drupal) discover problems with this new API that cannot be solved until 2.2. Note that no code previously tagged as @api has changed in these refactorings.

We currently have a related Symfony issue that might be interesting for you:
https://github.com/symfony/symfony/issues/6129

bschussek: So it sounds like we still have a window for a few more months where we could try out the Valdiator and push change requests back upstream if we need them, before it gets locked down for-reals in ~May, right?

That to me sounds like a "commit now so we can make sure it's fully baked for our use when it does freeze" situation.

That sounds encouraging to me, thanks bschussek!

bschussek: So it sounds like we still have a window for a few more months where we could try out the Valdiator and push change requests back upstream if we need them, before it gets locked down for-reals in ~May, right?

Exactly.

Anything not tagged as @api should generally not be relied on.

So if we're adding a component to Drupal that has some public methods annotated with @api and some not, how do we verify that patches submitted to Drupal core are only using the @api ones? Relying on reviewers/committers to manually do this is too fragile. Any way to automate it? I don't think we need to block commit of this on that automation, as long as we think such automation is reasonable to accomplish by D8 release.

We could subclass it and throw exceptions from the non @api methods? Then remove the subclass later?

There are a few issues stalled by this, can we get it in soon, please? The approaching feature freeze scares me.

#19: d8_validation_symfony.patch queued for re-testing.

Postponed on #1852106: Add the symfony translator interface or translation component

I'm comfortable with this being committed after the translation issue is resolved.

Oh, I like catch's idea in #32 as well.

FYI: https://github.com/symfony/symfony/pull/6137 is merged!

Great! I'm assuming #1853096: Integrate symfony validation violations with Drupal translation is the next step towards resolving #39 and then unpostponing this issue?

Fantastic. Let's make sure we have a follow up for #32 / #41. Maybe it could/should be a combination of subclassing and .gitignore (the latter for e.g., the Mapping subnamespace)?

Looks like Dries OKed this in #40, pending the "two translation systems" issue getting resolved, and according to #49 it sounds like it has.

However, no longer applies. :( Sorry, I saw #1894508: Update symfony/serializer first. Eclipse is working on a re-roll.

Ok, I lied. #1894508: Update symfony/serializer looks much easier to re-roll than this so, reverted that one instead.

Committed and pushed to 8.x. Thanks!