FieldDefinitionTestBase::getNamespacePath() breaks with PSR-4

A module is not required to be in a folder of the same name.

Is this true? I thought for D8 we deliberately changed it to be one module, one directory specifically because of things like this. That's why views and views_ui are both top-level modules in HEAD, for example.

A few clarifications:

1. The directory name in which a module/extension is contained is NOT necessarily the module name. (example)
2. The basename($info_filename, '.info.yml') is the internal name of a module/extension.
3. The internal name of a module/extension is the extension's literal namespace (\Drupal\$name).
4. You MAY derive the internal module/extension name from its namespace. (basename('Drupal\mymodule') == 'mymodule')

Thanks @donquixote. We can see that this is a hard blocker for #2247991: [May 27] Move all module code from …/lib/Drupal/… to …/src/… for PSR-4 in comments 10-13 of that issue.

To clarify the bug a little, the question is, do we support:
myproject/modules/subproject/myproject_subproject.info.yml
Or do we require:
myproject/modules/myproject_subproject/myproject_subproject.info.yml

In #1299424: Allow one module per directory and move system tests to core/modules/system we added the requirement that there only be one module per directory (see the change record), but there is nothing enforcing that the directory have the same name as the module. For example, @donquixote confirmed that you can move the Views module to core/modules/_views/ and still enable it successfully.

This is a specific problem for PSR-4 because with PSR-0 we had the information in the directory path, e.g there would have been:
myproject/modules/subproject/lib/Drupal/myproject_subproject/Classes/Here
With PSR-4 we no longer have that.

Either we need to separately enforce that the directory name is the same as the module name, which would require a separate policy discussion, or we treat this as a bug, and include an automated test to prove that enabling a module in a directory with a different name than its name works (which @donquixote will explore today).

Based on #8, it sounds like the answer is, yes, we explicitly support the directory name differing from the module name:
myproject/modules/subproject/myproject_subproject.info.yml
And therefore should go ahead and fix it here.

Sorry, but this issue is about a test base class. We're not going to add tests for tests.

Let's also make sure that each of these child issues relates to the parent PSR-4 issue.

@ sun is correct; I apparently was confusing this with a different part of the patch from #2247991: [May 27] Move all module code from …/lib/Drupal/… to …/src/… for PSR-4 that was changing some API. Adding a test to ensure a module can be enabled in a different directory name would be worthwhile but is out of scope here if this bug only exists in test code.

Thanks @donquixote. Agreed that we should fix it in the simplest way possible to just unblock the other issue. E.g.:

+++ b/core/modules/path/tests/src/Field/PathFieldDefinitionTest.php
@@ -41,8 +41,8 @@ protected function getPluginId() {
-  protected function getNamespacePath() {
-    return dirname(dirname(dirname(__DIR__))) . '/lib/Drupal/path';
+  protected function getModuleAndPath() {
+    return array('path', dirname(dirname(dirname(__DIR__))));

This is a bit of a silly contorted abstraction and opaque, especially since PathFieldDefinitionTest is the only implementation of this base class, but it's pre-existing in HEAD so I agree we should just fix the PSR-4-blocking bug here.

I rerolled to tweak the docs a little to our normal standards, but the patch looks fine to me. Let's get it in. (RTBCing since I just tweaked docs.)

Committed 7ae6f6b and pushed to 8.x. Thanks!

FieldDefinitionTestBase is a mess but that is not the fault of PSR-4

A little bit unhappy that we went with a single method that returns two completely different things instead of two separate methods, especially because I had discussed this with @donquixote in IRC, but at the end of the day this is a freaking test base class so whatever...

@tstoeckler, apologies, I didn't see any indication of an IRC conversation. =/ Yeah, it's far from perfect, but then that entire entire part of the test and base class is kind of goofy and ugly (not to mention there's abstract methods on the TEST base class that get implemented.... once). We just don't need to block a beta blocker on cleaning up the test. Maybe file a followup? We can definitely improve the test so long as it doesn't regress the PSR-4 support.

Right, my previous post sounded like @donquixote went over my head or something. That was not really the case. Sorry for that. It was more a miscommunication. I would have supported returning and array of $namespace => $directory, as that is a (somewhat) meaningful data structure on its own.

But again, let's move on. There are bigger fry to fish... :-)

And thanks for fixing this!!!