@robdennis and I have had several conversations about this, and the more we talk about the tradeoffs, the more we come down in favor of getting rid of all of Sideboard's virtualenv shenanigans.
There's basically one reason why we tried to do the each-plugin-runs-in-its-own-virtualenv thing: so that multiple Sideboard plugins can run in the same process even if they have conflicting package requirements.
The main reasons to stop doing this are as follows:
It's inherently confusing and error-prone. We've had several edge case bugs which are extremely hard to track down, such as a plugin accidentally calling into the Sideboard version of SQLAlchemy instead of its own SQLAlchemy. These are hard enough for us to diagnose and would be near-impossible for a Sideboard newbie to figure out.
Some third-party modules will just never work with this. We recently discovered that Django reads directly from sys.modules in some cases, which will just never work gracefully.
Sideboard has to be implemented before anything else. We can work around this in many cases (like by using @entry_point functions for command line scripts and conftest.py for pytest), but it's hard to imagine that something like Django manage.py would ever work.
Sideboard is REALLY slow to start up because of the virtualenv stuff. It takes upwards of 10 seconds on my laptop just to do from sideboard.lib import * on my laptop. It takes like 20 seconds just for py.test to collect its tests. That's a hugely bad first impression for anyone starting with Sideboard.
I don't think the advantage outweighs those disadvantages. Separate virtualenvs was a really nifty idea, but it's just not working out in practice, and it's such a small part of what Sideboard offers that we're better off without it. We can also close #66 and #23 and #18 and #72 as a result of this, since they will no longer apply.
@robdennis and I have had several conversations about this, and the more we talk about the tradeoffs, the more we come down in favor of getting rid of all of Sideboard's virtualenv shenanigans.
There's basically one reason why we tried to do the each-plugin-runs-in-its-own-virtualenv thing: so that multiple Sideboard plugins can run in the same process even if they have conflicting package requirements.
The main reasons to stop doing this are as follows:
sys.modulesin some cases, which will just never work gracefully.@entry_pointfunctions for command line scripts andconftest.pyfor pytest), but it's hard to imagine that something like Djangomanage.pywould ever work.from sideboard.lib import *on my laptop. It takes like 20 seconds just forpy.testto collect its tests. That's a hugely bad first impression for anyone starting with Sideboard.I don't think the advantage outweighs those disadvantages. Separate virtualenvs was a really nifty idea, but it's just not working out in practice, and it's such a small part of what Sideboard offers that we're better off without it. We can also close #66 and #23 and #18 and #72 as a result of this, since they will no longer apply.