[Ecosystem-engineering] The future of Charm Helpers

[Cory Johns]

On Mon, Nov 23, 2015 at 1:37 AM, Billy Olsen <billy.olsen at canonical.com>
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20151123/a7f87df9/attachment.html>