[BuildStream] pip origin doesn't support plugins with same name

[Chandan Singh <chandan chandansingh net>]

Hi all,

I think the title of this thread could be improved, but I couldn't of
anything better at the moment :) Please see the overview section for
details.

Overview
========
I was recently considering moving the two `pip` plugins out of the main repo
into an external plugins repository. Then I realized that it's not trivial as of
today because all BuildStream plugins, be it elements or sources, are expected
to share the same "buildstream.plugins" namespace when defining their entry
points.

This means that it's not possible to have an element and a source plugin with
the same name, like "pip". This is something that only shows up as an issue
when using the "pip" origin.  This is not an issue for "local" and "core"
origins as they operate on file paths, and not entry points.

Since this is allowed for two origins already, it seems like an unnecessary
restriction for the "pip" origin. We can decide not to allow duplicate plugin
names at all, but then it should be enforced across the board.

Options
=======
I think fixing this issue requires some sort of API break, one way or the other.
Broadly speaking, these are the two options that I see currently:

1. Separate entry point namespaces
----------------------------------
Under this solution, we would require all sources to be in
"buildstream.plugins.sources" namespace, and all elements to be in
"buildstream.plugins.elements" namespace.

This will mean an API break for _all_ external plugin maintainers. They would
need to change their `setup.py` files to update the entry points accordingly.

2. Disallow duplicate names altogether
--------------------------------------
This way, plugins with duplicate names (like "pip") will need to be renamed to
something like "pip_source" and "pip_element".

This will mean an API break for the plugin providers _and_ all downstream users
of those plugins.

Proposal
========
Option 1 will break all plugin repositories, albeit with a reasonably
straight-forward fix, but not any BuildStream projects.

Compared to that, option 2 will require both plugin maintainers and the users of
affected plugins to take an action.

Personally, I am in favor of option 1. This is because I think it clearly
separates elements from sources (like both other origins already do).

(We can keep supporting "buildstream.plugins" entrypoint as well but I don't
think quite like that idea, as it will likely increase confusion for plugin
authors.)

---

Let me know what you think, and if you favor one option strongly over the other.

Thanks!
Chandan