On Mar 11, 2016, at 07:22 AM, Michael Biebl wrote: >It creates unnecessary churn and potential stale dependencies in the future. >Most importantly, this split looks like an implementation detail to me. >I don't see, why packages should add a dependency on >libpeas-1.0-0-python3loader but not libpeas-1.0-0-python2loader
I'm not sure about your first point, but as to your last point: it would make no sense for an application to depend on both loaders. You cannot load both a Python 2 and Python 3 runtime into the same address space. The problem this is trying to solve is two-fold. First, some libpeas plugins don't use Python at all, and yet with the old arrangement they would still be pulling in both Python stacks. With this change, non-Python plugins wouldn't depend on either loader package and it would be a clear win. Python plugins are either going to be ported to Python 3 or not, in which case they now make explicit which runtime stack they require, via the loader they depend on, and in fact load at runtime (again, they cannot load them both). So this is another win because it allows such applications to only depend on the Python stack they use, and we can better identify which ones need porting to Python 3.
pgpJTlXl2CDXC.pgp
Description: OpenPGP digital signature
