gtristan commented on issue #1385: URL: https://github.com/apache/buildstream/issues/1385#issuecomment-808821369
> Hmm, so would the expected way to use eg bst-plugins-experimental then be to make your primary project use it as submodule and set ref to point to a tag, define it as a local plugin use it in junctions through that junction plugin origin? Not exactly, you don’t need to use a git submodule to use the junction plugin, rather we would have the `bst-plugins-experimental` repo provide a `project.conf` which declares all the plugins as local plugins *there* (so a plugins package itself *is* a buildstream project without any elements), then any project can use explicitly versioned plugins across a junction using the junction plugin origin (the version like you say, can be a git tag, it is defined by the `Source` on that junction). While it does work a lot *like* git submodules, it is declared completely by buildstream elements so it is explicitly project data which decides a plugin version and how to obtain it. Also, as I believe we had settled on keeping the `tar` and `remote` sources in core, it is more likely that plugin repos will be consumed as tarball releases through the `junction` origin rather than as git tags (although it is conceivable to use a tar plugin just to obtain the git plugin and then use the git plugin from there). What is also interesting about the junction plugin origin is that one can also *decide* to use the same plugin as a subproject, e.g.: the g-b-m project could select plugins from fdsdk and decide to buy into the same API breaks that fdsdk buys into, for the sake of consistently using the same plugins (or, g-b-m can decide to use different versions of the same plugins)... junction plugin origins are also recursive, so selecting a plugin from a subproject might get you a plugin that is actually a local plugin in a sub-sub-subproject. > Whereas BuildStream itself would have really hard API guarantees and you could just update it at any point. Yes. When we have fully API stable plugin repos, those stable repos will be more suitable for consumption using the `pip` plugin origin and installed on the host OS. If you intend to use unstable plugins using the `pip` origin, then you really need to use a `venv`, and you need all subprojects which consume the same plugin to *agree* on the API of that plugin, as `pip` plugins will be necessarily shared across subprojects (I believe I wrote a big warning about that in the plugin `origin` docs). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
