Unmet dependencies

@mkalkbrenner: it might be useful to have a look at #2668236: Make the plugin discovery case sensitive for the case sensitivity.

I feel very strongly that we should't let search api depend on taxonomy, maybe we should put the term stuff in a seperate module that does depend on taxonomy?

That's what I proposed, too:

The correct solution would be to move these plugins into separate sub-modules that explicitly declare the dependency to the taxonomy or the user module!

Oh, oops, yes. That solution++

I'm not sure I agree with this. If the taxonomy or user module isn't enabled (not possible for the latter, I think), there won't be field references to taxonomy terms (or users), so the filters won't be used anyways.
Of course, you can cause a fatal error by still requiring the file manually – but why would you do that? With that logic, we also couldn't provide a Views integration without depending on the Views module. But if the Views module isn't installed on a site, all those classes depending on it just won't be used – problem solved.

If you show me a way to actually trigger this problem via the UI, then yes, that would be a problem. Then we'd probably need to make sure to declare the necessary dependencies for views using those filters, for example. (Or remove the filter class via hook_views_filter_alter() (or whatever the hook is) if the module isn't enabled.)
But if you can only trigger it with special PHP code, it's not a bug.

Also, even if it is a bug, I don't really see why it should be a Beta blocker? It won't require any API change to fix it, as far as I can see?

Oh, wow, that indeed blows up horribly! We definitely need to fix that. Why didn't you report the issue with that right away?
Updated the IS to reflect the real problem.

A quick look at \Drupal\Core\Plugin\DefaultPluginManager::findDefinitions() also shows that using an alter hook also won't be able to fix this problem. So, indeed, it seems we will need to move that filter and argument to a separate module (maybe using that opportunity to also make their names consistent). Which is really pretty ugly, and bad UX, but appears to be the only solution.

As said, since Drupal requires the user module (and a lot of our code is using users), I don't think we need to do the same for users.

So this?

Oops.

The test runs out of memory on php5.x, php7 passes. I don't understand this.

@andypost suggested a great solution to fix something similar in facets; see the latest patch in #2775963: FacetsSerializer views style plugin depends on optional rest module, a similar solution would mean no changes for facets to go back to green tests. That would be a great solution imho.

Much better than the solution in the previous patches I uploaded anyway.

Also I'd better filed new issue to reorganize folders for modules and test modules

@drunken monkey: if this patch applies and passes, and you agree with the solution, please credit @andypost as well. I wouldn't have figured this out without his example.

Isn't this actually a core issue? See https://www.drupal.org/node/2776235

See my comment #7:

A quick look at \Drupal\Core\Plugin\DefaultPluginManager::findDefinitions() also shows that using an alter hook also won't be able to fix this problem.

Unless I'm mistaken, moving the class to a sub-module with the proper dependency is really the only way to solve this problem.
Patch attached, based on #15 (or, rather, #13 plus the interdiff from #15 – you had unrelated changes in the patch file from #15). Locally, it passes, but I'm also using PHP 7. Not sure what to do if it keeps failing on PHP 5.

I only renamed the argument class to follow the name of the filter class. Also, I think search_api_views_taxonomy, or at least search_api_views_taxonomy, would be a better name for the new module.

Isn't this actually a core issue? See https://www.drupal.org/node/2776235

That doesn't seem to have anything to do with it.

That makes sense, The fails on php5 are still happening but it's green on php7, so I guess this is the correct way to resolve this.

OK, thanks!
And any opinion regarding the name of the new module? search_api_term, search_api_views_taxonomy or search_api_views_taxonomy?

+1 to search_api_views_taxonomy

Any reason we're testing on D8.3? The tests succeed for D8.1, seems like there is an issue with 8.3.

The default branch for testing should be set to 8.1, not 8.3. See https://www.drupal.org/node/2784849.

Renamed the new module to search_api_views_taxonomy. Also, remove all references to the two handlers from the Search API module into the new module (seems we kinda forget about that bit before).
Still seems RTBC to me, any objections?
(Would be great to have tests for those handlers, too, but that probably shouldn't hold up this issue. We can create a followup for that.)

Any reason we're testing on D8.3? The tests succeed for D8.1, seems like there is an issue with 8.3.

As said in the other issue, this is a known problem and nothing we can fix in the Search API.

I agree with the changes, but it seems that the testbot doesn't.

The test bot has been brought to reason, fortunately.
Since I'm reading an "RTBC" from your comment: committed.
Thanks again, everyone, for your work here!

Awesome! This should make the facets tests green as well again, checking that out later today. Thanks so much for your hard work here @drunken monkey!

In case anyone reads closed issues: I'm proposing a way better solution in #2917399-10: Missing / broken handler when adding a filter for a field.