Re: [BuildStream] [Proposal] Plugin fragmentation / Treating Plugins as Sources

[Mathieu Bridon <bochecha daitauha fr>]

Say BuildStream is installed from a distro package, against the system
Python. Run `bst`, it creates the venvs and installs the plugins in
them.

Upgrade your system, get a new Python and BuildStream.

Next time you run `bst`, you need to destroy and recreate all the
venvs, so that they get the new Python. (there is no way to update the
Python in a venv)

That also means you need to keep track of which Python is in the venvs,
so that every time you launch `bst` you compare that to BuildStream's
Python.

That seems like an awful lot of management, and given how venvs work it
seems to me to be pretty brittle.

But then I'd be happy to be proven wrong. :)


-- 
Mathieu



On Sun, 2019-04-14 at 21:16 +0200, Sander Striker wrote:
> I am assuming that we, or rather bst, manages the venv's.  There seem
> to be enough options to ensure we run with the same Python as bst
> itself.
>
> Cheers,
>
> Sander
>
> On Sun, Apr 14, 2019, 19:29 Mathieu Bridon via buildstream-list <
> buildstream-list gnome org> wrote:
> > Hi,
> >
> > On Sun, 2019-04-14 at 19:38 +0900, Tristan Van Berkom via
> > buildstream-
> > list wrote:
> > > If we can get some prototype which demonstrates the base concept
> > of:
> > >   * Installing two separate venvs with different dependency
> > versions
> > >   * Running an interpretor which loads a plugin in both separate
> > >     venvs
> >
> > BuildStream will usually run from the system Python, or from its
> > own
> > venv. The venvs for each plugin have their own Python interpreter.
> >
> > Do you plan to change plugins so that each is its own process? (a
> > given
> > Python running the plugin)
> >
> > Otherwise, how will BuildStream running from a certain Python load
> > plugins from venvs which might have been built for different
> > Pythons?