[Plugin: Plugin Dependencies] conflict management idea for "Provides"

Maybe an administrator could even select which of the conflicting plugins should provide the feature in question.

He already can: by activating a conflicting plugin, he implicitly chooses to use that one.

If there are, say, two Facebook plugins – one providing login and one providing syndication – they wouldn’t both try to add data to the header, and could potentially share other data.

If they define different “Provides” headers, say ‘facebook-login’ and ‘facebook-syndication’, they wouldn’t be conflicting in the first place.

Instead of disabling the conflicting plugins outright, can some variable or option be set, notifying the plugins of the conflict? That way, an author could disable the part(s) of his plugin that conflicted but let other parts continue working.

I don’t think that’s a good idea. Plugins should be single-purpose or announce multiple distinct features that they provide:

Provides: facebook-login, facebook-syndication

I don’t think that’s a good idea. Plugins should be single-purpose or announce multiple distinct features that they provide:

Provides: facebook-login, facebook-syndication

What happens to the hypothetical plugin with a declaration like that? Would any plugin with EITHER facebook-syndication or facebook-login deactivate it? If not, how would another plugin that handles say, ‘facebook-login’ and ‘facebook-comments’ interact with it?

If they define different “Provides” headers, say ‘facebook-login’ and ‘facebook-syndication’, they wouldn’t be conflicting in the first place.

Ultimately, the situation I’m trying to describe is that each is declaring something like:
Provides: facebook-auth, facebook-syndication
Provides: facebook-auth, facebook-og, facebook-login

Users tend to want plugins to DO something, so they choose monolithic plugins over modular ones to get the marquee features. Deactivating either one of the above examples because of a conflict in facebook-auth is likely to confuse and frustrate the end user, who doesn’t know about the building blocks, and just wants both features.

That in turn will force plugin developers to either avoid the Provides line or create unique “feature” names, sacrificing modularity. Allowing plugins to strategically disable conflicting features without deactivating other features would, on the other hand, encourage modularity and adoption.

What happens to the hypothetical plugin with a declaration like that? Would any plugin with EITHER facebook-syndication or facebook-login deactivate it?

Yes, it would.

If dependencies were automatically installed, you wouldn’t be asking for this.

You could just build single-purpose library plugins and put them on wp.org. The only trick would be that the dependency name would have to match the wp.org plugin slug.