On Mon, Nov 23, 2015 at 1:37 AM, Billy Olsen <[email protected]> wrote:
> Secondly, I'm mildly concerned with the namespace of choice (using the > shared charms. as the parent namespace). There may be a magical python 3ism > that resolves the mixed development + packaged use of common code (think > pip, virtualenvs, etc), but there were some issues that the oslo components > within OpenStack ran into with a shared common namespace ((some are in a > blog here > <http://blog.nemebean.com/content/whys-and-hows-oslo-namespace-change>, > and the spec to remove the namespaces within the oslo packages is here > <http://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html>). > As the libraries are broken up, as I believe they should be, we need to > make sure we've carefully considered how we expect some of these flows to > work and make sure they work (and preferably well). Maybe its not really an > issue, but I'd love to be convinced of that. > I do think that namespace package support has been much improved in Python 3 (in particular, 3.3 and above), but I must admit that I had not run into nor been aware of the issues with namespace packages under earlier versions of Python. However, there has already been discussion of making all layered / reactive charms Python 3 anyway, so maybe we can do some quick tests to determine if those issues have been resolved with the new namespace package support?
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
