Expand Package Manager integration to support other source plugins

This is needed in order for Project Browser to support the Recipes initiative, which is strategically important. Therefore, I think we should un-postpone this and make it happen.

For implementation, I would suggest simply adding something like this to \Drupal\project_browser\Plugin\ProjectBrowserSourceInterface:

public function isProjectSafe(Project $project): bool;

To prevent BC breaks, I would add a default implementation to \Drupal\project_browser\Plugin\ProjectBrowserSourceBase which always returns FALSE.

I also think it would be beneficial for the method to receive a full Project object, if possible, rather than just a project ID, in the case the "is this safe" decision needs to be based on multiple factors (like whether the project is maintained, etc.) That would probably require some sort of way to retrieve the Project object from a cache of some kind. Should be interesting!

Postponed for over a year...!

Well, a lot has changed in that year. I think we can bravely move forward with this one.

Does this block ✨ Create a source plugin that scans for locally installed recipes Active ?

Nope!

@srishtiiee You mentioned in Slack:

Tim suggested that having the caching layer on top and using the same for all plugins as it currently did isn’t appropriate as the caching is query specific. I opened a new MR with plugin level caching and need feedback on it whether I’m on the right track and what the next steps would be.

I don’t know the Project Browser codebase at all, but I want to help you if I can!

So I’m trying to grok what you’re doing in https://git.drupalcode.org/project/project_browser/-/merge_requests/430/... 🤓

AFAICT you:

1. removed the caching from ProjectBrowserEndPointController, which essentially boils down to removing an if-branch and pulling up the else level to a higher level
2. moved it into MockDrupalDotOrg instead

Doesn’t this mean that there’s no caching at all anymore? 🤔 What am I missing? 🙈

I intended to move the whole caching layer one level down to the plugins instead of having a common layer for all the source plugins. I might have incorrectly interpreted what @tim.plunkett had suggested but the idea was to have the plugins handle their caching individually/separately which is what I tried to do by moving it into the MockDrupalDotOrg plugin.

Aha, I see, that makes sense!

But this did not yet update https://git.drupalcode.org/project/project_browser/-/blob/1.0.x/src/Plug..., which is why I was confused. But … looking at that plugin now, I see:

  protected function getProjectData(): array {
    $stored_projects = $this->cacheBin->get('DrupalCore:projects');
    if ($stored_projects) {
      return $stored_projects->data;
    }

so there's no changes needed? Which also means you've just removed extraneous caching for when this plugin is being used?

If the above is correct, then AFAICT, yes, you're on the right track 😄👍

I have almost no complaints here. Just a couple of questions. But otherwise I feel like this is RTBC.

I think this looks good. I do have one question on the MR for @tim.plunkett, though: https://git.drupalcode.org/project/project_browser/-/merge_requests/430#...

No response from @bnjmnm, so...whatever.

I'm happy to chalk it up to a "how did this ever work" moment and move on.

Agreed. Let's move forward.

I don't expect that this should actually land as-is, but it's usable in its current state! So, RTBC.

Failing PHPCS - I've rebased, please fix! :)

re-triage

I think we have pretty much already done this, now that the activator API and the recipe source plugin have landed.

Actually, this is more just outdated than anything.

What we really need is a new issue that rips out the hard-coding that prevents any project that's not from the drupalorg_mockapi source from being installed. With that gone, there'd automatically be first-class support for Package Manager across all sources.

@phenaproxima would you be able to create an issue for it, since it sounds like you have the direction?